pathMTU tuning needs parameter tcp_mtu_probe_ceiling
Bug #1953030 reported by
Bernhard Riegler
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| kernel-package (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
Bug Description
I found the parameter tcp_mtu_probe_floor
I need an additional parameter tcp_mtu_
why ?
If the tcp-connection goes only in a broadcast domain
(no IPv4 router in between, sending ICMP frag needed)
the pathMTU algorithm goes crasy.
I have 2 nodes IPv4 10.0.0.2 (ethernet cable) and 10.0.0.4 (802.11n)
testing with "iperf3 -s -i 5" as server on Ubuntu 20.04 LTS (10.0.0.2)
and ANDROID12 "MAGIC iperf3" as client (iperf3 -c 10.0.0.2 -t 22 -i 5 -P 1 -Z -O 5)
(10.0.0.4)
monitoring with wireshark shows ip packets with ip.len 65212 and tcp flags push,ack.
this does not work with the HW buffers of the LANIC,
therefore a reqest a control with parameter "tcp_mtu_
Revision history for this message
| Bernhard Riegler (riegler-b) wrote | #1 |
Revision history for this message
| Bernhard Riegler (riegler-b) wrote | #2 |
To post a comment you must log in.
I repeated the tests with LANIC HW features Large ReceiveO ffload and TCP Segmentation Offload
turned OFF.
Now the IPv4 packets are stable with MTU=1500 and TCP MSS=1460 in a broadcast domain.
the IPv4 packets up to 64KiB are caused by the HW features of LANIC and not by pathMTU algorithm.
you can close this request.