Hi List, as I am not sure if I may open a bug for this on sourceforge I want to present my problem on this list first. (This means that I already looked through the opened bugs and have not found anything appropriate)
I have noticed the following problem using a selfcompiled 5.4 (x86_64) under SLES9. When doing a bulkwalk on several (i.e. 10) OIDs using the SNMP.pm module on a Cisco Catalyst I am facing strange behaviour. For some OIDs I am getting all entries int the tree behind a specified base OID in bulkwalk return struct, but for some OIDs not all elements are included. I tracked down the problem by capturing the communication between both devices, and was able to find out what should cause the problem by taking a closer look in Wireshark. The agent on the Cisco Catalyst behaves as expected in the beginning, but suddenly, it resends an OID with an index that already has been sent, and then continues with the correct index. Here is a simplyfied example to make this behaviour more understandable. I do not include the other OIDs that are working correctly but I simply describe the order how the problem causing OID indices arrive. When I request .1.3.6.1.2.1.2.2.1.10 among other OIDs, the Catalyst is sending the results as follows: .1.3.6.1.2.1.2.2.1.10.1 .1.3.6.1.2.1.2.2.1.10.2 .1.3.6.1.2.1.2.2.1.10.3 .1.3.6.1.2.1.2.2.1.10.4 .1.3.6.1.2.1.2.2.1.10.2 .1.3.6.1.2.1.2.2.1.10.5 .1.3.6.1.2.1.2.2.1.10.6 .1.3.6.1.2.1.2.2.1.10.7 ... and so on. In the capture I can see that the catalyst sends information for the full tree behind .1.3.6.1.2.1.2.2.1.10. Net-snmp behaves correct, as it sends further requests to the agent as long as the tree behind .1.3.6.1.2.1.2.2.1.10 has not been fully retrieved. So all information should be in memory. But when I take a look at the result from the bulkwalk function in perl, I am only getting .1.3.6.1.2.1.2.2.1.10.1 .1.3.6.1.2.1.2.2.1.10.2 .1.3.6.1.2.1.2.2.1.10.3 .1.3.6.1.2.1.2.2.1.10.4 so the the internal processing when preparing the result in net-snmp stops at the point, the .1.3.6.1.2.1.2.2.1.10.2 is found the second time. Unfortunately this problem is only there for agents that do not send continuous elements in an OID tree, but do you see the possibility to handle this problem? I personally think this would make net-snmp more robust. If you need any further information (capture, code snippets, etc) don't hesitate to ask for it. Many thanks in advance Florian ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Net-snmp-users mailing list Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
