The Wallaces

TCP/IP MTU (Max Transmission Unit): Diagnosing a Packet Delivery Problem

(posted 10/21/2005) - MTU can be a key variable in TCP/IP network connection anomolies. Not because it's set 'wrong' in the client machine, but because network servers and home LAN products may be configured in so many ways.

Following are the facts concerning an internet upload problem and a wireless LAN data transfer problem that were resolved by adjusting the clients' MTU.

When I began using a Dlink 714+ integrated Router/Wireless Access Point I immediately noticed that when I tried to upload large image files to certain webservers via HTTP protocol (eg. Ofoto and Snapfish) I invariably got 'zero length file' errors from the server, or client side timeouts.

I also noticed that while I could connect and view shared directories and other devices among clients on my wireless LAN, sessions often failed with timeouts when the transfer required TCP/IP transactions over a couple of kilobytes in size.

After a little research I realized that a fundamental problem existed in which the internet endpoint (on WAN) and the Wireless endpoints (on LAN) were not receiving the source's packets, while the source was not always receiving ACK(nowledgements) for packets sent.

Not being a network protocol expert, nor having at my disposal a network protocol analyzer (and having no desire to learn how to interpret its output), I scoured the internet for reports of similar experiences. I found a surfeit of similar complaints and many folklore based remedies.

From my readings, I came away with the following simple procedure which can be performed by a non-techical but patient network user experiencing TCP/IP problems over a LAN or LAN/WAN.

Assumptions:
You have network connectivity and can ping a remote host but at a transactional level (eg. file transfer via HTTP) you get 'zero length file' or timeout errors.

It is also generally true, and assumed here that the client machines do not use Path MTU Discovery (a handshake for discoverying the proper MTU over a given route dynamically). You can verify this setting via the GUI utility mentioned below. For further informatin see a PMTUD Tutorial.

Other Tools:
Download DR TCP for Windows products -- this freeware standalone executable utility is a GUI that will allow you to make MTU changes on your Windows OS client if your diagnosis leads you to that conclusion.

Diagnostic Procedure:
Open a command window (Run 'cmd' in XP; open DOSCMD program if pre-XP MS OS). The first test is to ping the name of the machine with which you are having problems. If you get 'Request timed out' then one of three things is true:

• The remote host is not online.
• The remote host is configured not to respond to a TCP/ICMP Ping message.
• The remote host never received the ping because an intermediate server in the network path was set up not to pass ICMP messages (blackhole syndrome).

Typically your ping test results in a 'reply from' the remote host, indicating the default 32 byte payload was received for each packet sent. You can now use ping to determine the largest unfragmented packet payload deliverable to the remote host.

ping -f -l payload-size-in-bytes hostname:

• -f indicates 'Don't Fragment' the payload into smaller packets,
• -l (that's l as in lima-bean) is followed by a payload number between 536 and 1472. I believe MS Windows uses MTU defaults (payload plus protocol headers) of 576 for dialup and 1500 for ethernet.

  If you are debugging on a Wireless/Broadband connection, assume Windows defaults to an MTU of 1500 for your adaptor, and work with ping payloads in the 1420 - 1472 range.

The purpose of the diagnostic is to determine the point at which a remote host first returns 'Packet needs to be fragmented, but DF set.' Start at 1420 and work up until that occurs. Now you know the largest packet that can be sent over that LAN/WAN route without deconstruction and reassembly into two packets.

Look for anomolous behavior by continuing upward till you reach 1472 (ethernet payload limit). My Dlink 714+ Router/ Access Point actually breaks down and stops responding for the interval -l >1439, -l <1472 for wireless clients! It pays to check these things.

The fact that an IP message encounters a server that must fragment it in two is supposed to be transparent to the sender when Path MTU Discovery is not enabled. The problem is, sometimes the fragmentation operation jinxes the forward delivery and the acknowledgemnts -- rather than debate the causes of the anomolous behavior a user can try to accommodate the network by reducing the packets they send to a size that never involves fragmenting -- by adjusting the MTU.

Obviously I don't know the details of these protocols, I'm just observing my experimental results and saying that I've been able to adjust my client's MTU to accomodate my LAN router/access point and WAN image server's anomolous behavior.

Happy Networking to you!