Magnus Fromreide wrote:
> On Wed, Sep 01, 2004 at 03:02:39PM +0100, Dave Shield wrote:
>
>>>Mike Slifcak wrote:
>>>I believe that the logical outcome for registering three single objects
>>>should be three ranges N::N, not N::N+1.
>>>
>>>e.g., I would believe that these would be correct:
>>>
>>> 1.3.6.1.3.4 - 1.3.6.1.3.4
>>> 1.3.6.1.3.5 - 1.3.6.1.3.5
>>> 1.3.6.1.3.6 - 1.3.6.1.3.6
>>>
>>>
>>>Is there some other knowledge that applies ?
>>
>>
>>Question - are you talking about registering threee MIB instances,
>>or three MIB (scalar) objects?
>>
>>When registering a single instance (e.g. sysDescr.0), then I'd
>>agree - this should ideally register a single OID - i.e. the "range"
>> [ .1.3.6.1.2.1.1.1.0 - .1.3.6.1.2.1.1.1.0 ]
>>
>>But when registering a MIB scalar object (e.g. sysDescr), then this
>>needs to register a full subtree - i.e. the range
>> [ .1.3.6.1.2.1.1.1 - .1.3.6.1.2.1.1.2 )
>>
>>[Note that this is the mathematical notation for
>> "everything up to but not including" ]
>>
>>
>>That's because the handler for sysDescr would need to catch both
>>valid instances (.1.3.6.1.2.1.1.1.0) and invalid instances
>>(.1.3.6.1.2.1.1.1, .1.3.6.1.2.1.1.1.99, .1.3.6.1.2.1.1.1.0.1.2.3, etc)
>>And the situation for registering a table, or a full subtree is the
>>same (but more so).
>>
>>
>>When the agent MIB registry was first developed, this was done for
>>the v4 module API, which worked only with subtrees (containing a list
>>of named MIB objects). At that point, there was no concept of
>>registering individual instances.
>> Things have moved on a bit since then. but I'm not convinced that
>>the agent registry has been reworked to include the special processing
>>that would be necessary for individual instance registrations.
>>So in the meantime, treating an instance registration as a subtree
>>would work properly in 99% of cases - albeit with some unnecessary
>>processing.
>
>
> I tend to think of registration in terms of ranges and then it is possible
> to register a single item as [ .1.3.6.1.2.1.1.1.0 - .1.3.6.1.2.1.1.1.0.0 )
> but I am not sure about exactly how the agent_registry algorithm works.
>
> In my original post I was registering trees but I seem to have failed to say
> so.
>
> /MF
>
>
Dave,
Does the patch below supplied by Magnus in patch #1009799
fix the problem properly ?
Magnus,
Following your example, do you have a test case that
would produce this expected result ?
1.3.6.1.3.4 - 1.3.6.1.3.5
1.3.6.1.3.5 - 1.3.6.1.3.6
1.3.6.1.3.6 - 1.3.6.1.3.7
-mike
Index: agent/agent_registry.c
===================================================================
RCS file: /cvsroot/net-snmp/net-snmp/agent/agent_registry.c,v
retrieving revision 5.20
diff -c -r5.20 agent_registry.c
*** agent/agent_registry.c 2 Aug 2004 21:17:37 -0000 5.20
--- agent/agent_registry.c 15 Aug 2004 21:03:25 -0000
***************
*** 636,641 ****
--- 636,643 ----
sub2->name_a[range_subid - 1] = i;
sub2->start_a[range_subid - 1] = i;
sub2->end_a[range_subid - 1] = i; /* XXX - ???? */
+ if (range_subid == mibloclen)
+ ++sub2->end_a[range_subid - 1];
res = netsnmp_subtree_load(sub2, context);
sub2->flags |= SUBTREE_ATTACHED;
if (res != MIB_REGISTERED_OK) {
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
Net-snmp-coders mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
