1

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?

8
  • Is the host receiving the ICMP responses? Mar 31, 2016 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, 2016 at 21:55
  • I think you might be running into this: forum.ivorde.com/… Mar 31, 2016 at 22:19
  • @SanderSteffann I tried disabling tso and gso with those instructions and the same thing is still happening.
    – univerio
    Mar 31, 2016 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. Mar 31, 2016 at 22:30

1 Answer 1

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.

5
  • 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. Apr 1, 2016 at 1: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 1, 2016 at 1:51
  • Getting the firewall fixed is definitely the preferred solution. Disabling sequence number randomization exposes you to a variety of attacks. Apr 1, 2016 at 1: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 3, 2016 at 9: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 3, 2016 at 9:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .