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

[Michael Nolin]

I've seen this behavior on PPP configured links. I
used ethereal to determine that each time the ftp
session sent a > 1452 byte frame it was dropped up
stream. A "Missconfigured" router/firewall was the
source of the problem. 

> Searching for "tcp 1452 size" I got the following
technical note from 
> cisco. 
> 
> 
> http://www.cisco.com/warp/public/794/router_mtu.html

This problem is common to many ISP's that have not
compensated for this bug. As well as other router
vendors that have stollen intellectual property bugs
and all. 

Mike

 


--- bscott at ntisys.com wrote:
> > 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.              |
> 
> _______________________________________________
> gnhlug-discuss mailing list
> gnhlug-discuss at mail.gnhlug.org
>
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
> 



		
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail