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
Received on Sat Feb 04 2012 - 02:40:40 MST
This archive was generated by hypermail 2.2.0 : Sat Feb 04 2012 - 12:00:02 MST