Re: agent does not get called when registered at '.1'

Fulko Hew <[email protected]>
Newsgroups gmane.network.net-snmp.user
Message-ID <[email protected]>
On Wed, Apr 1, 2009 at 3:17 PM, Mark Ellison <[email protected]>wrote:

> On 04/01/2009 02:45 PM, Fulko Hew wrote:
>
>  On Wed, Apr 1, 2009 at 2:26 PM, Mark Ellison <[email protected]<mailto:
>> [email protected]>> wrote:
>>
>>    On 04/01/2009 02:00 PM, Fulko Hew wrote:
>>
>>>    I've managed to get a lot farther in my universal agent/network
>>>    simulator,
>>>    but todays problem is:
>>>
>>>    "An agent registered at '.1' does not receive any requests,
>>>    but agents registered at '.1.x' (and elsewhere) do receive requests"
>>>
>>>    For example: Lets say I query the agent with getNext
>>>    ('1.3.6.1.2.1.1.1')
>>>    And given the agent code:
>>>
>>>    my $regoid = new NetSNMP::OID('.1.3');
>>>    $agent->register($0, $regoid, \&my_snmp_handler);
>>>
>>>    my agent receives the query, but...
>>>    if I register my agent with the OID '.1'  instead (right at the
>>>    top of the tree so I get _every_ request) my handler doesn't get
>>>    called, but something inside the daemon does cause it to respond
>>>    with 'noSuchName'.
>>>
>>>    Any clues?
>>>    Is there something that says registering at the top of
>>>    the OID tree is wrong, illegal, or a bug/feature?
>>>
>>>     The shortest possible OID subtree is two subids in length.  If you
>>    register '.1' it is likely you are really registering '.0.1'.
>>  (There are some funky rules about encoding the first subid in an OID.)
>>
>>
>> OK.  I can live with that.  I just wanted to make sure _I_ wasn't doing
>> anything wrong.
>>
>>    You will still get every request by registering '.1.3'.    Everything
>> published for SNMP object-types, etc. is under .1.3.6.1
>>    anyway.  (See RFC 1065).
>>
>>
>> Actually... In the course of  hunting down MIBs for stuff I've tripped
>> over,
>> I have found the following from Cisco that fall outside of the normal
>> '1.3.6...' branch:
>>
>> IEEE8021-PAE-MIB     -    1.0.8802.1.1.1                also known as:
>>  iso.std.iso8802.ieee802dot1.ieee802dot1mibs.ieee8021paeMIB
>> IEEE8023-LAG-MIB     -    1.2.840.10006.300.43    also known as:
>>  iso.member-body.us.ieee802dot3.snmpmibs.lagMIB
>>
> You are doing some serious hunting.  Keep in mind that you can register
> multiple subtrees.


Yup. Thats what I'm working on right now.
I have a list of 'known' OIDs, so I'm searching that tree for the first
level of branches
and I'll register those.  Then anything that comes in underneath those
should get to my simulator.
(Then... based on the OID and its syntax, and the target IP (because I'm
simulating many IPs)
I'll pass back, semi-intelligent data.)


> Here is a link to more information about the top level OID subtrees:
> http://www.alvestrand.no/objectid/top.html
>
> Essentially, the first subid can be 0, 1 or 2.  I vaguely recall the second
> OID is limited to a range of 0..40.  Most of the top level subtrees are not
> used as a prefix for SMI definitions though.


Once past this top level registration, everything else will be dynamically
generated/supported.
So if I have a MIB compiled in, I'll answer (if configured to do so), and if
I don't have a MIB,
It'll mean that this NMS is looking for something I'm not expecting, and I
have to hunt it down.

Best of luck with your simulator effort!


Thanks.

------------------------------------------------------------------------------

_______________________________________________
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.