Subject: [Agentx] Some confusion, while watching AgentX-Register-PDU in net-snmp 5.4

From: Mark Atwood <[email-masked]>
Date: 06 Jul 2007 00:46:11 -0700

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

While debugging, I ran the subagent with -DALL, and then looked at all
the back and forth IO, along with a copy of RFC2471, to watch what the
subagent tells the snmpd.

I found something that confuses me, and I think it might be a bug in
net-snmp's client or server AgentX routines.  Or it might just be
me not understanding the RFC.

The oids instance row I want to register are, I think, 
  from 
     netSnmp.netSnmpExperimental.netSnmpPlaypen.mraMIB.mraObjects
       .mraOneTable.mraOneEntry.mraOneNum.42."E"
    .1.3.6.1.4.1.8072.9999.9999.947.17.61.1.3.42.1.69
                                            ^
  to
     netSnmp.netSnmpExperimental.netSnmpPlaypen.mraMIB.mraObjects
      .mraOneTable.mraOneEntry.mraOneStr.42."E"
    .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
It's not [1-5] because the [1-2] range covers the OID of the
not-accessable indexes of the table.

  { Do I want to register the whole [1-5] range of the instance row 
    instead of just [3-5]? }

The AgentX-Register-PDU sent was
  flags = 0x01 (INSTANCE_REGISTRATION, !NETWORK_BYTE_ORDER)
  range_subid = 13
    {shouldn't this be 14?}
  oid
    n_subid = 12   prefix = 4
    suboids = 1.8072.9999.9999.947.17.61.1.3.42.1.69
  range = 5

The AgentX-Response-PDU received was
  flags = 0x01 (INSTANCE_REGISTRATION, !NETWORK_BYTE_ORDER)
  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? }
    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 }
                                                   ^^^^^

Am I correctly understanding what I want to register?
That is, when 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?

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

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

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.

If that's the case, what should it's OID value be?  Given that some
other subagent could also register a row in this table, with some
other value for the indexes?

Interestingly, my reading of the RFC doesnt say that these two OIDS
should be part of the AgentX-Response-PDU at all.  Is that a bug as
well?  It's certainly useful...

-- 
Mark Atwood                 When you do things right, people won't be sure
[email-masked]         you've done anything at all.
http://mark.atwood.name/   http://fallenpegasus.livejournal.com/

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 6 Jul 2007 18:10:38 -0700

Hi -

> From: "Mark Atwood" <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, July 06, 2007 12:46 AM
> Subject: [Agentx] Some confusion,while watching AgentX-Register-PDU in net-snmp 5.4
...
>   { Do I want to register the whole [1-5] range of the instance row 

There's no great benefit to doing so.

>   flags = 0x01 (INSTANCE_REGISTRATION, !NETWORK_BYTE_ORDER)

I'd have expected 9, based on the text on page 24 of RFC 2257,
as well as the example on page 25, since it's using the prefix kludge.
It might be worth looking at the actual byte stream, rather than
a pretty-printed version; it's possible that the pretty-printer is
obscuring what's really happening.

...
>                   shouldnt this should always be zero? }

Here, yes.

>       { shouldnt this be 1.8072.9999.9999.947.17.61.1.5.42.1.69 }

No, it should match the request, so it should be
    1.8072.9999.9999.947.17.61.1.3.42.1.69
 
> do I want to register just the part that has data,

Yes, though it wouldn't hurt to register the whole thing.

> or also the not-accessible index variables as well?

RFC 3416 clause 4.2.5 generation of "notWritable" error is
easier to ensure if the not-accessible indexes are included.
 
> Is the range_subid in this case supposed to be 13 or 14?

I'd say 9.  (See above)

> Is the "include" in the second oid of the response varbindlist

I don't know where that's coming from.  As I read RFC 2247, I'd expect
the response to look more like the request.

> well?  It's certainly useful...

Sounds bug-like to me.  :-)

Randy

---

From: Mark Atwood <[email-masked]>
Date: 06 Jul 2007 18:37:56 -0700

> obscuring what's really happening.

I think the RFC is reasonably clear here.

| Note that r.range_subid indicates the (1-based) index of
| this sub-identifier within the OID represented by r.subtree,
| regardless of whether or not r.subtree is encoded using a
| prefix. (See the example below.)

"within the OID represented by r.subtree" tells me that the index is
into the *actual* complete OID.  r.subtree is just a representation of
the complete OID.

I supposed it could be more clear.  The proof of the pudding would be
an interop-fest, I supposed.

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 6 Jul 2007 21:06:57 -0700

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, July 06, 2007 6:37 PM
> Subject: Re: [Agentx] Some confusion, while watching AgentX-Register-PDU in net-snmp 5.4

...
> into the *actual* complete OID.  r.subtree is just a representation of

The example shows an r.range_subid value of 5.  For the example
to make sense, this is the fifth word in the encoding (with a value of 1),
not the fifth subidentifier of the object identifier it represents.  For your
interpretation to be correct, r.range_subid in the example would
be 10.

Note that the text says "r.subtree", *not* "r.region", and thus is not
in terms of the complete object identifier that r.region encodes.
At least that's how I read it. 

Either the example is incorrect, or the explanatory text is unclear, or both.  :-)

> an interop-fest, I supposed.

There was one, long long ago.  Perhaps someone who hasn't been away
from this stuff as long as I have should comment.

Randy

---

From: Frank Fock <[email-masked]>
Date: Sat, 07 Jul 2007 21:45:36 +0200

Hi,

>> | prefix. (See the example below.)

The above is a quote of RFC 2741 page 24.

> interpretation to be correct, r.range_subid in the example would
The example on page 25 and 26 of RFC 2741 reads as follows:

   The use of r.range_subid and r.upper_bound provide a general
   shorthand mechanism for specifying a MIB region. For
   example, if r.subtree is the OID 1.3.6.1.2.1.2.2.1.1.7,
   r.range_subid is 10, and r.upper_bound is 22, the specified
   MIB region can be denoted 1.3.6.1.2.1.2.2.1.[1-22].7.
   Registering this region is equivalent to registering the
   union of subtrees

   1.3.6.1.2.1.2.2.1.1.7
   1.3.6.1.2.1.2.2.1.2.7
   1.3.6.1.2.1.2.2.1.3.7
   ...
   1.3.6.1.2.1.2.2.1.22.7

Following that example, I would say that 14 is the correct value
for r.range_subid in Mark's original example.

> Either the example is incorrect, or the explanatory text is unclear, or both.  :-)
I think, this has been clarified in RFC 2741 which obsoletes 2257 ;-)

>> an interop-fest, I supposed.

I have implemented AgentX++ and SNMP4J-AgentX according to
RFC2741 and so far got no complains about interoperability
issues - except those I had with the NET-SNMP master and
sub-agents regarding handling of search-ranges and region
registration. The bug(s) Mark found might be one reason
for that.

Regards,
Frank Fock

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 7 Jul 2007 21:46:01 -0700

Hi -

> From: "Frank Fock" <[email-masked]>
> Sent: Saturday, July 07, 2007 12:45 PM
...
> I think, this has been clarified in RFC 2741 which obsoletes 2257 ;-)

Absolutely.  Thanks for correcting my mistake in citing the wrong document
and steering this thread back to the correct document.
 
> registration. The bug(s) Mark found might be one reason

Sounds plausible.

Randy