2

I'm trying to write an SNMP agent and frankly the whole process has been like reading pooorly translated stereo instructions. But I'm close, except for one problem: implementing the GETNEXT operation.

Consider the following chunk of the system OID space:

.1.3.6.1.2.1 .1.5.0
             .1.6.0
             .1.8.0
             .1.9.1 .2.1
                    .2.2
                    .2.3

For definiteness, let's say that I want to do

 $ snmpwalk -On -v 2c -c public localhost .1.3.6.1.2.1.1.8.0

net-snmp implements this by first performing a GET on .1.8.0, followed by a GETNEXT. The GETNEXT should go from .1.8.0 to .1.9.1.2.1, then .1.9.1.2.2 and so on.

I recognize that this is conceptually merely a depth first walk, but for some reason -- age, perhaps -- I just can't figure out a clean way to implement that search when it has to find the GET node, then back up on the next call and find the "next" node.

Feel free to show me that it's foolishly simple.

Update

I wrote this after a 26 hour programming bout, so I can imagine it's not clear. Here's the question:

I need a function successor which takes an OID as input and returns the next OID -- where next is in depth-first order as implemented by SNMP tools. I've got a couple of solutions that work by enumerating the OIDs in depth-first order and waiting for the right one to come around, ; I'm looking for an elegant one thatis better than O(l+n) where l is length of the OID and n is number of OIDs.

Charlie Martin
  • 110,348
  • 25
  • 193
  • 263
  • Well, do you mean that you don't understand why Net-SNMP sends a GET message at the very beginning? I don't know either, as the snmpwalk in other toolkit (such as #SNMP) does not perform this extra GET. – Lex Li Jul 04 '12 at 06:09
  • That's another question, ie, how does something that's supposed to be a long established standard end up with so many mutually contradictory behavioors. – Charlie Martin Jul 04 '12 at 17:57
  • Unfortunately, walk is not part of the standard (none of the RFC documents emphasize on it compared to GET/GET NEXT/SET and so on). Therefore, for such a non-standard operation, vendors have the freedom to implement it differently. – Lex Li Jul 05 '12 at 03:36
  • Yeah, I'm getting that. Unfortunately, it means I'm trying to make this work by trying a collection of tools and trying to figure out the special cases. – Charlie Martin Jul 06 '12 at 04:06
  • You seem to be doing it the hard way. Have you tried the Net-SNMP MFD? The MFD will do all of that for you and the only thing you'd have to worry about is getting your data into the Net-SNMP data containers. http://www.net-snmp.org/wiki/index.php/MIB_for_Dummies – EhevuTov Aug 14 '12 at 19:14
  • Shouldn't be surprised. The big difficulty -- it's working now -- was that the command line snmpwalk and snmpbulkget command lines didn't match the way tools like Scotty work. I eventually had to get network traces and revearse engineer what was going on. – Charlie Martin Aug 15 '12 at 20:23
  • 1
    I'm not surprised you had a problem with this. I'm sure there are better solutions, but when I faced the same problem some years ago, I implemented the MIB as a Map (Java), which gives O(1) lookups. Of course, I needed a sorted view of the map, for the successor() function, which had to be re-sorted when variables were added (like new rows in a table), which cost time on the first get-next request after an insert. Later found Java's NavigableMap class, which solves the problem much better. – Jolta Sep 24 '14 at 08:26
  • In case it's not obvious from my previous comment, I think that the best solution is in choosing (or designing) a good data structure to store you MIB data, which enables both a constant-time variable lookup as well as reasonably fast successor search. – Jolta Sep 24 '14 at 08:44

1 Answers1

-1

Check each OID in the response PDU against the root OID you are walking. If you find a match, then you know to stop traversing the tree. If you don't find a match, send the next GET_MSG_BULK request PDU.

initzero
  • 852
  • 11
  • 13
  • Doesn't really answer the question, I think. Charlie was looking for the best way to find the successor of an OID on the agent side. Your answer applies when implementing the snmp walk operation on the manager side. – Jolta Sep 24 '14 at 08:15