On Tue, 2005-04-19 at 19:27, mark kaplun wrote:
> What is the point of sending an snmpv3 GET to an agent which does
> not support snmpv3?
There isn't any point in doing that, no.
But we're not really talking about sending a request. At least,
not from the point of view of the application developer.
The basic job of snmp_open() is to provide a session structure,
ready for later requests. It probably needs to know "where"
the requests are going to be directed, but it doesn't actually
need the SNMP version, user, passwords and all that gumph.
They're not strictly relevant until the request is actually sent.
So in principle, I should be able to do:
snmp_sess_init( &sess );
sess.peername = "this.agent";
ss1 = snmp_open( &sess );
sess.peername = "that.agent";
ss2 = snmp_open( &sess );
ss1->version = SNMP_VERSION_1;
ss1->community = "public";
etc, etc
ss2->version = SNMP_VERSION_3;
ss2->user = "me";
etc, etc
and then use 'ss1' and 'ss2' to communicate with the two
agents. That works with ucd-snmp (where the default version
is SNMPv1). But with a default build of net-snmp, then
ss1 = snmp_open( &sess );
may well fail, if "this.agent" doesn't actually speak SNMPv3.
> maybe I'm mistaken but isn't it the same as resolving
> the dns address when openning a session?
You can certainly look at it that way - particularly if
you're happy to set everything up before calling snmp_open.
But I stumbled across this problem when I was trying to
document SNMP client programming. The cleanest way of
describing the process of preparing a request was:
- set up "where" you want to communicate with
(agent address, and call 'snmp_open()')
- set up "who" is communicating
(version, user, community, etc)
- set up "what" you're communicating
(snmp_pdu_create, etc)
I'd started working with the UCD library, where this clean
separation worked fine (since 'snmp_open' didn't do any probing).
It was a bit of a shock when I came to check it against the
v5 releases, and discovered that the snmp_open failed.
So I ended up having to mix the "where" and "who"
configuration, *before* calling snmp_open.
It's not a major problem, which is why I didn't press the issue
very hard when I got minimal response. But it would be cleaner
IMO, if the library didn't have this version dependency at all.
I'd like to see our toolkit as foolproof as possible.
The more ways there are to break things, the more traffic there'll
be on the lists!
Dave
-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
