On Tue, 21 Jan 2003, Mark J. Scheller wrote:
The Linksys does have an MTU setting, and I've had my users try some lower settings to see if it made any differences. One user set the MTU on the Linksys as low as 1200 with no noticeable improvement.
If you're using path MTU discovery (in other words, sending out packets with the DF bit set), it works like this: The host on each end of the connection has an MTU configured in its TCP stack, so on initial connection (generally with very small syn/ack packets), the packet size gets negotiated and set to the lower of those two numbers. If all the router interfaces in between have an MTU equal or greater than the MTU that gets negotiated between the hosts, packets will continue to flow at that size without incident. In general, when you're dealing with two ethernet connected hosts with MTUs of 1500 bytes, and a bunch of routers in between with MTUs of greater than 1500, this is what happens. However, if there's a network link in the path with an MTU smaller than the MTUs of the two end devices, the large packets sent by the end devices won't be able to pass through that link. Instead, the router with the small MTU link sends an ICMP response back to the sending host, requesting smaller packets. The sending host retries with progressively smaller packets until arriving at a size that works. Therefore, I think the scenario that people are describing here is this: The user's computer is talking to the Linksys across a regular ethernet with an MTU of 1500. The host on your network probably also has an MTU of 1500. The Linksys is talking to the DSL provider via PPPoE, and thus has an MTU of 1492. The connection starts out with an initial MTU of 1500 in each direction, but 1500 byte packets can't pass through the 1492 byte MTU of the connection between the Linksys and the DSL provider. Therefore, the devices on the two ends of that link would be sending back ICMP messages requesting smaller packets. If all ICMP were being blocked somewhere, those ICMP messages wouldn't arrive, and the host that wasn't receiving them would keep obliviously sending out 1500 byte packets until the connection timed out. But, if you were plugging the client computers directly into the DSL line and running PPPoE on them, you'd have the 1492 byte MTU negotiated from the start and everything would work. In this scenario, decreasing the Linksys's MTU wouldn't help you, because the problem would already be that the MTU on the Linksys was smaller than the MTU on the end points. Decreasing the MTU on the end points would help. What would help even more would be fixing the ICMP filtering. Now that I've said all that, this scenario doesn't really fit what you're seeing. You said your packet sniffer showed no packets coming across, but TCP connections don't generally start out with 1500 byte packets. In general, when you see an path MTU discovery issue, you see the connection being successfully opened, small packets (containing such small bits of data as "GET /") flowing freely, and then the connection freezing when a big burst of data gets sent for the first time. Since that's not what you're seeing here, I'm more inclined to agree with those who have suggested upgrading the Linksys's firmware. I don't have any experience with that -- The Linksys NAT box on my home network works fine and I haven't had any reason to mess with it -- but it does seem like a far more plausible explanation for what you're seeing. -Steve -------------------------------------------------------------------------------- Steve Gibbard scg@gibbard.org +1 510 528-1263 http://www.gibbard.org/~scg