[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 <[EMAIL PROTECTED]> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
