Re: Why does net-snmp generate an extra request internally?

On Thu, Apr 16, 2009 at 3:59 AM, Dave Shield <[email protected]>wrote:

2009/4/16 Fulko Hew <[email protected]>:
> > While testing my 'network simulator' agent, I'm finding that Net-SNMP
> > appears to be generating an extra (ie. unexpected) getnext request
> > internally that gets handed down to agents.
>
> Are you talking about communication between the master Net-SNMP
> agent and subagents that you provide?   Or between the client
> application (snmpgetnext) talking directly to your "simulator agent"?
>   It's not clear from your description, but I presume the former.
>

You are correct in assuming its between Net-SNMP and my sub-agent(s).

Its actually a single sub-agent (written in Perl) that registers
itself against the (currently) three branches mentioned below.


> > In my environment, I have a MIB variable instance at
> > 1.2.840.10006.300.43.1.3.0
> > (IEEE8023-LAG-MIB::dot3adTablesLastChanged) and the 'next' variable in
> the
> > list is SNMPv2-MIB::sysDescr.0 (at 1.3.6.1.2.1.1.0)
>
> Are these both implemented by your subagent?


Yes.


> What MIBs are handled by the main agent?
>

None.  My agent is intended as an 'any device' simulator,
and hence tries/needs to usurp the whole tree.  ie. OID of 1...

> Internally, my agent received that request and answered it,
> > but then in the same request list, there is another request 'GetNext
> (1.3)'
>
> > I currently have the following sub-trees in my MIB collection:
> >
> > 1.0...
> > 1.2...
> > 1.3...
>
> Yes - that makes sense.
> Particularly if you think of these as *ranges*
>
>   .1.0 up to (but not including) .1.1
>   .1.2 up to (but not including) .1.3
>   .1.3 up to (but not including) .1.4
>
> rather than subtrees.
>

Correct.  I didn't know how to express that so eloquently.


>  > Can someone shed some light on whats going on and why?
>
> When the master agent receives the request
>     GETNEXT 1.2.840.10006.300.43.1.3.0
> it passes this request off to the subagent registered for the .1.2 range.
> That subagent processes the request according to the information
> that it knows about, and returns the next valid instance
> (.1.3.6.1.2.1.1.0) back to the master agent.
>
> Now the master agent looks at the OID, and compares it to the
> range that this registration was valid for [.1.2 - .1.3 )
> This result is *not* in the valid range, so it can't be used.
>
> The master agent therefore discards the result, and moves
> on to the next registration (.1.3) and sends a GETNEXT
> request to that subagent (which happens to be the same one!)
> asking for the first entry that it knows about.
>  When this result comes back, it *is* in the valid range for
> that registration, so can be used.
>
> That's my guess, anyway.


This is the same revelation I came to in the shower a few minutes ago.

The original 1.2.x request comes in, and my agent answers it, but since my
agent 'knows' the whole tree, it responds with the OID in the 1.3 branch.
The master agent, sees this response... ignores it and performs another
request into the 1.3 tree, which is fed down to my agent again (because it
is registered onto the 1.3 tree also.  It answer again, but this time it
_is_
accepted by the master agent, and the response is sent back to the client.

(BTW.  Subsequent debugging showed me that the new sub-tree request came in
as a new request set, not as the second request of the original request
set.)

So without having done more research yet, before posting this reply...

1/ This is a side effect of my Perl based sub-agent not being able to
register itself against the top tree 1.x (the master agent complains
about multiple registrations) I will examine if/what changes might be
required in Net::SNMP to allow/superceed existing registrations.

2/ Failing that, and having to continue to perform individual registrations
on multiple sub-trees... What can a sub-agent return to indicate...
'response will not be in my sub-tree, go an ask the next guy'

This would be important to me, because my agent is effectively called twice
and my synthetic data is therefore incorrectly (incremented) processed
twice.

------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and 
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today. 
Use priority code J9JMT32. http://p.sf.net/sfu/p

_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users