FTP Download issues (was: Destination show up twice in traceroute)

[bscott at ntisys.com]

> Speaking of NAT issues, I've got one which is driving me nuts.
> 
> Simple FTP downloads are failing to complete on my Linux box which is
> behind a firewall/NAT setup on a Linksys router.
>
> I have 6 or 7 computers behind the firewall, all sharing the same IP on
> the cable modem (Comcast).

  General fault isolation:

  Does the same problem happen on all hosts behind the LinkSys?

  Does the problem happen if you place a system outside the LinkSys,
directly on the cable feed?  (Be sure to take appropriate precautions (like
a host-based firewall) when you test this.)

> What happens is that the download dies part way through the download and
> just hangs. It always seem to hang at the same percentage, though the
> actual percent download varies from file to file.  ... In fact, typically
> I will download something to that remote server, then scp it in to my home
> workstation.

  What you describe sounds suspiciously like a data-dependent line problem.  
I've seen this kind of thing twice in about fifteen years.  It occurs when
there is some problem in a data line that is only triggered by a particular
bit pattern.  So you can pump data through it all day long and never have a
problem, but try to send a few dozen bytes of a particular pattern and it
gets scrambled.

  The reason I suspect this kind of problem is that you say it always
happens at the same point in the same files.  That would indicate something
at that point in the file is triggering the problem.  You also say that SCP
works.  Since SCP encrypts the payload, the lines don't "see" the pattern
that causes the problem.

  Most recently, this happened to me a couple of years ago at a client.  
They had an Internet feed that would drop packets if you tried to send a
packet filled with bit pattern

	10000001100000011000000110000001100000011000000110000001

(which corresponded to the capital letter 'A' in ASCII, repeated over and
over again).  It took forever to track down.

  To see if you are having the same problem, you need to use a packet
sniffer.  Start sniffing on the sending host, and then start your transfer.  
Wait until the sender stops getting ACKs back from the receiver.  Find the
first packet being sent that was *not* successfully ACK'ed, and look for a
data pattern.

  If you think you've found it, use the "ping" command, with the "-p" and 
"-s" switches to test.  For example, I used

	ping -s 300 -p 41 remote-host.example.net

to send packets padded with with 300 bytes of 0x41 (41 hex = 65 decimal =
'A' ASCII) to a remote host.

  Good luck getting this fixed on a consumer feed.  I had to provide
byte-level packet dumps and scream bloody murder and threaten to cancel the
feed, and even then the ISP only grudgingly looked into it.  And this on a
frame-relay line with a 4-hour response time in the contract.  You'll
probably need a signed note from God before Comcast does anything about it.

> Someone somewhere suggested the Linksys router might be suspect ...

  Well, I would certainly suggest testing that.  The problem could just as
easily lie in your equipment.  So make sure you've tried different
*everything* (routers, computers, cables, operating systems, brands of
network card, etc.) before you go blaming the ISP.  But the Principle of
Maximum Aggravation says that it will most likely be the ISP.

  Hope this helps,

-- 
Ben Scott <bscott at ntisys.com>
| The opinions expressed in this message are those of the author and do  |
| not represent the views or policy of any other person or organization. |
| All information is provided without warranty of any kind.              |