1. Home
  2. Digital Subscriber Line
  3. Reproduceable data dependent TCP checksum errors

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

formatting link
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.

Reply to
Orin
Loading thread data ...

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

Reply to
Scott Hemphill

And NNTP?

Here's a string of U's, as promised:

UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU

Scott

Reply to
Scott Hemphill
Reply to
Neil W Rickert

Yes but you provide no complete path to the file, thus no one can try to reproduce the error.

Billy Y..

Reply to
abuse

Here's one that fails:

formatting link
stopping after 1911066 bytes.

Orin.

Reply to
Orin

My mistake - the path was in what you posted earlier(!)

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 -

formatting link
if you want to see if that works any better for you.

Billy Y..

Reply to
abuse

Thanks!

I got 4626360 bytes from

formatting link
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.

Reply to
Orin

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.

Reply to
Orin

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..

Reply to
abuse

Here is one of my killer patterns. The ping is done from a different ISP:

ping -p 000000000000df7df3db00000000000000 -s 380

Over 90% of these get corrupted. Drop the size down to the default and around 20% get corrupted.

Orin.

Reply to
Orin

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.

Reply to
Orin

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.