In article , 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 , 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 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 , 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 , 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

Hello,

Geoff Lane a écrit :
>
> I thought 1472 allowed for a 28 byte header and actually equalled 1500,

What header ? The IP header length is included in the MTU.

> I arrived at this figure initially by using ping

Oh, do you mean 28 is the sum of the IP header length (20) + ICMP header
length (8) and 1472 is the maximum payload length (-s option, online
help calling it "packetsize" may be misleading) in the ping request ?
Then the MTU is 1500.

Clifford Kite wrote:
> 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,
>> 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.

PPPoA vcmux has the least overhead (9 or 10) but you can still run MTU
1500 as AAL5 can carry about 32k. PPPoE adds the mac address amongst
other things on top of the 8 bytes that eat out of the 1500 ethernet
payload limit.

Andy.

Andy Furniss wrote:
> Clifford Kite wrote:
>> 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,
>>> 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.

> PPPoA vcmux has the least overhead (9 or 10) but you can still run MTU
> 1500 as AAL5 can carry about 32k. PPPoE adds the mac address amongst
> other things on top of the 8 bytes that eat out of the 1500 ethernet
> payload limit.

Beg to differ, the source and destination MAC addresses are part of
the header for Ethernet frames of type 0x8864 (PPPoE session frames)
just as they are a part of the header for regular Ethernet frames and
don't take up any of the regular Ethernet payload space.

--
Clifford Kite

> the MTU reduction usually serves no purpose today.

The exception is pretty much rule around here. We share a dialup
connection for the entire house. So the smaller MTU allows for more user
friendly queuing of packets. Like most web pages with 1,000,000 50 byte
pics and scripts all imported to one html document. Which appears to be
the rule these days. Run a torrent or *cough* windows update while trying
to check your web based email and forget about it, if you're using a larger
MTU size. Also the ISP seems to drop the connection much quicker if you
don't use a small MTU. With a 1500 packet size, it will dial out about
every two minutes. With the smaller MTU size I can stay connected 5 to 10
hours at a time. I also appear to be able to download at extra 3MB per
hour at 576. So roughly 15MB per hour, instead of 12MB or less.

When issues arise, it's problematic in that nothing changed on this end.
Mom gets edgy, my internet games this morning and my whole day sucked
because of it. Don't make me run windows. Of course we moved away from
windows because it's wireless connectivity was dodgy at best. Sometimes it
worked, sometimes it didn't. Normally if the signal dropped below 34% it
would forget that it had a wireless interface. So any time the A/C kicked
on bye bye network. I moved her to linux and she's much happier. But now
when issues happen she gets flustered as do I because normally it runs
problem free. And of course "nothing changed on our end".

Moe Trin wrote:

>> 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.

On the following URL it explains about using PING to check MTU and gives
the explanations following.

http://www.kitz.co.uk/adsl/MTU2.htm


In the example above it shows that my highest responsive ping is 1402.
From this we need to add on 28 to get the maximum MTU figure.
(28 being the header size for IP + ICMP)

Do not go above 1472. (1472 + 28 = 1500 MTU) since 1500 is the maximum MTU.

Geoff Lane

Pascal Hambourg wrote:

> Oh, do you mean 28 is the sum of the IP header length (20) + ICMP header
> length (8) and 1472 is the maximum payload length (-s option, online
> help calling it "packetsize" may be misleading) in the ping request ?
> Then the MTU is 1500.

Yes, I did read that explanation somewhere.

Geoff Lane

Moe Trin wrote:

>> 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've got an older Vigor 2600 NAT router, on the IP tables I have barred
everything in and out unless I open the ports.

To date with trial and error, if anything don't work I check the ports
in the router's system log and open that port if I require it. All
normal ports are open.

The rules apply to TCP/UDP so I assume ICMP is not affected.

Is Path MTU Discovery on by default. I have looked at DR TCP and have
tried altering the MTU and saving but it always comes up blank when I
launch the program again.

