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

Fred puissante at lrc.puissante.com
Tue Jul 6 17:10:01 EDT 2004


Mkie & Ben, thanks for the suggestions.

I was hoping for a "simple" solution, one that would not involve me
spending a whole day doing a "bug" hunt. Yes, I should try this from
different computers and the like.

Mike, your MTU problem may be related to what I am seeing, though I'm
not using PPPoE. Something somewhere in the path must be getting hung up
on packet sizes or related. Ben, your data-dependent line problem may be
playing a role, too.

At least I have two new avenues to attack this issue on now. I just wish
I had more time to pursue it. Come to think of it, I am having another
wierd problem, this one involving an ssh connection being used by CVS
connecting to a server on the LAN, but through an external IP address,
which may be related. Doing a traceroute points it directly to the
Linksys router, which is doing port forwarding to one of my Linux boxes.
Hmmm... perhaps I should just junk and replace it. I've had other weird
problems with it before. I've already relieved it of handling DHCP,
because it couldn't do that AND handle a high packet throughput at the
same time.

Thanks again.

-Fred

On Tue, 2004-07-06 at 09:58, Michael Nolin wrote:
> 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
> _______________________________________________
> gnhlug-discuss mailing list
> gnhlug-discuss at mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
-- 
Fred -- fred at lrc.puissante.com -- place "[hey]" in your subject.
There are inflows and outflows -- and you're just a little node.
Know then, what transcendental sets have you.



More information about the gnhlug-discuss mailing list