Re: MRTG 2.10 (fwd)

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]?subject=unsubscribe
Help        mailto:[email protected]?subject=help
Archive     http://www.ee.ethz.ch/~slist/mrtg-developers