Hacker News new | past | comments | ask | show | jobs | submit login

Well, while we're at it, here's my crazy MTU-related war story, although not as crazy as that one!

I was troubleshooting with a user of an audio streaming application running over a LAN. The user could stream classical music but not rock music. Seriously. Classical was fine, but when streaming rock, the connection would drop after a few minutes.

The application took chunks of audio, compressed them with a lossless codec, and then sent each chunk in a separate UDP packet to the other end. It tried to use IPv6 whenever possible because it was generally more reliable in the LAN environment, although it would happily use IPv4 if need be.

After a huge amount of boring troubleshooting going back and forth with this guy, I finally figured it out. Somehow, he had set his network interface's MTU to 1200 bytes. IPv6 won't perform automatic IP-level fragmentation for MTUs below 1280 bytes, so larger packets simply could not be sent at all. The streaming application would try to send an audio packet larger than 1200 bytes, get an error, and bail out of the connection.

Why did it only happen with rock music? Turns out to be pretty simple. Lossless codecs are necessarily variable bitrate, and classical music compresses better than rock music. When streaming classical, each chunk of audio consistently compressed to less than 1200 bytes, but rock music produced occasional packets over the threshold.

The user didn't know why his MTU was turned down and didn't need it, so we turned it back up and everything worked just fine.

I love this sort of insane-sounding problem descriptions. Here's one that happened to me: WiFi disconnects when I visit Gmail, and doesn't reconnect until I reboot Linux. Cause: Gmail's chat thingy uses Flash, which for some reason does some webcam initialization, which triggers a bug (in combination with crappy hardware) in the uvcvideo kernel module which leads to a timeout which leads to the whole USB bus going down. Which includes the WiFi chip.

How long did that take you to figure out? I imagine that would drive me completely mad.

Well, back in the day I did a lot of network management on ATM and frame-relay networks and MTU-related problems were quite common there. It left me with a habit of always checking packets of different sizes and looking closely for fragmentation-related issues (also ICMP filtering).

But this one is different -- it's not just the packet size that is the problem, it's that certain packets above a certain size get corrupted. Much more difficult to trace, so kudos to the authors. In fact, it seems I was bitten by the exact same problem, but could not trace it down, as I checked and ICMP packets of various sizes passed OK.

Having a smaller MTU is fine. The problem comes when people start blocking the ICMP fragmentation needed packets, presumably due to some assumption that this will in some way help with security.

That's fine for TCP, but not good for a UDP protocol that can't make packets smaller.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact