[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: airport on tibook: surfing vs. ssh/scp

On  24 Feb, this message from Serge Rey echoed through cyberspace:
> On Sun, Feb 23, 2003 at 11:05:05AM -0500, christophe barbe wrote:
>> On Sat, Feb 22, 2003 at 09:09:35AM -0800, Serge Rey wrote:
>> > i tried this last night on my tibook. upgraded OS X and the airport
>> > firmware went from 8.4 to 8.7.
>> > 
>> > however, booting back into linux i see the browsing problem with some
>> > pages not loading still remains. (and the firmware is 8.7 according to
>> > dmesg).
>> So if I understand correctly the remaining issue is the one I described.
> yes, i think it is.
>> The best explanation I have found for this problem is related to MSS
>> clamping [1]. This could explain why not everybody is seeing the
>> problem. The symptoms are the same but it is difficult to explain why it
>> occurs only when encryption is turned on. 
>> [1] http://home.earthlink.net/~jaymzh666/solaris/mss.html
> great link. this lead me to poke around some more and one of the
> suggestions i came across was to tweak the mtu setting. so here is what
> i did
> ifconfig eth1 mtu 462
Sure about that value? Not 1462?

> and galeon is loading all the pages just fine now.
> perhaps someone who knows networks better than i (which is a very large
> population) could help explain why this setting seems to have done the
> trick with the airport card. 
> i should note that before this change, the default mtu assigned was 500.
Again, this was probably 1500, no?

Well, I can explain in a few words what's up with MTU-related problems.

MTU is the maximum size of a frame you can send out on the network (be
it Ethernet, wireless, whatever). This is a limit on the physical (or
rather, MAC)-layer. IP can handle larger packets, but then the IP packet
needs to be fragmented into multiple (for Ethernet as example) Ethernet
frames, which is not that efficient. There are other reasons, but in
general, you try to avoid fragmentation.

Maximum MTU is almost always 1500 bytes everywhere, even on media other
than Ethernet (think your ISP's big backbone pipes). The problem arises
when you put more protocol stacks one above the other, as is the case
for example for PPPoE: now your Ethernet frame doesn't contain an IP
packet, but rather contains a PPP frame that contains an IP packet. and
suddenly, the medium just below IP, which is now PPP, doesn't have
1500 bytes MTU anymore, but (1500 - PPP header size).

If IP continued to send (1500 - Ethernet header) sized packets, they
would all get fragmented into a big (1500 - Ethernet header - PPP
header) and a small chunk (PPP header size).this is obviously very
inefficient: on your PPPoE link, for every IP packet, you get double the
overhead: two Ethernet headers and two PPP headers instead of just one
of each if you made your IP packets just a little bit smaller.

That's the reason to do path MTU discovery, a mechanism for hosts to try
and determine the largest IP packet they can send _without_ triggering
fragmentation. Sometimes, this mechanism breaks, and that's what the
page posted here is about.

Now, after this (rather long, after all :-) explanation, questions to
those with this Airport problem: are you using PPPoE (i.e. ADSL or some
other broadband medium) to connect to the Internet?



Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "

Reply to: