hi dave,
ok, i installed 5.1.2.rc2, i'm still seeing the same issue.
guru> snmpget -V NET-SNMP version: 5.1.2.rc2 guru>
here are some details.
for grins, i verified that the translate function is working in both the command-line utility and SNMP.pm:
guru> snmptranslate -On -IR portOperStatus.1 .1.3.6.1.4.1.9.5.1.4.1.1.6.1 vishnu> snmptranslate -Onf -IR portOperStatus.1 .iso.org.dod.internet.private.enterprises.cisco.workgroup.ciscoStackMIB.portGrp. portTable.portEntry.portOperStatus.1 guru>
guru> cat test #!/opt/vdops/bin/perl
use strict; use warnings; use SNMP;
my $obj = "portOperStatus.1"; my $oid = SNMP::translateObj($obj); print "oid = $oid\n"; guru> ./test oid = .1.3.6.1.4.1.9.5.1.4.1.1.6.1 guru>
and then i turned to your suggestion. here is a snippet from the ethereal trace, taken running my script as designed:
Source Destination Protocol Info 140.107.74.123 140.107.50.5 SNMP GET ccitt.1 140.107.50.5 140.107.74.123 SNMP RESPONSE ccitt.1 140.107.74.123 140.107.50.5 SNMP GET ccitt.2 140.107.50.5 140.107.74.123 SNMP RESPONSE ccitt.2
this of course is the same behavior i saw under 5.1.2pre2.
and here is a snippet taken when running my script as modified in the way you suggested, i.e. asking for ".1.3.6.1.4.1.9.5.1.4.1.1.6.1.99" instead of "portOperStatus.1" and "portOperStatus.2".
Source Destination Protocol Info
140.107.74.123 140.107.50.5 SNMP GET iso.3.6.1.4.1.9.5.1.4.1.1.6.1.99
140.107.50.5 140.107.74.123 SNMP RESPONSE iso.3.6.1.4.1.9.5.1.4.1.1.6.1.99
140.107.74.123 140.107.50.5 SNMP GET iso.3.6.1.4.1.9.5.1.4.1.1.6.1.99
140.107.50.5 140.107.74.123 SNMP RESPONSE iso.3.6.1.4.1.9.5.1.4.1.1.6.1.99
what do these results tell you? if you can think of additional ways in which i can dig into this issue, please let me know.
--sk
On Wed, 21 Jul 2004, Dave Shield wrote:
if you look at packet #15 in the 'good' snoop trace, you can see that what appears on the wire is ".1.3.6.1.4.1.9.5.1.4.1.1.6.1.1" (portOperStatus.1.1), i.e. the OID which this script wants.
yet, if you look at packet #15 in the 'bad' snoop trace, you can see that what appears on the wire is "0.1" (ccitt.1)
Actually, looking at the packet dump, the OID that's being requested in the 'bad' trace is actually "1" (i.e. "iso"), but I suspect this may be a red herring. Because the following request appears to be asking for "2".
What I suspect is happening is that the 'bad' requests are just taking the last subidentifier from the intended OID - i.e. the second instance value. It is possible to tweak the script to request a (deliberately bogus) OID, such as ".1.3.6.1.4.1.9.5.1.4.1.1.6.1.99"
If I'm right, then the 'bad' trace will attempt to ask for ".99" (which isn't actually a valid OID, so building the packet may well fail anyway)
Dave
------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ 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
