irritating connection issue
Oct. 25th, 2004 09:43 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
solarbirdSo I'm trying to download this file that the REST OF THE WORLD can download just fine, and I can't get past byte 2,031,357. Even wget contacting the server and asking for a resend from the failure point gets a 206 (okay, continuing from last point) and then - nothing, until it times out.
We're running into that kind of thing semi-regularly. It's REALLY annoying.
No proxies are involved, it's all fixed IP addresses, we're talking right upstream to our IP provider, we aren't losing connection to the host because a new connection works just fine - we move a boatload of data at 80KB/sec and then it just. stops.
Meanwhile, of course other people can get the item in question just fine.
It only happens with larger files. i don't know where there's a cutoff, if there is one. Huge files will transfer fine from one host and smaller large ones will fail from another host at the same time. Size and capability of the sender are irrelevant, as far as we can tell. (This has happened against tiny hosts and microsoft.com both, for example.)
Once (so far) if we left a wget running overnight, a file transfer "stuck" like this eventually worked. Trying it again later didn't work.
At least one person apparently has had the same kind of trouble downloading a large file from us. Other people downloaded it easily, but he couldn't pull it down on multiple retries. High rate streaming followed by complete shutdown.
I'm mystified. Help? Anybody?
We're running into that kind of thing semi-regularly. It's REALLY annoying.
No proxies are involved, it's all fixed IP addresses, we're talking right upstream to our IP provider, we aren't losing connection to the host because a new connection works just fine - we move a boatload of data at 80KB/sec and then it just. stops.
Meanwhile, of course other people can get the item in question just fine.
It only happens with larger files. i don't know where there's a cutoff, if there is one. Huge files will transfer fine from one host and smaller large ones will fail from another host at the same time. Size and capability of the sender are irrelevant, as far as we can tell. (This has happened against tiny hosts and microsoft.com both, for example.)
Once (so far) if we left a wget running overnight, a file transfer "stuck" like this eventually worked. Trying it again later didn't work.
At least one person apparently has had the same kind of trouble downloading a large file from us. Other people downloaded it easily, but he couldn't pull it down on multiple retries. High rate streaming followed by complete shutdown.
I'm mystified. Help? Anybody?
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2004-10-26 03:37 am (UTC)If so, you may need to reduce your MTUs (normally 1500) to 1492 or 1472 or smaller. On linux or MacOSX, the
ifconfigcommand will tell you what the current mtu setting is for a given interface (orip link showif it's Linux 2.4 or later); in windows it's a registry setting somewhere.I'll note that my current understanding of this is still somewhat vague --- and I need to work this out for my own situation since I'm being moved from a bridged to a PPPoE connection --- but here goes:
MTU is the largest IP packet that you can send without having to fragment it and is normally set at 1500. But in PPPoE, rather than slapping an ethernet header on the packet and sending it out, we first add on a PPP header (2 bytes) and then a PPPoE header (6 bytes), and then wrap all that in an ethernet header. Maximum ethernet packet size is fixed at the hardware-level.
IP packets can be arbitrarily large but at some point some gateway in the middle should be sending back ICMP thingies saying, "sorry, you need to fragment this," and then the IP layer is supposed to take care of splitting the IP packet up and recombining it at the other end.
The problem is when the sender thinks it's okay to send packets of a given size (since it's less than the MTU) but which, with PPPoE overhead, turn out to be too large for the hardware to deal with but at the same time are not large enough to send back the ICMP thingie (because the gateway MTU?/MRU?/something is misconfigured); hardware chokes and the packet disappears down a black hole, and endless retransmissions of it don't make any difference.
Never mind that certain ISPs/routers/modems helpfully block ICMP.
This is something that triggers on anything that creates large packets --- not necessarily large files --- streaming audio/video is evidently one of the prime offenders.
What I'm unclear on is
- why smaller settings than 1492 are sometimes necessary, eg., 1472 or 1452 --- the consensus seems to be that you keep trying smaller values until it works
- exactly where you need to do this (seems to me it should suffice if the gateways know what the real maximum size is -- but some things I've read suggest that if you reduce the MTU on the gateway then you also have to reduce the MTU on everything behind the gateway.
- how changing your own MTU is going to affect how MSN/CNN/whoever sends something
Here's the RFC that actually describes the problem (Path MTU Black Hole).We probably need to drag out
no subject
Date: 2004-10-26 06:34 am (UTC)This doesn't even have to be anything to do with your connection. If something upstream has a truncated MTU and some idjit is blocking the wrong ICMP, it'll cause this problem.
If you feel like being clever, some pinging with carefully controlled packet sizes will let you find the satanic node in question, but only if you can test both directions. Otherwise, you might be able to detect things one way.
no subject
Date: 2004-10-26 09:44 am (UTC)