Re: I hate the net-snmp library

[Jeff Bailey]

On Tue, 2002-04-23 at 23:42, Jamshed Kakar wrote:

> > I'm thinking of a nice starting set of wrappers:
> > 
> > try {
> > snmp_connection foo = new snmpv1_connection("server", "community");
> > } catch { // Various can't connect errors;
> > }

> What exactly would this do?  Or what would you do once you had the
> connection?

SNMP is a two mode protocol.  In this case we're only interested in the
first mode, which is request->response.  There is exactly 0 or 1
responses per request that gets sent.

We probably need to take a step back in the explanation to go over how
SNMP works.

ASN.1 (or Aggrivating, Stupid Notation - 1^A^K^KAbstract Syntax
Notation) is a notation that allows you to define communications using
Object IDs (OIDs).  This is a hierchical tree where branches may never
contain data.

MIBs (Management Information Bases) provide a schema for this tree. 
They both turn OIDs into words, and also allow you to know the type of
data that can be returned.

Generic structure, and details on all of the is provided by the SMI
(Structure of Management Information) RFC.

A PDU is the message that gets sent back and forth.

(I haven't got it all straight in my head yet, and having to cross
reference four documents isn't helping.)

As an example, When working with a device, I can ask it:

.1.3.6.1.2.1.1.3.0, and it will answer with a "Timeticks" giving me the
uptime.

Those translate into:

.iso.org.dod.internet.mgmt.mib.system.sysUpTime.sysUpTimeInstance

Because of the way the protocol is done, we are not guaranteed a
response (although it's pretty likely.  Have you worked with UDP yet?)

> What kind of things do we need to represent?  I'm assuming some kind
> of device hierarchy- in fact, you could probably build a map of the
> network using a composite tree.  This is potentially a bad solution if
> you intend to have lots of different interfaces to devices.  At this
> point my assumption has been that a generic interface to devices will
> have to be created.

Because devices can implement their own mibs, I think we'll always need
access to a direct SNMP interface for the hairier questions.  I think
the generic interface can be implemented in terms of the specific one.

Also, until I have code down to a second interface, I think it's
unlikely that I'll be able to accurately predict a generic one.

> > I'm not sure yet how to handle an snmpwalk type of sequence, but I
> > think I'd like it to be something like it either returning a list<pdu
> > *>, or something.  Suggestions?

> Building out the composite tree would be easy to cook up quickly if
> nothing else.  A tree is also much more descriptive than a list.  If
> you intend to keep these structures for a long time AND want to view
> the data in a particular way it wouldn't be hard to build observers to
> watch changes in the tree and update indexes.

I need to store the mib data in a tree.  The problem with ASN.1 is that
it's a plain text frequently syntactically inaccruate form.  Most
projects wind up creating a MIB compiler to ease the parsing
requirement.

My original plan was to use Guile as the target of this compiler, so
that it would load it into a tree structure that I could load/unload and
easily edit.  Two problems 1) I don't have a good scheme algorithms
book, so I don't know how to usefully do a composite pattern there (And
don't have the weeks to spend experimenting with it) 2) Then I'd have to
write an ASN.1 parser.  And right now I'd rather pull out my eye teeth.

So far, I've been working with a limited set of devices (almost all the
information I need can be found in less than 100 oids), so I'm hard
coding.  That'll need to change sometime, but for now it's okay.

Where was I going with this?  Oh yeah.

I can send a request synchronously (with a timeout) or asynchronously. 
So far I'm working with synchronous requests, so I want a simplified
wrapper that allows me to request an OID, and get the response, or an
exception.  Everything else is details, and shouldn't be part of the
story.

Does that help?

Tks,
Jeff Bailey