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:[EMAIL PROTECTED] Help mailto:[EMAIL PROTECTED] Archive http://www.ee.ethz.ch/~slist/mrtg-developers
