Strange MTU Problem

I run a small home network with two older Linux machines and an XP laptop.

Recently I ran a Windows network analysis tool and after testing various
URLs it reported my best MTU to be 1500, as this is the default for ADSL
I thought nothing of it and set my router to 1500 (It had been 1472).

Everything appeared to be fine, web surfing OK, receiving mail OK but
had a problem sending emails with attachments; also there was one web
site that I couldn't access on my windows or Linux machines.

As the only thing I recalled altering was the MTU changed it back to
1472 and now all fine.

I know the default is 1500 also for the Linux machines so is this a
common problem with incorrect MTUs that most will work OK but some areas
of the network may not.

Geoff Lane

In article <g18lnc$ji0$(E-Mail Removed)>, Geoff Lane says...
> I run a small home network with two older Linux machines and an XP laptop.
>
> Recently I ran a Windows network analysis tool and after testing various
> URLs it reported my best MTU to be 1500, as this is the default for ADSL
> I thought nothing of it and set my router to 1500 (It had been 1472).
>
> Everything appeared to be fine, web surfing OK, receiving mail OK but
> had a problem sending emails with attachments; also there was one web
> site that I couldn't access on my windows or Linux machines.
>
> As the only thing I recalled altering was the MTU changed it back to
> 1472 and now all fine.
>
> I know the default is 1500 also for the Linux machines so is this a
> common problem with incorrect MTUs that most will work OK but some areas
> of the network may not.
>
It also manifests itself as an inability to sign into Hotmail/MSN and
online banking.

I fail to see, however, how the analysis tool can report the MTU of
1500 as being the best when it is incapable of altering the MTU you set
on the router which, in respect to internet activity, is the only
important one.


--
Conor

I only please one person per day. Today is not your day. Tomorrow isn't
looking good either. - Scott Adams

On Sat, 24 May 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <g18lnc$ji0$(E-Mail Removed)>, Geoff Lane wrote:

>I run a small home network with two older Linux machines and an XP laptop.
>
>Recently I ran a Windows network analysis tool and after testing various
>URLs it reported my best MTU to be 1500, as this is the default for ADSL
>I thought nothing of it and set my router to 1500 (It had been 1472).

1472 isn't that common - it's not even listed as a default in one of the
O/S fingerprinting tools. 1492 on the other hand is _VERY_ common.

>Everything appeared to be fine, web surfing OK, receiving mail OK but
>had a problem sending emails with attachments; also there was one web
>site that I couldn't access on my windows or Linux machines.
>
>As the only thing I recalled altering was the MTU changed it back to
>1472 and now all fine.

Someplace, there is a firewall that is dropping ICMP Type 3 Code 4
packets ("Fragmentation needed, but don't fragment bit set"). This
could be a mis-guided attempt at security, or a NAT translation that
isn't forwarding the error to the right computer.

>I know the default is 1500 also for the Linux machines so is this a
>common problem with incorrect MTUs that most will work OK but some
>areas of the network may not.

1191 Path MTU discovery. J.C. Mogul, S.E. Deering. November 1990.
(Format: TXT=47936 bytes) (Obsoletes RFC1063) (Status: DRAFT
STANDARD)

1435 IESG Advice from Experience with Path MTU Discovery. S. Knowles.
March 1993. (Format: TXT=2708 bytes) (Status: INFORMATIONAL)

2923 TCP Problems with Path MTU Discovery. K. Lahey. September 2000.
(Format: TXT=30976 bytes) (Status: INFORMATIONAL)

The problem has been known for a "few" years, but it still catches
people by surprise.

Old guy

> I run a small home network with two older Linux machines and an XP laptop.

On my dialup connection I run the MTU at 576, and the MRU at 1500. If I
run the MRU at 576, I can't even check my email from my ISP.

When I was just playing with the MTU and leaving the MRU and stuff alone, I
had to change my MTU to 1500 to get to some sites. Tracfone.com,
Pogo.com, and some others. Accessibility came and went though, I could
access them, but there was normally a five minute to an hour and a half
delay before a page would suddenly finish downloading. And not really
because of media content. The bandwidth/throughput would just sit idle
until it popped up. A month earlier, and probably a month later, those
same sites were NOT problematic on the same MTU size. Most times the
routing machine didn't have the issue, where any NAT'd clients did. I
don't know why, just that changing the MTU and sometimes MRU fixed the
problem.

1500 for most things, especially wireless.
1492 for some cable providers
576 for dialup

Changing the MTU in XP, a real PITA (registry hack). In Vista a little
less painfull with the proper documentation of course. netsh or whatever
it's called. Used it once, hopefully never have to see it again in my
lifetime. Not that it's all that bad relative to CLI based ifconfig and
such. But in the newer windows you have to do special stuff to launch an
admin capable dos window. And running that netsh thing in a non admin
window does NOT fail, but does NOT make the change you requested either.

