On Mon, Apr 09, 2012 at 10:06:52PM +0200, Jaap Winius wrote: > Package: libcurl3 > Version: 7.21.0-2.1+squeeze1 > > After upgrading to this version, none of the servers I maintain > displayed any problems except for one machine that uses an ADSL > broadband connection with RFC1483. > > Some years ago I managed to configure the modem/router involved (a > Thomson SpeedTouch 780i WL) to operate in a DHCP spoofing mode so > that its public IP address is passed on to its only client, a Debian > GNU/Linux server currently running squeeze. On the server, all I had > to do was add an extra NIC and give it a simple dhcp client > configuration. For the latter I use the dhcpcd package, although I > forget whether this is what allows me to run the isc-dhcp-server on > the other NIC, or that it's important for the DHCP spoofing trick > itself. > > Anyway , this worked fine for some years until the recent update for > libcurl3 and libcurl3-gnutls. For me, this update involved only > these two packages, and the event was followed almost immediately by > these error messages in the syslog: > > 1.) kernel: [5470349.890390] Neighbour table overflow. > 1a.) kernel: [5470359.920776] __ratelimit: 1766 callbacks suppressed > > Error 1a appeared regularly, once every 10 times for error 1. Six > hours after the update, I also started seeing this error in the > syslog: > > 2.) kernel: [527233.379270] nf_conntrack: table full, dropping packet. > > Whenever the error types 1 or 2 two would start, hundreds would > usually appear within the space of a few minutes and then stop. The > server is mostly quiet, but such events would occur several times a > day. > > Eventually I examined the arp table, which turned out to have far > too many entries. Instead of having just a few local IP/MAC address > combinations, it was full of public IP addresses. Only, in these > cases the MAC address was always the same -- I suspect it's the MAC > address of the nearby DSLAM, the IP address of which is the server's > default gateway. I tried a server reboot, but afterwards the arp > table quickly filled up and the errors continued. > > After downgrading libcurl3 and libcurl3-gnutls to version 7.21.0-2, > the error messages disappeared. For some reason the arp table did > not clear up, even after several days, so the server was rebooted > again and now it's fine. > > I don't know how, but it seems clear to me that the most recent > version of libcurl3 and/or libcurl3-gnutls introduced a bug that > only affects certain systems, such as the one described above.
It sounds pretty weird. How is libcurl used in this setup anyway (i.e. what
are its reverse dependencies installed)? Are those libcurl based applications
runned regularly? When was the last time you updated this system? Are you sure
the issue was really caused by the libcurl upgrade and not, say, by a temporary
issue in an unrelated software (i.e. can you you reproduce the problem if you
upgrade libcurl again in this moment)?
Cheers
--
perl -E'$_=q;$/= @{[@_]};and s;\S+;<inidehG ordnasselA>;eg;say~~reverse'
signature.asc
Description: Digital signature
