| Author |
Message |
Orin
Guest
|
 Posted:
Fri Dec 31, 2004 2:38 pm Post subject:
Reproduceable data dependent TCP checksum errors |
|
|
I'm having a strange problem with a data dependent error. Downloads of
certain files never complete. Tcpdump (or netmon or ethereal) show a
packet being received with a TCP checksum error. The retransmits of
this packet also have a TCP checksum error. If I try to download the
same file from a different mirror, it too stops in the same place with
a TCP checksum error. Attempts to restart the download hang
immediately with the first data packet having a TCP checksum error.
This happens with both ftp and http!
This is one thing that TCP can't handle. Sure the packet gets
retransmitted - many times - but every time it gets corrupted.
I went as far as getting a good copy of the file via a roundabout route
(an encrypted VPN connection) and comparing the data in the file with
that in the bad packet. A single byte at offset 0x1E0 in the packet
was 0x20 when it should have been 0x00. Every time.
Playing with the MTU sometimes helps - dropping it to 472 obviously
lets the above transfer restart as packets aren't 0x1E0 long. It
doesn't cure the problem though.
Hardware. This was first seen with a Westell 2200 on a Verizon DSL
line to a local ISP. It's running bridged ethernet only. I also tried
an older Westell Wirespeed. Same problem. Different computer
connected directly to the Westell. Same problem (no surprise, but when
the ISP started blaming my computers...).
The 2200 reports no errors. Verizon have checked the line, found no
errors and say it's clean.
So, anyone seen anything similar?
FWIW, I put an ethereal trace of a failure at
http://www.nwlink.com/~orin/Fail_new_modem This was a restart of a
failed http transfer. It gets the error on the first packet containing
data from the file, ie the first packet containing data after that
with the http 206 response and headers. It's a very short trace...!
Orin. |
|
| Back to top |
|
 |
