On fre, 2007-09-28 at 02:00 -0500, Chris Abbey wrote: > Hmm. So here's my problem with this. On the client side, I might not know > that I > need to use IPv6 to get to the server. Say all I know is that I need to send > traps to entrapment.example.com. Hand that name off to DNS and it only comes > back with an AAAA record (an IPv6 address). How is a script or a user calling > snmptrap to report something or query something supposed to know that they > need > to specify "udp6:" for this address?
Yes, this is a problem. For the special case of IPv4/IPv6 I think the best course forward would be to merge the two drivers into one, but in the general case I do not know how to do this, but on the other hand I think merge of IPv4 and IPv6 would handle 99.9% of all usages. > IPv4 doesn't seem to need the user to tell it to use udp, it seems to default > to > that. Any reason not to make the default switch to udp6 if dns returns *only* > an > AAAA record? (I'm not even going to go into the insanity that could result > from > trying to do both if DNS returns both an A and an AAAA address.) The problem is that the name lookup happens after the choice of transport at the moment. > It looks like a bit of code around line 380 of snmplib/snmp_transport.c might > be > the ticket to accomplishing that. In a way this is true, but that is realy kind of a wart on the system, it exists solely to make sure that some old special cases keep working. I think bug #1801793 is another angle on this very same problem, and the solution I proposed there with multiple default transports probably would work on this problem as well. > > actually does make snmptrapd receive and print the trap. > > Yup, technically it does work... just in a very user-un-friendly way. Well, yes, there is a potential to increase the usability. /MF ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
