Can't load website; wants a max MTU/MRU of 302 bytes?

January 13, 2009 9:35 AM

Since this weekend I have been unable to access a website. I am network tech so troubleshooting problems like this is my thing, but this one has me stumped. Come in if you know TCP/IP and Path MTU Discovery!

This weekend a website stopped loading for me. The website itself doesn't matter (www.dailymotion.com). The strange thing is that it loads fine through a proxy, or from work. So I set about investigating.

That is the only site so far I have found which does not respond. It worked fine before the weekend. Firefox will connect to the site, but hang indefinitely waiting for a reply.

I can ping the site fine. I can traceroute to it. I can telnet to port 80 and get a connection, but no reply to my requests. If I sniff a connection in progress, I will see the standard SYN, ACK, SYN/ACK, the GET request, and then TCP lost packets and DUP ACKs.

I am over PPPOE. I recalled that there may be issues with MTUs and all that jazz. I used ping to try and determine when I get fragmentation and when I get no reply. My packets are fragmented over 1464 bytes (my MTU is 1492) but I get no reply below that size anyway. I only get a reply for packets which are 274 bytes or smaller (not including the header).

This seems to indicate that there is a link somewhere that will not pass packets bigger than 302 bytes total. This makes very little sense to me. The minimum MTU is supposed to be 576.

What could be going on? How could I go about fixing it? This is confusing me.... Any help is appreciated!

posted by splice to computers & internet (20 comments total)

Does this happen only from one location (home, work)? Does the site work from other machines at this location?
posted by zippy at 9:44 AM on January 13

Have you determined whether this is a problem with one computer, or every computer connected to your network? What's doing the PPPoE negotiation? Your PC or a router?
posted by mrbarrett.com at 9:45 AM on January 13

My guess is a routing table is misconfigured on one of your hops. Probably some return traffic is being pushed to another subnet for some reason. I had something like this happen on our farm, and that was the root problem.

However I did not have to go as far as you did with packet analysis. I'm guessing based on your stated experience that you've checked all your tables twice, and things look OK.

Do you get a "HELO" from the web server... or any service (pub FTP, SMTP?) on that domain? Your DNS isn't reporting back a bogus IP is it?
posted by teabag at 9:54 AM on January 13

This happens only from one location. I cannot get the website on either Linux or Windows, on either of my machines at home.

PPPoE is handled by a Linksys router with Tomato firmware. I had been using single-link MLPPP but disabled it, with no effect.

I can traceroute and see that the large pings (well, larger than 274 bytes anyway) die in the last 3 hops. The 3rd to last hop is a shadow router (doesn't respond to ICMP requests that I can see), and the last two are over at dailymotion.
posted by splice at 9:55 AM on January 13

teabag, I don't handle or manage any routers. Just my DSL router, and I don't think it's about routing.

TBH routing seems fine since I can ping/traceroute. I really think this may be related to PMTUD but 304 bytes is just so small as to beggar disbelief.
posted by splice at 9:57 AM on January 13

I had this exact symptom once, on a cable connection - I could ping, traceroute, telnet and make connections, but any Web requests wouldn't work. It turned out that the Linux box doing the routing had silently dropped its own MTU down to 576 or down around there. Rebooting didn't help and I had to manually configure the MTU to get back up - for a permanent fix, I had to increase the MTU in /etc/rc.local.

I know theoretically you should be able to run your MTU at 576 and be okay, but some firewalls out there have a bad attitude about fragmented packets. Is it possible your MTU has changed without your knowing it?
posted by pocams at 10:08 AM on January 13

PPPoE is handled by a Linksys router with Tomato firmware.

Got anything to swap this out with? Or run pppoe on a computer straight into the modem to bypass this? If it still happens Id borrow a DSL modem and swap that in. If it continues then the problem is probably upstream and out of your control.
posted by damn dirty ape at 10:13 AM on January 13

pocams, I've been changing the MTU myself to try and get it to work. Ideally I would have set it at 302 and have all packets fragmented over that size but 576 is the minimum size. 1492 is the default (and I also ran on 1486 for single-link MLPPP because of the MLPPP header). Nothing weird going on with the MTU changing on its own.

damn dirty ape, I do have a stock linksys router that's a spare, no tomato or custom firmware on it. I'll try it out tonight.

I imagine I may well be out of luck after all. Darn strange problem anyway.
posted by splice at 10:21 AM on January 13

Verify that your public IP has a PTR record configured. Some sites for some reason will reject IPs without PTR records configured. Also, did you try going to the site with IE?
posted by aperture_priority at 11:40 AM on January 13

Can others on your ISP access the site? Or perhaps call your ISP to see if they can access the site. That would help determine whether its a problem specific to you, or a more general issue.
posted by forforf at 11:48 AM on January 13

can you hit the site using a proxy server?
posted by jenkinsEar at 12:35 PM on January 13

Have you been hardsetting your MTU all the while, even before last weekend? That can negate PMTU.
posted by rhizome at 12:45 PM on January 13

I seriously doubt dailymotion requires a valid reverse DNS.
posted by rhizome at 12:46 PM on January 13

FWIW, youre not the only one. Look like there's an issue with Canada connecting to DM.
posted by damn dirty ape at 1:25 PM on January 13

aperture, jenkins, please refer to my question and follow-ups. Yes, I tried with IE. Yes, I can get to the site using a proxy server.

rhizome, I wasn't hardcoding my MTU, just using the default (1492). Started playing around when the problems occured.

I am unsure if others on my ISP are experiencing the same issue. I'll try verifying that.
posted by splice at 1:26 PM on January 13

Thanks damn dirty ape. I had browsed dslreports but just the teksavvy portion. I'll write up my data so far in that thread when I am at home.
posted by splice at 1:27 PM on January 13

And from that thread another person on my ISP has the same issue. Solving it will be fun I am sure. Thanks for all the input & suggestions so far. I anybody has something dawn upon them, let me know!
posted by splice at 1:29 PM on January 13

Can you, for testing purposes, take the WAP out of the equation? I had tons of trouble with Tomato firmware. It's so pretty and graphy, and yet sometimes it seems to just fail on basing routing.
posted by pompomtom at 2:40 PM on January 13

ahem, 'basic'...
posted by pompomtom at 2:52 PM on January 13

The site is responding normally again this morning. Temporary network troubles FTW. Strange symptoms all the same.
posted by splice at 2:20 AM on January 14