Neil W Rickert
Guest
|
| Posted:
Fri Dec 31, 2004 3:20 pm Post subject:
Re: Reproduceable data dependent TCP checksum errors |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
"Orin" <orin.eman@gmail.com> writes:
| Quote: | I'm having a strange problem with a data dependent error. Downloads of
certain files never complete. Tcpdump (or netmon or ethereal) show a
packet being received with a TCP checksum error. The retransmits of
this packet also have a TCP checksum error. If I try to download the
same file from a different mirror, it too stops in the same place with
a TCP checksum error. Attempts to restart the download hang
immediately with the first data packet having a TCP checksum error.
This happens with both ftp and http!
This is one thing that TCP can't handle. Sure the packet gets
retransmitted - many times - but every time it gets corrupted.
I went as far as getting a good copy of the file via a roundabout route
(an encrypted VPN connection) and comparing the data in the file with
that in the bad packet. A single byte at offset 0x1E0 in the packet
was 0x20 when it should have been 0x00. Every time.
Playing with the MTU sometimes helps - dropping it to 472 obviously
lets the above transfer restart as packets aren't 0x1E0 long. It
doesn't cure the problem though.
Hardware. This was first seen with a Westell 2200 on a Verizon DSL
line to a local ISP. It's running bridged ethernet only. I also tried
an older Westell Wirespeed. Same problem. Different computer
connected directly to the Westell. Same problem (no surprise, but when
the ISP started blaming my computers...).
The 2200 reports no errors. Verizon have checked the line, found no
errors and say it's clean.
|
If this is a line problem, then it could conceivably be due to a
resonance. The particular data might generate a signal that happens
to hit that resonant frequency, and cause errors.
I once saw something similar with an older coax ethernet that had a
defective multiconnect on it.
Perhaps it could also be caused by a bad chip in telco equipment.
You seem to have ruled out equipment problems on your side.
You would really need to do some low level signal checking to see if
the problem is occurring at the DSLAM or the line.
Since DSL packages the data over the wire as ATM cells, there is
possibly a way that you can trigger the problem with a short message
that generates only a single cell.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.91 (SunOS)
iD8DBQFB1W4fvmGe70vHPUMRAsPTAKDw3nIb/OfXsVxmqRuaJWyEXrXXtwCguHR9
pHeBoKHC30PN0JwM7TGcf1o=
=zyO6
-----END PGP SIGNATURE----- |
|
| Back to top |
|
|
Guest
|
| Posted:
Fri Dec 31, 2004 8:17 pm Post subject:
Re: Reproduceable data dependent TCP checksum errors |
|
|
Orin <orin.eman@gmail.com> writes:
Yes but you provide no complete path to the file,
thus no one can try to reproduce the error.
Billy Y.. |
|
| Back to top |
|
|
Scott Hemphill
Guest
|
| Posted:
Sat Jan 01, 2005 1:15 am Post subject:
Re: Reproduceable data dependent TCP checksum errors |
|
|
"Orin" <orin.eman@gmail.com> writes:
| Quote: | I'm having a strange problem with a data dependent error. Downloads of
certain files never complete. Tcpdump (or netmon or ethereal) show a
packet being received with a TCP checksum error. The retransmits of
this packet also have a TCP checksum error. If I try to download the
same file from a different mirror, it too stops in the same place with
a TCP checksum error. Attempts to restart the download hang
immediately with the first data packet having a TCP checksum error.
This happens with both ftp and http!
This is one thing that TCP can't handle. Sure the packet gets
retransmitted - many times - but every time it gets corrupted.
I went as far as getting a good copy of the file via a roundabout route
(an encrypted VPN connection) and comparing the data in the file with
that in the bad packet. A single byte at offset 0x1E0 in the packet
was 0x20 when it should have been 0x00. Every time.
Playing with the MTU sometimes helps - dropping it to 472 obviously
lets the above transfer restart as packets aren't 0x1E0 long. It
doesn't cure the problem though.
Hardware. This was first seen with a Westell 2200 on a Verizon DSL
line to a local ISP. It's running bridged ethernet only. I also tried
an older Westell Wirespeed. Same problem. Different computer
connected directly to the Westell. Same problem (no surprise, but when
the ISP started blaming my computers...).
The 2200 reports no errors. Verizon have checked the line, found no
errors and say it's clean.
So, anyone seen anything similar?
|
About five years ago I had a data dependent problem with my SDSL link.
There were a few bit patters that had some trouble, but the one that
was guaranteed to fail was a string of capital 'U' characters. (The
bit pattern for ASCII 'U' is 01010101.) I first noticed the problem
when a string of U's occurred in a CD-ROM (.iso) image of a Red Hat
Linux release. I was able to work around the problem by continuing
the download via dial-up long enough to get past the problem, then
re-establish the DSL connection. Within a year or so, I noticed the
problem was gone, with no hardware/software changes on my end.
Just for grins, my next followup to this post will be a string of U's.
Scott
--
Scott Hemphill hemphill@alumni.caltech.edu
"This isn't flying. This is falling, with style." -- Buzz Lightyear |
|
| Back to top |
|
|
Scott Hemphill
Guest
|
| Posted:
Sat Jan 01, 2005 1:16 am Post subject:
A string of U characters |
|
|
"Orin" <orin.eman@gmail.com> writes:
| Quote: | I'm having a strange problem with a data dependent error. Downloads of
certain files never complete. Tcpdump (or netmon or ethereal) show a
packet being received with a TCP checksum error. The retransmits of
this packet also have a TCP checksum error. If I try to download the
same file from a different mirror, it too stops in the same place with
a TCP checksum error. Attempts to restart the download hang
immediately with the first data packet having a TCP checksum error.
This happens with both ftp and http!
|
And NNTP?
Here's a string of U's, as promised:
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
Scott
--
Scott Hemphill hemphill@alumni.caltech.edu
"This isn't flying. This is falling, with style." -- Buzz Lightyear |
|
| Back to top |
|
|
Orin
Guest
|
|
| Back to top |
|
|
Guest
|
| Posted:
Sun Jan 02, 2005 3:17 am Post subject:
Re: Reproduceable data dependent TCP checksum errors |
|
|
Orin <orin.eman@gmail.com> writes:
My mistake - the path was in what you posted earlier(!)
| Quote: | Currently stopping after 1911066 bytes.
|
Well, using NetBSD v2.0 and lynx I got the file ok, no
problem at all. It is currently sitting on that same
system at -
http://www.panix.com/~zippy/glibc-2.3.3.tar.bz2
if you want to see if that works any better for you.
Billy Y.. |
|
| Back to top |
|
|
Orin
Guest
|
| Posted:
Tue Jan 04, 2005 8:03 am Post subject:
Re: Reproduceable data dependent TCP checksum errors |
|
|
Thanks!
I got 4626360 bytes from
http://www.panix.com/~zippy/glibc-2.3.3.tar.bz2 before the dreaded tcp
checksum errors.
Now they want me to upgrade the firmware on the modem (it's aready at
the latest version that I can find) or try a different brand...
Yes, the path and host was in the ethereal trace, but I should have
posted it anyway...
Orin. |
|
| Back to top |
|
|
Guest
|
| Posted:
Tue Jan 04, 2005 3:50 pm Post subject:
Re: Reproduceable data dependent TCP checksum errors |
|
|
Orin <orin.eman@gmail.com> writes:
| Quote: | Now they want me to upgrade the firmware on the modem (it's aready at
the latest version that I can find) or try a different brand...
|
I'm using a Zyxel - it works well but it does get pretty warm, you can't
leave one on top of some other heat producing device - the combination will
get it too hot. They are also pretty cheap on ebay.
I also have a Netopia box - I would not recommend them not only because
has their support web site always sucked, now it has also been dumbed down
heavily and quite a bit of very useful info has been pulled. And replaced
with crap. They define "NIC" as the "National Internet Commission" for
example. Real confidence-inspiring stuff.
I can say neither of these has any crc-related problem with the very same
file though...
Billy Y.. |
|
| Back to top |
|
|
Orin
Guest
|
| Posted:
Wed Jan 05, 2005 12:04 am Post subject:
Re: Reproduceable data dependent TCP checksum errors |
|
|
I can get a Zoom locally cheap enough - I don't really expect it to
make a difference.
It was ironic that during my research, I couldn't download the Verizon
setup pdf from the Zoom web site. Better go grab it here at work!
Orin. |
|
| Back to top |
|
|
Orin
Guest
|
| Posted:
Sun Jan 09, 2005 12:42 am Post subject:
Re: Reproduceable data dependent TCP checksum errors |
|
|
Here is one of my killer patterns. The ping is done from a different
ISP:
ping -p 000000000000df7df3db00000000000000 -s 380 <my DSL IP>
Over 90% of these get corrupted. Drop the size down to the default and
around 20% get corrupted.
Orin. |
|
| Back to top |
|
|
Orin
Guest
|
| Posted:
Sat Feb 05, 2005 12:29 am Post subject:
Re: Reproduceable data dependent TCP checksum errors |
|
|
Update.
I managed to get a ping from an external ISP to the gateway to fail.
My ISP fixed this by re-routing the return path of these pings. Didn't
help my DSL of course.
Finally, a week ago, they replaced some hardware and life is good. No
more corruption.
Orin. |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in