>That's the table that Frithiof was asking about. Hence the >RFC 2096 version of this MIB (as shipped with the Net-SNMP >distribution) doesn't cover all the objects in the new >(experimental) MfD-style code.
The latest "ip-forwarding-mib" that *I* could find, is "draft-ietf-ipv6-rfc2096-update-07.txt". "Diff'ing" the MIB extracted from this document and the IP-FORWARD-MIB.txt shipping with net-snmp 5.2.1 reveals that the difference is Whitespace. They indeed got the same release data in the MIB and inetCidrRouteTable is defined. So the tools should know what to expect and how to display it. If i do a snmpget on one of the "overlong OID's", i can retrieve the same value as the "snmpwalk" can. If i do an snmpget further up the tree such as "ip.24.6"/"ip.24.6.0" (inetCidrRouteNumber), I get "No such object on this agent at this OID". Looking with "ethereal" is see the same overlong OID's as those shown by snmpwalk. Since "ethereal" A.F.I.K. do not care about MIB's, I think that it is the Agent that is broken and that it is somewhere where the mapping from OID to Data takes place and --enable-ipv6 has something to do with it - i.e. the Data overwrites something and ends up in the OID. Is there a guide to running a debugger on the Agent somewhere, the debugging dumps do not really give me much to go by? ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
