bad tcp cksum

When resolving google.com, i get about six ip addresses back. Five of
those work perfectly fine, but with one, 216.239.59.104, i
always get bad tcp checksums, so the page never loads.

Now i've tried just about anything: different router, different
computer, different os (Linux, Windows, OSX), different cables,
different MTU and so on, but none of those steps solved the problem.

Is there anyway i can tell my computers that to use any ip for google,
except for the one that doesn't work?

eelco

"eelco" <(E-Mail Removed)> wrote in message
news:42c31886$0$60131$(E-Mail Removed)

> When resolving google.com, i get about six ip addresses back. Five of
> those work perfectly fine, but with one, 216.239.59.104, i
> always get bad tcp checksums, so the page never loads.
>
> Now i've tried just about anything: different router, different
> computer, different os (Linux, Windows, OSX), different cables,
> different MTU and so on, but none of those steps solved the problem.

http://216.239.59.104 works fine here on all those OS's.

ynotssor schreef:

>> Now i've tried just about anything: different router, different
>> computer, different os (Linux, Windows, OSX), different cables,
>> different MTU and so on, but none of those steps solved the problem.
>
> http://216.239.59.104 works fine here on all those OS's.

I bet it does, it should.

eelco

Hi.

We're having this problem also. We're using
SuSE Linux, with a 2.4 kernel. One strange thing
we've noticed: the reported checksum appears to
always be the same, namely hexadecimal FEEF.

Another odd thing is that when we look at the
packet with tcpdump and dump the contents, the
checksum *doesn't* appear to be FEEF after all.
In other words, some piece of software seems to
be getting confused about what checksum actually
appears in the TCP header.

Our records show that the machine in question
has been unable to make a HTTP connection to
the address you mention since at least the end
of April (this has been a long-running problem
for us, which is why we have records going back
so far).

http://www.DevPlug.com --Connecting Developers
Posted from: http://www.devplug.com/ftopic41589.htm