HTH

> I run a small home network with two older Linux machines and an XP laptop.

On my dialup connection I run the MTU at 576, and the MRU at 1500. If I
run the MRU at 576, I can't even check my email from my ISP.

When I was just playing with the MTU and leaving the MRU and stuff alone, I
had to change my MTU to 1500 to get to some sites. Tracfone.com,
Pogo.com, and some others. Accessibility came and went though, I could
access them, but there was normally a five minute to an hour and a half
delay before a page would suddenly finish downloading. And not really
because of media content. The bandwidth/throughput would just sit idle
until it popped up. A month earlier, and probably a month later, those
same sites were NOT problematic on the same MTU size. Most times the
routing machine didn't have the issue, where any NAT'd clients did. I
don't know why, just that changing the MTU and sometimes MRU fixed the
problem.

1500 for most things, especially wireless.
1492 for some cable providers
576 for dialup

Changing the MTU in XP, a real PITA (registry hack). In Vista a little
less painfull with the proper documentation of course. netsh or whatever
it's called. Used it once, hopefully never have to see it again in my
lifetime. Not that it's all that bad relative to CLI based ifconfig and
such. But in the newer windows you have to do special stuff to launch an
admin capable dos window. And running that netsh thing in a non admin
window does NOT fail, but does NOT make the change you requested either.

HTH

Conor wrote:

> It also manifests itself as an inability to sign into Hotmail/MSN and
> online banking.

Hadn't tried the online banking during this period.

> I fail to see, however, how the analysis tool can report the MTU of
> 1500 as being the best when it is incapable of altering the MTU you set
> on the router which, in respect to internet activity, is the only
> important one.

I hadn't even considered that, blatantly obvious now you've highlighted
it

Geoff Lane

Moe Trin wrote:

> 1472 isn't that common - it's not even listed as a default in one of the
> O/S fingerprinting tools. 1492 on the other hand is _VERY_ common.

I thought 1472 allowed for a 28 byte header and actually equalled 1500,
I arrived at this figure initially by using ping with -l and -f flags
but I may be getting the wrong end of the stick here.

It is working though

Geoff Lane

Geoff Lane <(E-Mail Removed)> wrote:
> Moe Trin wrote:

>> 1472 isn't that common - it's not even listed as a default in one of the
>> O/S fingerprinting tools. 1492 on the other hand is _VERY_ common.

> I thought 1472 allowed for a 28 byte header and actually equalled 1500,
> I arrived at this figure initially by using ping with -l and -f flags
> but I may be getting the wrong end of the stick here.

It allows for 28 octets of PPPoX baggage in the framing probably used by
your ADSL equipment. The (usual) 40 octet TCP/IP headers are included
in the 1472 leaving 1432 octets for data. The 1492 allows for 8 octets
of baggage in the most basic PPP over Ethernet, the smallest of all in
the PPPoX family.

How you got 1472 using preloaded flood pings is beyond me - unless you
also specified packet size. However, you might try

tcptraceroute -n -l 1500 192.175.48.60

and perhaps see where the hangup occurs when the router MTU is set to
1500 (the address is an IANA black hole). I suspect it won't even get
to the ISP but if it does then I've guessed wrong and the problem is
not on your end even though the cure is.

> It is working though

Right. "It" then hopefully doesn't have to depend on Path MTU Discovery,
which is how TCP/IP can determine a workable MSS (Maximum Segment Size,
and so maximum packet size) in the absence of broken routers in the path
and broken endpoints.

--
Clifford Kite
/* Substitute "damn" every time you're inclined to write "very"; your
editor will delete it and the writing will be just as it should be.
-- Mark Twain */
QED

On Sat, 24 May 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <(E-Mail Removed)> , Shadow_7 wrote:

>On my dialup connection I run the MTU at 576, and the MRU at 1500. If I
>run the MRU at 576, I can't even check my email from my ISP.
>
>When I was just playing with the MTU and leaving the MRU and stuff alone, I
>had to change my MTU to 1500 to get to some sites. Tracfone.com,
>Pogo.com, and some others.

That's rather interesting. Normally the problem is packets that are to
big, rather than to small. Setting the MTU to 1500 (the default) says
this is the largest sized packet you will transmit. The normal
concern is the largest _receive_ packet, and that is actually what
gets negotiated between ppp peers. Most links don't care what the
maximum size packet YOU transmit is, as long as it's less than the
maximum size that the peer will accept (default 1500).

>Accessibility came and went though, I could access them, but there was
>normally a five minute to an hour and a half delay before a page would
>suddenly finish downloading. And not really because of media content.
>The bandwidth/throughput would just sit idle until it popped up. A
>month earlier, and probably a month later, those same sites were NOT
>problematic on the same MTU size.

