2

I am sending an HTTP request with body that it is large enough for request to get segmented into multiple packets of sizes 374B (headers), 1500B and 199B.

Since some of our network equipment has a MTU of only 1430B and the packets have IPv4 "Don't fragment" flag set, the equipment rejects the packet of size 1500B and responds with ICMP Fragmentation needed, but "don't fragment" flag set. This packet ICMP packet has "MTU of next hop" of 1430B.

TCP then waits a bit and re-transmits the packet just at it was dropped as a result of network congestion (see Wireshark screenshot) and does not adjust the size of its segments.

Why won't TCP adjust the size of the segments, so the packet size would be smaller enough?

I am using:

  • Java Apache HTTPClient library or curl 7.64.0
  • Linux raspberrypi 4.19.86-v7+
  • SIMCOM SIM7600G-H LTE Module

wireshark packets

IPv4 headers of the large packet

ICMP packet that responds to the large packet (with "MTU of next hop: 1430B")

Edit: all traffic was captured at client device via tcpdump.

aljazerzen
  • 121
  • 4
  • Where was the packet capture created, directly on the client device? Are you sure that there are no firewall rules which block arbitrary ICMP since this is actually a common problem of overblocking? – Steffen Ullrich Dec 12 '19 at 09:18
  • @SteffenUllrich yes, client device. I believe there are only default firewall settings of raspbian. How would I check that? With iptables? What rules should I be searching for? – aljazerzen Dec 12 '19 at 09:41
  • There might be rules specific for blocking ICMP. There might also be a generic rule to drop everything from outside and only allow specific data in. Hard to tell. But note that you can explicitly set the MTU of the link in order to deal with the problem. – Steffen Ullrich Dec 12 '19 at 09:50
  • @Steffen Ullrich yes, that is what I did, but I am still want to know why it is not working as I think it should. – aljazerzen Dec 12 '19 at 11:00
  • If the TCP stack does not get the ICMP information then it has no idea that adjustments need to be done. I guess the relevant ICMP are somewhere dropped. – Steffen Ullrich Dec 12 '19 at 11:05
  • Hello, did you find a solution ? I've more or less the same problem. My SIM7600 is configured to use 1500 MTU, TCP connection uses 1500 MTU (I can see this in my dump, in SYN package) but if I run a qmicli --wds-get-current-settings I got a MTU of 1430. So my modem doesn't send package more than 1430 bytes => ICMP fragmentation needed – Damgot Feb 21 '22 at 12:34
  • I've lowered MTU setting in the NetworkManager to 1430 so the kernel fragments the packet to sizes I know the modem can handle. – aljazerzen Feb 21 '22 at 13:42

0 Answers0