[mrtg-developers] Re: MRTG 2.10 (fwd)
Rafael Martinez Torres
rafael.martinez at novagnet.com
Tue May 27 15:09:46 MEST 2003
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,
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
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
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 ?
Unsubscribe mailto:mrtg-developers-request at list.ee.ethz.ch?subject=unsubscribe
Help mailto:mrtg-developers-request at list.ee.ethz.ch?subject=help
More information about the mrtg-developers