Geoff Lane

Clifford Kite wrote:
> Andy Furniss wrote:
>> Clifford Kite wrote:
>>> 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,
>>>> 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.
>
>> PPPoA vcmux has the least overhead (9 or 10) but you can still run MTU
>> 1500 as AAL5 can carry about 32k. PPPoE adds the mac address amongst
>> other things on top of the 8 bytes that eat out of the 1500 ethernet
>> payload limit.
>
> Beg to differ, the source and destination MAC addresses are part of
> the header for Ethernet frames of type 0x8864 (PPPoE session frames)
> just as they are a part of the header for regular Ethernet frames and
> don't take up any of the regular Ethernet payload space.
>

In the context of ADSL and PPPoX as above you said PPPoE had the
smallest baggage. This is not the case as ADSL uses ATM/AAL5 and in the
case of PPPoE the mac gets sent in the AAL5 frame as well as other
overheads - for PPPoA it doesn't. If as a DSL customer you have a choice
(As I do) PPPoA/VC multiplex gives the lowest on the wire overhead of
the PPPs.

In both cases there are ATM overheads and padding to consider as well to
truly know how much of your sync/showtime bitrate is used per packet.

Andy.

Andy Furniss wrote:
> Clifford Kite wrote:
>> Andy Furniss wrote:

>>> PPPoA vcmux has the least overhead (9 or 10) but you can still run MTU
>>> 1500 as AAL5 can carry about 32k. PPPoE adds the mac address amongst
>>> other things on top of the 8 bytes that eat out of the 1500 ethernet
>>> payload limit.
>>
>> Beg to differ, the source and destination MAC addresses are part of
>> the header for Ethernet frames of type 0x8864 (PPPoE session frames)
>> just as they are a part of the header for regular Ethernet frames and
>> don't take up any of the regular Ethernet payload space.
>>
> In the context of ADSL and PPPoX as above you said PPPoE had the
> smallest baggage. This is not the case as ADSL uses ATM/AAL5 and in the
> case of PPPoE the mac gets sent in the AAL5 frame as well as other
> overheads - for PPPoA it doesn't. If as a DSL customer you have a choice
> (As I do) PPPoA/VC multiplex gives the lowest on the wire overhead of
> the PPPs.

Okay, my bad. I failed to connect the first sentence in your reply
with the last and thought you were talking about the Ethernet framing
not that over the wire to the ISP.

> In both cases there are ATM overheads and padding to consider as well to
> truly know how much of your sync/showtime bitrate is used per packet.

> Andy.

--
Clifford Kite

On Mon, 26 May 2008, in the Usenet newsgroup comp.os.linux.networking, in
article , Shadow_7 wrote:

>> the MTU reduction usually serves no purpose today.
>
>The exception is pretty much rule around here. We share a dialup
>connection for the entire house. So the smaller MTU allows for more
>user friendly queuing of packets.

That is a very valid reason.

>Like most web pages with 1,000,000 50 byte pics and scripts all
>imported to one html document. Which appears to be the rule these days.

Boy, do I know what you mean. I was investigating a webpage that one
of my users was complaining about, and discovered it had so much
garbage - mainly small _pictures_ of letters, so the idiot web designer
could have his own freakin' font, in multiple sizes and colors. WTF???

>Also the ISP seems to drop the connection much quicker if you don't use
>a small MTU. With a 1500 packet size, it will dial out about every two
>minutes. With the smaller MTU size I can stay connected 5 to 10 hours
>at a time.

I must say I've never seen that problem.

>When issues arise, it's problematic in that nothing changed on this end.

Are you dialing the same number? Your posting IP is changing significantly
and belongs to a point-of-presence provider (Level3). It's not at all
unusual to see the systems at the other end of the wire configured
differently, even when you dial the same number. I usually detect this
by IP addresses, or the options that ppp negotiates.

Old guy