[clug] Wierd problem connecting to www.mozilla.organdwww.microsoft.com

Andrew Smith andrew at coolchilli.com
Thu Dec 16 20:51:17 GMT 2004


Ideally the MTU shouldn't need changing, but clients don't often do MTU
discovery and lots of people block ICMP frag packets, it's a sad
by-product of DSL.  In fact I've noticed that XP doesn't seem terribly
friendly when it comes to MTU/DF/ICMP frag things.  Async PPP over
modems didn't show this problem as the MTU was typically plugged into
your PC (so it knew the max) and many PPP MTU/MRU negotiations are only
512 bytes.

If your DSL service is PPPoE then you lose 8 bytes for PPP header, if
you're with someone cool like Internode on a Layer 2 service, then you
don't have a ppp stack and just bridge Ethernet.  If Internode were even
cooler they'd allow Layer 2 people to run Classic IP over ATM (rather
than rfc1483 bridging) to further reduce ethernet's overhead and allow
larger frames, but that's another story.

It gets more exciting again when you run some sort of tunnel type
encapsulation from your access router (like gre) which has even more
overhead!

Interestingly, google told me this about the microsoft.com story, which
may help to understand why it was some sites:
>From http://www.netheaven.com/pmtulist.html

Site With an Alternative Path MTU Approach

 One site uses its own approach to the Path MTU problem. 
microsoft.com
 
The microsoft.com servers begin by sending full-size packets with the DF
bit set, as if they were doing path MTU discovery, but any return
"fragmentation needed" ICMPs are either blocked or ignored.  Instead, if
after several retries no acks of the full-size packets are received, the
servers switch to sending small (524-byte) packets without the DF bit
set. 

This works, but we have to wonder what is the point of setting the DF
bit on the initial full-size packets.  Overall, this procedure
introduces a delay of about 10 seconds in the download, compared to no
delay for simply turning off the DF bit and delays typically around one
or two tenths of a second for PMTUD. 


This behavior appears to be a custom modification for Microsoft's own
use.  We haven't seen any of Microsoft's customers' servers do this. 


Andrew

On Thu, 2004-12-16 at 17:51, Donovan J. Edye wrote:
> D,
> 
> > I don't think the MTU thing worked.
> Correct. I installed DrTCP and it had not taken. Made it 1300. Rebooted....
> and now www.microsoft.com opens!!!!
> 
> Now what I want to know is what is the MTU really and why has this worked?
> 
> --D
> 
> 
> -----Original Message-----
> From: Dale Shaw [mailto:dale.shaw at gmail.com] 
> Sent: Thursday, 16 December 2004 13:54
> To: donovan at edyeweb.com
> Subject: Re: [clug] Wierd problem connecting to
> www.mozilla.organdwww.microsoft.com
> 
> I don't think the MTU thing worked. Was there more than one {guid}?
> Anyway, perhaps a better way to do it is to use DrTCP:
> 
> http://www.dslreports.com/drtcp
> 
> Have a play with that and see if you can verify that the MTU change
> you did manually worked properly. If not or if in doubt, use DrTCP to
> make the change.
> 
> cheers,
> Dale
> 
> 
> On Thu, 16 Dec 2004 13:46:02 +1100, Donovan J. Edye <donovan at edyeweb.com>
> wrote:
> > G'Day,
> > 
> > >Maybe you could humour me and try dropping the MTU on the Ethernet
> > <HUMOUR MODE ON>
> > - There was no MTU key so I added one and set it to 1300
> > - Rebooted
> > - I have no idea to know if this worked (How do you tell on a Windoze box
> > what it thinks the MTU is)
> > - Made sure GW was .1
> > - Opened up www.microsoft.com and got...... nowhere (See ethereal dump
> > below)
> > 
> > </HUMOUR MODE ON>
> > 
> > Back to stabbing the Bill Doll.....
> > 
> > No.     Time        Source                Destination           Protocol
> > Info
> >      1 0.000000    hometheatre.home.local origin2.microsoft.com TCP
> > 1092 > http [SYN] Seq=0 Ack=0 Win=65535 Len=0 MSS=1460
> > 
> > Frame 1 (62 bytes on wire, 62 bytes captured)
> > Ethernet II, Src: 00:40:63:ca:84:72, Dst: 00:50:ba:9a:7a:d7
> > Internet Protocol, Src Addr: hometheatre.home.local (192.168.40.100), Dst
> > Addr: origin2.microsoft.com (207.46.156.220)
> > Transmission Control Protocol, Src Port: 1092 (1092), Dst Port: http (80),
> > Seq: 0, Ack: 0, Len: 0
> > 
> > No.     Time        Source                Destination           Protocol
> > Info
> >      2 0.205602    origin2.microsoft.com hometheatre.home.local TCP
> > http > 1092 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460
> > 
> > Frame 2 (62 bytes on wire, 62 bytes captured)
> > Ethernet II, Src: 00:50:ba:9a:7a:d7, Dst: 00:40:63:ca:84:72
> > Internet Protocol, Src Addr: origin2.microsoft.com (207.46.156.220), Dst
> > Addr: hometheatre.home.local (192.168.40.100)
> > Transmission Control Protocol, Src Port: http (80), Dst Port: 1092 (1092),
> > Seq: 0, Ack: 1, Len: 0
> > 
> > No.     Time        Source                Destination           Protocol
> > Info
> >      3 0.205713    hometheatre.home.local origin2.microsoft.com TCP
> > 1092 > http [ACK] Seq=1 Ack=1 Win=65535 Len=0
> > 
> > Frame 3 (54 bytes on wire, 54 bytes captured)
> > Ethernet II, Src: 00:40:63:ca:84:72, Dst: 00:50:ba:9a:7a:d7
> > Internet Protocol, Src Addr: hometheatre.home.local (192.168.40.100), Dst
> > Addr: origin2.microsoft.com (207.46.156.220)
> > Transmission Control Protocol, Src Port: 1092 (1092), Dst Port: http (80),
> > Seq: 1, Ack: 1, Len: 0
> > 
> > No.     Time        Source                Destination           Protocol
> > Info
> >      4 0.206104    hometheatre.home.local origin2.microsoft.com HTTP
> > GET / HTTP/1.1
> > 
> > Frame 4 (362 bytes on wire, 362 bytes captured)
> > Ethernet II, Src: 00:40:63:ca:84:72, Dst: 00:50:ba:9a:7a:d7
> > Internet Protocol, Src Addr: hometheatre.home.local (192.168.40.100), Dst
> > Addr: origin2.microsoft.com (207.46.156.220)
> > Transmission Control Protocol, Src Port: 1092 (1092), Dst Port: http (80),
> > Seq: 1, Ack: 1, Len: 308
> > Hypertext Transfer Protocol
> > 
> > No.     Time        Source                Destination           Protocol
> > Info
> >      5 3.150457    hometheatre.home.local origin2.microsoft.com HTTP
> > GET / HTTP/1.1
> > 
> > Frame 5 (362 bytes on wire, 362 bytes captured)
> > Ethernet II, Src: 00:40:63:ca:84:72, Dst: 00:50:ba:9a:7a:d7
> > Internet Protocol, Src Addr: hometheatre.home.local (192.168.40.100), Dst
> > Addr: origin2.microsoft.com (207.46.156.220)
> > Transmission Control Protocol, Src Port: 1092 (1092), Dst Port: http (80),
> > Seq: 1, Ack: 1, Len: 308
> > Hypertext Transfer Protocol
> > 
> > No.     Time        Source                Destination           Protocol
> > Info
> >      6 3.400492    origin2.microsoft.com hometheatre.home.local TCP
> > [TCP Previous segment lost] http > 1092 [ACK] Seq=2921 Ack=309 Win=65227
> > Len=0
> > 
> > Frame 6 (60 bytes on wire, 60 bytes captured)
> > Ethernet II, Src: 00:50:ba:9a:7a:d7, Dst: 00:40:63:ca:84:72
> > Internet Protocol, Src Addr: origin2.microsoft.com (207.46.156.220), Dst
> > Addr: hometheatre.home.local (192.168.40.100)
> > Transmission Control Protocol, Src Port: http (80), Dst Port: 1092 (1092),
> > Seq: 2921, Ack: 309, Len: 0
> > 
> > No.     Time        Source                Destination           Protocol
> > Info
> >      7 47.126245   candice.home.local    192.168.40.255        NBNS
> > Name query NB MOE<20>
> > 
> > --D
> > 
> > 
> > -----Original Message-----
> > From: Dale Shaw [mailto:dale.shaw at gmail.com]
> > Sent: Thursday, 16 December 2004 13:07
> > To: donovan at edyeweb.com
> > Cc: Linux List
> > Subject: Re: [clug] Wierd problem connecting to
> > www.mozilla.organdwww.microsoft.com
> > 
> > Getting a bit OT, not that it ever stopped me before..
> > 
> > Maybe you could humour me and try dropping the MTU on the Ethernet
> > card in the XP box just to rule it in/out. Take it down to 1300 or
> > something, just to test. It's in the registry, under:
> >
> HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{guid}\MT
> > U
> > 
> > If you have multiple interfaces, there will be multiple {guid} keys.
> > Just flick through and find the one that has some entries that
> > correspond to your Ethernet card's settings (IP address etc.). Change
> > the value of 'MTU' to something low (e.g. 1300), reboot (I assume) and
> > try it all again.
> > 
> > I doubt this really has anything directly to do with XP misbehaving.
> > More like the D-Link device or even a host-based firewall blocking
> > ICMP unreachables (specifically type 3/code 4).
> > 
> > You shouldn't see those ICMP redirects now you've changed the default
> > gateway to be the D-Link, as Andrew suggested.
> > 
> > cheers
> > Dale
> > 
> > On Thu, 16 Dec 2004 12:46:25 +1100, Donovan J. Edye <donovan at edyeweb.com>
> > wrote:
> > > A,
> > >
> > > > Is there a special reason the XP box has the Music box as it's
> gateway,
> > > > rather than the Dlink (40.1)?
> > > No special reason at the moment. I do want to place an internal firewall
> > on
> > > .3 and so am setting up all boxes to go to that box. However changing it
> > to
> > > .1 produces exactly the same result.
> > >
> > > > Enable HTTP/1.1 and HTTP/1.1 through proxy connections,
> > > Done. Only the proxy one was not enabled
> > >
> > > > plus disable "Show friendly HTTP error messages" so you get some
> usefull
> > > feedback,
> > > > rather than that pathetic "DNS or server error" page.
> > > I have done so. Strangely I still get the "The page cannot be displayed
> > > under IE" Checked and there don't seem to be any other settings that
> would
> > > make this happen. Any ideas on that one as well?
> > >
> > > "Hauls out Bill Doll and starts stabbing it with pins"
> > >
> > > --D
> > 
> > --
> > linux mailing list
> > linux at lists.samba.org
> > https://lists.samba.org/mailman/listinfo/linux
> >



More information about the linux mailing list