HI, It would be really cool if there was a file that had translations between transport addresses and engineIDs (and contain engineBoots, and a timestamp that could be used to compute engineTime). Instead of probing, the values from this file would be used. If a failure occured, due to engineID change, then the user should be told. If there was not an entry, then the user should be told, and the entry added to the file.
This type of functionality is very much how SSH works today with the SSH server "fingerprint" of the SSH server's public key. In the future when both ends are authenticated, I believe that it is even more important to know if the SNMP agent's identity changed. And possibly interesting that engineBoots changed. On Tue, 19 Apr 2005, Dave Shield wrote: > DS> What would be the implications of defaulting to "DONT_PROBE"? > RS> Besides the hissy fits from Wes and Dave on breaking backwards > compatibility. > > Who said anything about breaking compatibility? > > All I asked was what the implications would be about moving the > engine probe later (when the request was ready to be sent) > rather than earlier (possibly before the session credentials > had been properly established). > > IIUC, setting DONT_PROBE would mean that the initial snmp_open() > would succeed, returning a session data structure (though without > the remote engineID and related info). > > Then, when that session was used to send an SNMPv3 request, > the library would spot that there wasn't a valid engineID, etc, > and probe for this information, before sending the request as > before. > > OK - that would introduce a slight delay at the point of the > first request, rather than having the same delay when the > session was first opened. But it's the same overhead, just > at a different point. And it would make opening the session > significantly more consistent and reliable. > > Now I may well have misunderstood how all this actually works. > Which brings us back to my original question: > > > DS> what's the purpose behind sending the > > DS> probe at this point (opening the session) rather than > > DS> later on (when it's actually used) ? > > (That's a request for information, not the start of an argument!) > > > The original patch for delaying the probe (submitted against 5.0.9) actually > > did do just that, and changed the semantics of the return code from > > snmp_open > > so you could tell if the probe failed. Maybe we could do something like > > that in > > a newly define netsnmp_open... > > Well, snmp_open returns the session data structure, doesn't it? > So you can tell whether the probe failed by looking at the engineID > field. If it's non-empty, then the probe succeeded (and this is > the remote engineID). If it's zero, then the probe failed. > Or am I wrong? > > Dave > Regards, /david t. perkins ------------------------------------------------------- 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 Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
