[This query feels to be specific to a particular implementation
of AgentX, rather than about the protocol as a whole. As such,
it feels more appropriate on the net-snmp-coders mailing list,
rather than the AgentX WG list. ]


On 05 Jul 2007 21:06:24 -0700, Mark Atwood wrote:
> I've been trying to build an AgentX subagent that registers a single row
> instance inside a table. I'm using net-snmp 5.4


> I found something that confuses me, and I think it might be a bug in
> net-snmp's client or server AgentX routines.


Very likely.
As I think I said before, this particular facility hasn't been widely used,
so will almost certainly still be relatively buggy.


> The oids instance row I want to register are, I think, from
> .1.3.6.1.4.1.8072.9999.9999.947.17.61.1.3.42.1.69
> to
> .1.3.6.1.4.1.8072.9999.9999.947.17.61.1.5.42.1.69


> That's .1.3.6.1.4.1.8072.9999.9999.947.17.61.1.[3-5].42.1.69
> {Do I want to register the whole [1-5] range of the instance row
> instead of just [3-5]?}


No - you are registering the accessible MIB objects.
Assuming the index objects are defined as MAX-ACCESS
not-accessible, then they shouldn't be included in the registration.



> The AgentX-Register-PDU sent was
> flags = 0x01 (INSTANCE_REGISTRATION, not NETWORK_BYTE_ORDER)
> range_subid = 13
> {shouldn't this be 14?}


Yes.

What does the code for registering this slice look like?



> The AgentX-Response-PDU received was
> flags = 0x01 (INSTANCE_REGISTRATION, not NETWORK_BYTE_ORDER)


I'm not sure that is correct either.

> oid
> n_subid = 12 prefix = 4
> include = 0
> suboids = 1.8072.9999.9999.947.17.61.1.3.42.1.69
> oid
> n_subid = 12 prefix = 4
> include = 1 { according to RFC2741 line 725,
> shouldnt this should always be zero? }


I think so, yes.
I'd need to re-read the AgentX specs to clarify what should be
returned following a Register-PDU, but the second half of a
SearchRange is certainly non-inclusive.


> suboids = 1.8072.9999.9999.947.17.61.5.3.42.1.69
> { shouldnt this be 1.8072.9999.9999.947.17.61.1.5.42.1.69 }


Yes.
That's probably a consequence of the wrong 'range_subid' value
in the original registration.


> So am understanding what I want to register? Which I register a
> instance row, do I want to register just the part that has data, or
> also the not-accessible index variables as well?


Just the accessible columns.


> Is the range_subid in this case supposed to be 13 or 14?


14. The OID is treated as a 1-indexed array, and the column
subidentifier is the 14-th entry

> Is the "include" in the second oid of the response varbindlist
> supposed to be 0 or 1?


Probably 0.

> Isn't that a searchrange? If it is a searchrange, and its supposed to
> be zero, that means its supposed to be *beyond* the end of my
> registered instances.


Yup - the range searched should be [3..6), rather than [3..5]


> If that's the case, what should it's OID value be


.1.3.6.1.4.1.8072.9999.9999.947.17.61.1.6.42.1.69

I suspect.

> given that some
> other subagent could also register a row in this table, with some
> other value for the indexes?


That would involve registering different OIDs,
say
[ .1.3.6.1.4.1.8072.9999.9999.947.17.61.1.3.42.1.70
to
.1.3.6.1.4.1.8072.9999.9999.947.17.61.1.6.42.1.70 )


> Interestingly, my reading of the RFC doesnt say that these two OIDS
> should be part of the AgentX-Response-PDU at all.


I need to re-read the specs.
I couldn't immediately spot what the response to a registration ought to be.


Dave

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/...et-snmp-coders