Re: MRTG 2.10 (fwd)

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