On 1/12/2011 4:45 a.m., Fredrik Eriksson wrote:
On 11/30/2011 02:06 AM, Amos Jeffries wrote:
Data packet from Squid->Server. 1085 bytes. Well under both 1160 and
1460 sizes, even with TCP packet bits added.
However the packet checksum is incorrect.
This is a problem in the kernel code somewhere. Given that it works on
the same box with older Squid it is likely something to do with the
IPv4/IPpv6 v4-mapping features of the kernel. Squid-3.1 prefers to use
"v4-mapped" IPv6 sockets and let the kernel swap the TCP stacks around
depending on the IP address type connected to.
I'm not entirely sure what you said here, but I tried to pursue the
issue further based on this having to do something with the kernel and
perhaps IPv6.
Ah sorry. In short I think its a kernel bug in the TCP / IP support.
On the old squid2 server, running debian etch, we have linux
2.6.18-6-686. To make sure, I installed squid 2.7.STABLE9-2.1 on the
squid3 server, changed the http_port, to be able to run both at the
same time, and verified that we could indeed access www.usitc.gov from
the same host running a 2.x version of squid.
After that I have tried both changing linux from 2.6.32-5-amd64 (from
debian stable) to 2.6.38-bpo.2-amd64 (from squeeze-backports) as well
as completely disable IPv6 on the host. We don't use IPv6 and have no
IPv6 connections to the outside world, but the interfaces did, of
course, have link-local addresses, however, disabling IPv6 did not
make any difference to the state of not being able to access the site.
Is there any other information I could provide you with? To my
knowlege, this is the only site we are having these problems with.
I hate to say this, but if all else fails you will probably need to
--disable-ipv6 in Squid to get back to the IPv4-ony behaviour Squid-2
had. That wont exactly solve the problem, but should avoid it.
Amos
