An IPv6 MTU path discovery bug

While installing a new server last week, my (SSH / TCP) connection seemed to suffer from some sort of hanging; randomly. I tried to figure out what was going on and it didn’t take long to find… that there were several icmp-v6 “too big” packets – but no response on the server side. It kept sending 14..-something large packets, although my SIXXS-tunnel can only handle 1280 bytes (or “octets”, I should say). So the tunnel end point kept sending icmp-v6 “too big” and the connection got stuck.

Then, after a bit of fiddling with the routing entries, I found out that “ip -6 route flush cache” would resolve the issue. Temporarily. After a routing cache flush, suddenly, the same icmp-v6 that were ignored seconds before, now set a new MTU on the connection.

“That’s weird”, I thought. I looked if I could find any bugs related to this – I couldn’t, apart from a message on the Netdev-mailinglist by someone named Steinar Gunderson, who seemed to have the same issue – with a totally different kernel and completely different routing.

It puzzled me – and although I wasn’t sure this was a bug, I set out to send a message to the Netdev guys.

The rest is – almost – history: here is my message. As you can see from the message thread, it took Hannes Frederic Sowa just a couple of days to reproduce it – and to write two patches to fix the issue.

So I’m hoping to have a working IPv6 setup in a couple of weeks. Until then, your Linux machine may suffer from random TCP cut off…

Tags: , , , , , ,

Comments are closed.