0

I'm seeing this in Wireshark when curling this URL:

wireshark capture

On the same network, a Windows host retransmits properly, but an Android host does not. On a different network (presumably appropriately configured), the same Android host works.

What could be the cause?

univerio
  • 121
  • 4
  • Is the host receiving the ICMP responses? – Michael Hampton Mar 31 '16 at 21:45
  • @MichaelHampton You mean the Packet Too Big messages? Yes, all hosts seem to receive ICMPv6 messages correctly. The firewall is configured to allow all ICMPv6 messages. The screenshot shows several Packet Too Big messages specifying MTU 1280 immediately followed by a retransmission with packet size ~1500. – univerio Mar 31 '16 at 21:55
  • I think you might be running into this: https://forum.ivorde.com/linux-tso-tcp-segmentation-offload-what-it-means-and-how-to-enable-disable-it-t19721.html – Sander Steffann Mar 31 '16 at 22:19
  • @SanderSteffann I tried disabling tso and gso with those instructions and the same thing is still happening. – univerio Mar 31 '16 at 22:24
  • The retransmission does _not_ occur immediately after the ICMP message is sent. It's delayed, with an obvious exponential backoff occurring. That's what indicates that the host is not receiving the ICMP responses. Check your firewalls. – Michael Hampton Mar 31 '16 at 22:30
  • @MichaelHampton But the wireshark capture clearly says that the ICMPv6 messages have been received. Perhaps I should clarify that the capture is done on the Linux host, not the remote server. – univerio Mar 31 '16 at 22:34
  • You still need to check your firewalls. – Michael Hampton Mar 31 '16 at 22:38
  • @MichaelHampton What should I be looking for? I don't understand how, if I see the packet in wireshark, the firewall is still blocking it? I've enabled all WAN <-> LAN traffic and it still didn't help. – univerio Apr 01 '16 at 01:21

1 Answers1

2

I've figured out the problem.

This is caused by TCP sequence number randomization in my firewall. The kernel was apparently unable to figure out which TCP connection the Packet Too Big message was referring to so it couldn't retry with the correct MTU. Disabling TCP sequence number randomization in my firewall fixed the issue.

EDIT: the firewall in question is a SonicWALL NSA 220, firmware 5.9.1.0-22o.

univerio
  • 121
  • 4
  • Strange, Linux has no problem with TCP sequence number randomization. You either have a bug in your particular kernel version, or you still have a firewall issue. – Michael Hampton Apr 01 '16 at 01:47
  • 1
    @MichaelHampton I should add that it's sequence number randomization by the firewall. I suppose this could be seen as a defect in my firewall. Ideally it would see the truncated packet in the ICMPv6 message and rewrite the sequence number back to their original. – univerio Apr 01 '16 at 01:51
  • Getting the firewall fixed is definitely the preferred solution. Disabling sequence number randomization exposes you to a variety of attacks. – Michael Hampton Apr 01 '16 at 01:52
  • @MichaelHampton As long as the endpoints randomize their initial sequence numbers there is no need for intermediate routers to even know what TCP is. A firewall is supposed to inspect traffic and reject any which is harmful. It is not supposed to modify the traffic in flight. Having a firewall rewrite sequence numbers is a really dirty workaround for a problem that probably does not exist in the first place. – kasperd Apr 03 '16 at 09:28
  • @univerio To help others in the future searching for a solution to the same problem, you should specify the model of the buggy firewall in either the question or the answer. – kasperd Apr 03 '16 at 09:34