[mrtg] Re: Bug in SNMP_Session 0.79 on FreeBSD (fwd)

Tobias Oetiker oetiker at ee.ethz.ch
Fri Nov 3 12:26:01 MET 2000

so if you are on freebsd you might want to upgrade snmp session


 ______    __   _
/_  __/_  / /  (_) Oetiker, Timelord & SysMgr @ EE-Dept ETH-Zurich
 / // _ \/ _ \/ / TEL: +41(0)1-6325286  FAX:...1517  ICQ: 10419518 
/_/ \.__/_.__/_/ oetiker at ee.ethz.ch http://ee-staff.ethz.ch/~oetiker

---------- Forwarded message ----------
From: Simon Leinen <simon at limmat.switch.ch>
To: Bert Driehuis <driehuis at playbeing.org>
Cc: cricket-users at lists.sourceforge.net, Tobias Oetiker <oetiker at ee.ethz.ch>
Date: 02 Nov 2000 15:30:58 +0100
Subject: Re: Bug in SNMP_Session 0.79 on FreeBSD


thanks for the explanation, which allowed me to (hopefully) fix this
long-standing problem in SNMP_Session.  Please try the current version
(0.80) from the Web page (http://www.switch.ch/misc/leinen/snmp/perl/).

>>>>> "bd" == Bert Driehuis <driehuis at playbeing.org> writes:
> The origin check that was added in SNMP_Session 0.79 breaks
> SNMP_Session on FreeBSD (and probably all BSD derivatives that have
> sin_len).

Just for the record... the origin check was supposed to be in the code
for a long time, but I had to disable it, probably because some
(FreeBSD) users had problems with it.  When I worked on the code
recently, I had forgotten about that problem and re-activated the old

> The problem is that Socket.pm's pack_sockaddr_in and recv(2) aren't
> consistent in filling in the sin_len field (leaving it as zero is
> equivalent to setting it to 16 for AF_INET sockaddr's, so some code
> doesn't bother to do it consistently). However, binary comparing the
> sockaddr_in's results in all incoming packets to be dropped. To make
> this even more confusing to the user, if debug is enabled, this
> results in "Response came from [].161, not [].161"
> messages.

> I'm not sure what the best way of dealing with this is. Probably
> unpacking the sockaddr_in's and comparing the addresses and
> ports.

This is what I'm doing now.

> However, the attached diff will act as a stopgap (it is not
> computationally expensive, but it is ugly).

> The problem is rather bewildering for someone who just downloads
> SNMP_Session as a required module for MRTG or Cricket, so I'd
> suggest at least releasing a 0.79a with this stopgap or fix.


Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
Archive     http://www.ee.ethz.ch/~slist/mrtg
FAQ         http://faq.mrtg.org    Homepage     http://www.mrtg.org
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi

More information about the mrtg mailing list