Lorenzo Colitti writes: > Simon Leinen wrote: >> Now one could argue that agents that violate RFC 1157 are *still* >> broken, even in the IPv6 world, and that, since IPv6 support in agents >> is relatively recent, there would be better chances to get these >> agents FIXED. In particular the Net-SNMP agent (which seems to be >> what you are using on your Debian system) can be fixed relatively >> easily, by producing a clean documented patch and submitting it as a >> contribution (see http://net-snmp.sourceforge.net/). > But isn't such behaviour hard to achieve with the standard socket API? > Wouldn't you have to create a new socket, bind() and connect() it for > every incoming packet?
To me, the most difficult part seems to be to find out what was the *destination* address that has been used in a query datagram. You should check how BIND handles this. I think it bind()s a separate socket for each interface. I don't know how it handles interfaces with multiple addresses though (maybe the assumption is that different addresses will show up as separate logical interfaces). I do know that BIND has to somehow track interface additions and deletions (and address changes) over the lifetime of the process. So yes, this seems quite hard currently. > There is the advanced IPv6 socket api (rfc 2292), which allows you > to specify the source address with ancillary socket data (section 5) > but perhaps it's not supported on all platforms on which net-snmp > supports IPv6. RFC 2292 (and draft-ietf-ipngwg-rfc2292bis-09.txt, which will replace it at some point) also specifies a way to find out the destination address that had been used in a received datagram. So it looks as if with these new interfaces, it would probably be reatively easy to implement the required semantics. > Or am I missing something? >> If we want to provide the same workaround for IPv6 that we have for >> IPv4, then we MUST use an unconnected datagram socket. If I >> understand correctly, Lorenzo's and Valerio's code has to use a >> connected datagram socket for some reason - maybe this reason goes >> away when IO::Socket::INET version 1.25 is replaced by >> IO::Socket::INET6 version 1.26 (from your "INET6-1.90", hm, confusing >> versioning...)? > Yes, that's correct. If you call IO::Socket::INET6->new() but don't > provide a remote endpoint, the Debian INET6 module creates an > AF_INET socket(!). If you do provide a remote endpoint, it creates > an AF_INET6 socket, but then it calls connect(). For me this is reason enough to insist on using Rafael's INET6.pm (1.26/1.90). I have tried it and it doesn't seem to have that problem; i.e. you can call new() without a remote endpoint and get a socket object that can be used just as my code did for IPv4. So the lenient_address_matching code (which I don't like and don't think *should* be necessary, but obviously it still is if you have Net-SNMP agents, sigh) works again. I'm attaching my current SNMP_Session.pm which implements this (insist on INET6.pm version 1.26 and no longer specifies the remote address). Regards, -- Simon. -- Attached file removed by Ecartis and put at URL below -- -- Type: text/x-perl-script -- Size: 32k (33471 bytes) -- URL : http://www.ee.ethz.ch/~slist/p/03-SNMP_Session.pm -- Unsubscribe mailto:[EMAIL PROTECTED] Help mailto:[EMAIL PROTECTED] Archive http://www.ee.ethz.ch/~slist/mrtg-developers
