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 > > > > > --- [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 -- Fred -- [EMAIL PROTECTED] -- place "[hey]" in your subject. There are inflows and outflows -- and you're just a little node. Know then, what transcendental sets have you. _______________________________________________ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