Hind-sight is a wonderful thing, but next time that happens, try using
a packet sniffer looking at the headers, and try using traceroute
(preferably 'tcptraceroute' or 'hping3' which allows using TCP data
rather than ICMP echos or UDP) to see the route and possibly who is
dropping packets. The most likely answer is that the routing between
you and the destination changed. Such routes through the "cloud" are
not under your control, but can be bewildering. As an extreme case,
I once did a traceroute6 (IPv6) from a site in New York to a site in
Montreal, and the intermediate hops included Chicago, Seattle, Tokyo,
and Vancouver.

>Most times the routing machine didn't have the issue, where any NAT'd
>clients did. I don't know why, just that changing the MTU and
>sometimes MRU fixed the problem.

THAT problem is Path MTU Discovery. See the three RFCs I refer to
up-thread (RFC1191, RFC1435 and RFC2923). The problem is that Linux
defaults to using Path MTU Discovery (the DF flag is set in the IP
headers), so when sending full sized packets, they are 1500 octets.
Your router/NAT box is either dropping, or failing to correctly
forward the resulting ICMP Type 3 Code 4 packets (often, because it
can't figure out who they are associated with). If you can run a
packet sniffer on the router/NAT box, you'd likely see the ICMP
errors on the Internet side, and not see them forwarded to your LAN
hosts.

>1500 for most things, especially wireless.
>1492 for some cable providers
>576 for dialup

First two OK - last one definitely not. The 8 octet reduction in
MTU for some cable providers is because they are using PPPoE (or the
similar PPPoA). This service sticks an 8 byte header on top of the
packet, and as (standard) Ethernet is limited to 1500 octet frames,
the payload has to be reduced. See RFC2516 and RFC4937 for more
information on this poorly documented service.

The reduction for dialup - that's a whole 'nother problem. The reason
to reduce the MTU is for interactive services, where what you are
typing is echoed back to you from the remote server - for example,
in 'telnet'. The packet size is reduced to improve the latency (the
time between you typing the character, and the resulting echo back
to your display) - see RFC1144 for further details. The '576' MTU
is suitable for X.25 links (now uncommon) and 19200 BPS serial
links. As most serial connections are substantially faster than that,
the MTU reduction usually serves no purpose today. AN EXCEPTION
is when you are using the link for multiple connections _at_the_same_
time_ such as a bloated webpage AND an SSH session, or large FTP file
transfer. The concept here is that with smaller packets, the second
or third connection can 'get a word in edge-wise' between packets of
the bandwidth hog. The overall time for the combined connections will
not significantly change, but each component may have a better chance
to get _some_ bandwidth.

>Changing the MTU in XP, a real PITA (registry hack). In Vista a
>little less painfull with the proper documentation of course. netsh
>or whatever it's called. Used it once, hopefully never have to see it
>again in my lifetime.

Use a packet sniffer - is windoze setting the 'DF' (Don't Fragment)
flag in the IP header? If it's not, the only reason to be reducing
the MTU would be for connection sharing with bandwidth hogs.

>Not that it's all that bad relative to CLI based ifconfig and such.

In most Linux or UNIX operating systems, setting the MTU is a
single variable in the boot configuration file, which you can set
using the windoze-wannabe toy admin application, or by adding a
line to the appropriate (varies by distribution or O/S) file.

Old guy

On Sun, 25 May 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <g1beip$8al$(E-Mail Removed)>, Geoff Lane wrote:

>Moe Trin wrote:

>> 1472 isn't that common - it's not even listed as a default in one of the
>> O/S fingerprinting tools. 1492 on the other hand is _VERY_ common.

>I thought 1472 allowed for a 28 byte header and actually equalled 1500,

While 1472+28 certainly does equal 1500, I'm not aware of a protocol
that would use 20 or 28 bytes. The default Ethernet packet (RFC0894)
is 1500 octets (but that doesn't include the Ethernet header and trailer
of 18 octets). That packet contains an IP datagram of 46 to 1500 octets,
which consists of a 20 to 60 octet IP header (20 plus options in steps
of 4 octets), and the MTU is defined as the size of that IP datagram.
See RFC1191 for additional details. The problem home broadband users
encounter is the abortion called PPPoE, which sticks an IP packet into
a PPP frame, and that frame adds 8 octets to the length (see RFC2516 and
RFC4937 for more details). But the resulting packet still has to have a
maximum Ethernet length of 1500 octets (without the Ethernet headers),
so the MTU of the IP datagram has to be reduced by 8 to compensate for
the 8 extra bytes of PPP header.

>I arrived at this figure initially by using ping with -l and -f flags
>but I may be getting the wrong end of the stick here.

Not exactly sure how that would enter into the argument.

>It is working though

That's the important part.

Old guy