Re^3: SNMP from script conflicts with snmpwalk

If your IP addresses are getting jumbled up you now have to ask yourself: "are all my values that are returned on the same row?"

If it is at all possible that particular rows have a field missing then your individual column getnexts are going to get out of sync.. you may be retrieving share name for row 12 while retrieving comment for row 15.

To guard against this you are going to have to harvest the last integer from the OID of each column and ensure they are all the same. (The last OID of each column is the row number, or more accurately, the index of the row.. actually the index might be an IP address and consist of many integers.. The only right way to obtain the row number is to strip off the leading digits that match the OID of the variable you are getting - confused yet?).

ie. let's say you have an object called myEnglishCol with OID 1.3.6.1.7.1.3 and an object called myFrenchCol with OID 1.3.6.1.7.1.4.

You then do a getnext on these two objects and you get back the following:

  getnext( "1.3.6.1.7.1.3", "1.3.6.1.7.1.4" );

  1.3.6.1.7.1.3.14.15.16 - "Hello"
  1.3.6.1.7.1.4.14.15.16 - "Bonjour"
[download]

.. in this situation you are returned row "14.15.16" for both the myEnglishCol and myFrenchCol objects.

Now let's say you do a getnext on this:

  getnext( "1.3.6.1.7.1.3.14.15.16",
           "1.3.6.1.7.1.4.14.15.16" );

  1.3.6.1.7.1.3.14.15.17 - "Goodbye"
  1.3.6.1.7.1.4.14.15.19 - "Non"
[download]

.. clearly something has gone wrong. Maybe there was no translation available for the word "Goodbye" so there is no myFrenchCol.14.15.17 object. Because the two row numbers (14.15.17 and 14.15.19) don't match up you should consider rejecting this whole row. Your next attempt at a getnext should be:

  getnext( "1.3.6.1.7.1.3.14.15.17",
           "1.3.6.1.7.1.4.14.15.17" );

  1.3.6.1.7.1.3.14.15.19 - "No"
  1.3.6.1.7.1.4.14.15.19 - "Non"
[download]

So you might want to consider using OIDs directly in your code instead of "magic" auto-MIB interpreting stuff. You might want to do something like:

  my $myFrenchCol = '1.3.6.1.7.1.3';
  my $myEnglishCol = '1.3.6.1.7.1.4';

  my $row = "";
  while ( 1 ) {
    my ( $rF, $rE ) = getnext( $myFrenchCol . $row,
                               $myEnglishCol . $row );

    if ( $rE =~ m/^$myEnglishCol(.+)$/ ) {
        $row = $1;
        if ( $rF !~ m/^$myFrenchCol($row)$/ ) {
            print( Results on different rows\n";
            next;
        }
        # match! process results.. and continue
        next;
    } else {
        # got something funny back, maybe run out of rows
        last;
    }
  }
[download]

Whilst SNMP is a simple protocol to implement, it's not so simple to use.. you have my empathy.

Comment on Re^3: SNMP from script conflicts with snmpwalk Select or Download Code

Replies are listed 'Best First'.
Re^4: SNMP from script conflicts with snmpwalk by bowei_99 (Friar) on Nov 15, 2005 at 01:38 UTC
I see. So, even though the output from snmpwalk turns out OK, I still get erroneous results when autointerpreting MIB values. So for that reason, it would be safe to use OIDs instead names? If so, it seems odd that snmpwalk returns what I expect, but perl returns another. For example, when I run the script, I get: `q - "A6_1640_cn", comment - q - "D1_319_CN3", comment - "" q - "130_1016_4+", comment - "61.134" q - "130_1035_4+", comment - "61.116"` [download] So, it seems that the script is seeing blank values for the first two queues, and is getting messed up. However, when I check those values using snmpwalk, things are what I expect: [burvil@localhost printer-list]$ foreach p ( A6_1640_cn D1_319_CN3 ) foreach? snmpwalk server-ip-address public .1.3.6.1.4.1.77.1.2.27.1.1 +\| egrep $p foreach? end enterprises.77.1.2.27.1.1.10.65.54.95.49.54.52.48.95.99.110 = "A6_1640 +_cn" enterprises.77.1.2.27.1.1.10.68.49.95.51.49.57.95.67.78.51 = "D1_319_C +N3" [burvil@localhost printer-list]$ foreach p ( 10.65.54.95.49.54.52.48.9 +5.99.110 10.68.49.95.51.49.57.95.67.78.51) foreach? snmpwalk server-ip-address public .1.3.6.1.4.1.77.1.2.27.1.3 +\| egrep $p foreach? end enterprises.77.1.2.27.1.3.10.65.54.95.49.54.52.48.95.99.110 = "57.13" enterprises.77.1.2.27.1.3.10.68.49.95.51.49.57.95.67.78.51 = "61.88" [burvil@localhost printer-list]$ [download] Somewhat annoying, since one of the main reasons I chose SNMP over Net::SNMP or SNMP_Session was because it could parse MIBs, allowing me to write (in theory at least) more maintainable code.	[reply] [d/l] [select]
Re^5: SNMP from script conflicts with snmpwalk by monarch (Priest) on Nov 15, 2005 at 02:07 UTC
I haven't used SNMP, I've only ever used Net::SNMP myself.. But it appears that you must be calling getnext in an invalid manner. Try breaking down the problem a little. Firstly, use 'getnext' on 'svPrintQName' only. Then identify the row number that is returned to you (in the above examples you were returned `10.65.54.95.49.54.52.48.95.99.110` and `10.68.49.95.51.49.57.95.67.78.51`). Then perform a 'get' on the 'svShareComment' object with the rowID that you just extracted from the result of 'getnext svPrintQName'.. The `snmpwalk` command line tool is showing you that the SNMP Agent you're querying has the results you want, so it's a matter of digging through the documentation you have for the module you're using and learning how to use it correctly.	[reply] [d/l] [select]