[BUG] inexact MTU calculation for PDU session interface

[yoursunny]

Describe the bug
When PacketRusher creates a PDU session valXXXXXXXXXX interface, the MTU size calculation is off by 8 octets, which forces IPv4 fragmentation on the N3 network.

To Reproduce
Steps to reproduce the behavior:

1. Start PacketRusher with PDU session tunnel feature enabled.
2. Wait for PDU session establishment.
3. Observe the MTU of valXXXXXXXXXX interface and n3 interface.
4. Transmit an uplink ICMP ping at exactly the MTU size, and observe the traffic on n3 interface.

Expected behavior
MTU of valXXXXXXXXXX interface should be small enough so that uplink packets do not experience IPv4 fragmentation on n3 interface.

Screenshots

ubuntu@N0:~$ docker exec gnb0 ip link
5: val7005551000: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1464 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none
13785: n3@if13786: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
    link/ether 52:de:ac:19:c3:12 brd ff:ff:ff:ff:ff:ff link-netnsid 0

Architecture (please complete the following information):

• OS: Docker 27.3.1 on Ubuntu 22.04
• Platform: amd64
• Version: fd83fec
• Kernel: 5.15.0-127-lowlatency with gtp5g v0.9.6

Log:

time="2025-01-03T21:33:54Z" level=info msg="[UE][GTP] Interface val7005551000 has successfully been configured for UE 10.1.0.1"
time="2025-01-03T21:33:54Z" level=info msg="[UE][GTP] You can do traffic for this UE by binding to IP 10.1.0.1, eg:"
time="2025-01-03T21:33:54Z" level=info msg="[UE][GTP] iperf3 -B 10.1.0.1 -c IPERF_SERVER -p PORT -t 9000"

Pcap:
Packet trace: 2.pcapng.gz

Additional context
Outer IPv4 header has 20 octets; outer UDP header has 8 octets; GTPv1 header including PDU Session Container extension has 16 octets.
Total header overhead is 44 octets, so that valXXXXXXXXXX interface MTU should be 1500-44=1456 octets.

While this does not prevent communication, it is a performance overhead as the UPF now has to perform IPv4 reassembly.
This is most likely a regression introduced during #135 QFI implementation.

[linouxis9]

Hi @yoursunny,

Thanks a ton for the very nice report! Yes it's quite likely that this issue was introduced by the PR you mentioned.
Since I added an additional header in all GTP-U packets, the effective payload (/MTU of the interface) that can be transported in the GTP-U tunnel is now lower.

I'll submit a patch.

Thanks for reporting and your help diagnosing this issue!
Valentin

[linouxis9]

Hi @yoursunny,

After a careful check, we actually never set the MTU inside PacketRusher, we let gtp5g completely handle the interface creation.

The bug seems to be actually in gtp5g, as their calculation seems to forget to include the extension header: https://github.com/free5gc/gtp5g/blob/11ff34a9f13df040b43883a1ceddc22c6869622a/src/gtpu/link.c#L31
Free5GC's UPF does not seem to be affected as they usually overwrite the interface's MTU to 1400 in the sample configurations.

I can add a call inside PacketRusher to overwrite the MTU set by the gtp5g kernel module (setting the MTU as underlying interface's MTU - 44 as you rightfully pointed out), but it might be worth fixing this issue in gtp5g directly too.
Tings is, when the interface is created, gtp5g does not yet know if the extension header will be used.

Thanks!
Valentin

[yoursunny]

Free5GC's UPF does not seem to be affected as they usually overwrite the interface's MTU to 1400 in the sample configurations.

Maybe PacketRusher could offer the same configuration option?
This way, when I run free5GC+PacketRusher combination, I can set the same MTU on both sides.