On 2/02/2012 3:55 a.m., Fredrik Eriksson wrote:
Hi,
I just wanted to follow up on this one.
We ran into other issues that required a local backport of the squid3
package anyway, so I took the opportunity to build a package without IPv6
support (--disable-ipv6). Also, IPv6 support is switched off on the squid
server itself.
On 12/01/2011 01:13 PM, Amos Jeffries wrote:
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.
Unfortunately, this didn't work. I get the same incorrect checksums from
the squid server as earlier. We have no iptables, or similar, at this
server.
FWIW I'm running the Wheezy kernels here with no such problems.
I take it you managed to access both hts.usitc.com and www.usitc.com and
that there was no packet with an incorrect checksum being sent from the
squid box. I've tried stable, backports and testing kernels, with IPv4
turned off, together with --disable-ipv6 built squid3, without success.
Hmm. Packet checksums are the TCP stacks business. Squid has nothing to
do with those. At worst I thought it might be a stack problem triggered
by Squids use of IPv6. Could be as low level as the NIC itself (happened
to someone a few years ago, but with more "random" effect than this).
I have been testing those sites from a FreeBSD 4.7 and Debian Wheezy
(3.0, 3.1, 3.2 kernels), just tried again with the latest 3.2.0.2 kernel
(still no problem visible here). FWIW the last checksum issues I heard
about in the netfilter lists was for kernel 2.6.36/38 or so. Which might
affect squeeze, but not wheezy.
But beyond what you have already tried I'm stuck for ideas myself now.
Good luck.
Amos
