TCP/IP RST being sent differently in different browsers.

Question

On Mac OS X (10.6), if I start a YouTube video download and pull the Ethernet cable for 5 or so seconds, then plug it back in, I get varying results depending on the browser. With Opera and Chrome, after I plug the cable back in the video continues to load. But with Safari and Firefox, it never does.

Using Wireshark to look at the traffic, I found that Opera and Chrome simply ACK the first packet from YouTube after the cable has been plugged back in, but Safari and Firefox set the RST flag (0x4) in the TCP header and no more traffic follows.

I can put a HUB in between the machine and the internet connection, the problem goes away and all four browsers continue loading the video when the cable is plugged back into the HUB. Again, looking at the Wireshark logs, it's evident that the machine doesn't see the Mulitcast connection close and there is simply a delay in the packets flowing through.

So it seems that if Safari and Firefox sees a Multicast connection close, and then later see data on that same connection, they will send a RST.

My question is why? What is the correct course of action, and why are 2/4 browsers doing it one way, while the other 2/4 are doing it another way? Is there somewhere in the code that I can see where this is happening in Firefox, for instance?

Thank you very much.

Answer 1

It seems that Firefox and Safari delete the TCP connection from their list of opened connections when they see the Multicast connection close.

Once a TCP connection is closed, a reasonable behavior when trying to send packets to it is to send a RST packet.

Answer 2

When you pull the cable, your interface goes down, and subsequent packets should get an "ICMP NO ROUTE TO HOST". It's then up to the application as to what to do with that: do you give up immediately or wait longer? Looks like Firefox and Safari don't wait longer.

When you leave the hub in place, your computer doesn't know it's lost the route to the host, so the message doesn't come up.

HTH,