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 --- [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> > | 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 > [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
