[mrtg-developers] Re: MRTG 2.10 (fwd)

[Simon Leinen]

Rafael Martinez Torres writes:
> 3.- snmpd in violation of RFC 1157:
> 	Possible causes: module faulty INET6?.

This is bad reasoning.  NOTHING on the MRTG side can be a CAUSE for
the AGENT violating RFC 1157.

> 		Try alternative INET6.pm  (INET6-1.90).

> 	My experience:
> 		Original MRTG was ready even to handle different origin
> 		and source addresses.Hence, this violation was already in
> 		mind and must be kept.

I would claim that this is not that easy.

Initially, my SNMP_Session.pm code insisted that the responses came
from the same source address (IPv4) that it had sent the request to.

Then it was pointed out to me that some agents don't observe this
rule.  So, I suggested that the people with these problems contacted
their agent vendors to fix the problem.  Unfortunately, after several
such messages I was persuaded to add some code to make SNMP_Session.pm
more tolerant so that it can handle this type of brokenness in
agents.  This code is activated by setting the
`lenient_source_address_matching' slot to a non-zero value in the
SNMP_Session object.  Initially the default was zero, but nowadays it
is one, to reduce the number of support calls.

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/).

One problem though is that RFC 1157 is historic (but so is SNMPv1 :-).
It would be great if someone could find similar wording in one of the
SNMPv3 RFCs, even though SNMP_Session.pm (and thus MRTG) doesn't
support SNMPv3.

> 		Using INET6-1.90 does NOT solve the problem.
> 		INET6-1.25 (that from Debian) is NOT wrong. It runs well
> 		even on my patch.
> 		So, the problem must be in your SNMP modules...It is
> 		useless to track tcpdump.

The problem is in the agent.  And that can be proven by looking at
tcpdump.

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...)?

Regards,
-- 
Simon.

--
Unsubscribe mailto:mrtg-developers-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:mrtg-developers-request at list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/mrtg-developers