On Tue, 27 May 2003, Simon Leinen wrote:
> 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. Well. this is clear, Simon. this was unprecise then: You should have understood: " MRTG, expecting strictly RFC 1157 can not dealing the situation a snmpd Agent is in violation of RFC 1157, because of faulty INET6 ?". Too long line. > > > 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. > Yes. It was on my projects too. > > 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. > Well, you have just said that you fixed it with the "lenient_source_addr..." slot ? So may be Lorenzo and Cia. had this slot with wrong value ? > If we want to provide the same workaround for IPv6 that we have for > IPv4, then we MUST use an unconnected datagram socket. Absolutely rigth. We must. > 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...)? > I tried it, but no result. I will try again, however. I may be wrong. Or we have to rewrite the way SNMP_Session calls the new INET6.pm I call it INET6-1.90 because it is not a rewriting of INET6-1.25 ... Summing: the problem , in general is, may be: - The INET6.pm (yes) if Lorenzo is rigth. - The "lenient:source_..." flag ? Default is value=1. I think we hould keep it with default = "0". - The way new SNMP_Session calls INET6 ? > Regards, > -- > Simon. > -- Unsubscribe mailto:[EMAIL PROTECTED] Help mailto:[EMAIL PROTECTED] Archive http://www.ee.ethz.ch/~slist/mrtg-developers
