Broken segmentation on UDP_GSO / VIRTIO_NET_HDR_GSO_UDP_L4 forwarding path
From: Marek Majkowski <hidden>
Date: 2023-07-12 14:00:57
Dear netdev, I encountered a puzzling problem, please help. Rootless repro: https://gist.github.com/majek/5e8fd12e7a1663cea63877920fe86f18 To run:
$ unshare -Urn python3 udp-gro-forwarding-bug.py
tap0 In IP 10.0.0.2.55892 > 1.1.1.1.5021: UDP, length 4000
lo P IP 10.0.0.2.55892 > 1.1.1.1.5021: UDP, bad length 4000 > 1392
lo P IP 10.0.0.2.43690 > 1.1.1.1.43690: UDP, bad length 43682 > 1392
lo P IP 10.0.0.2.43690 > 1.1.1.1.43690: UDP, bad length 43682 > 1200
'''
The code is really quite simple. First I create and open a tap device.
Then I send a large (>MTU) packet with vnethdr over tap0. The
gso_type=GSO_UDP_L4, and gso_size=1400. I expect the packet to egress
from tap0, be forwarded somewhere, where it will eventually be
segmented by software or hardware.
The egress tap0 packet looks perfectly fine:
tap0 In IP 10.0.0.2.55892 > 1.1.1.1.5021: UDP, length 4000
To simplify routing I'm doing 'tc mirred' aka `bpf_redirect()` magic,
where I move egress tap0 packets to ingress lo, like this:
> tc filter add dev tap0 ingress protocol ip u32 match ip src 10.0.0.2 action mirred egress redirect dev lo
On ingress lo I see something really weird:
lo P IP 10.0.0.2.55892 > 1.1.1.1.5021: UDP, bad length 4000 > 1392
lo P IP 10.0.0.2.43690 > 1.1.1.1.43690: UDP, bad length 43682 > 1392
lo P IP 10.0.0.2.43690 > 1.1.1.1.43690: UDP, bad length 43682 > 1200
This looks like IPv4 fragments without the IP fragmentation bits set.
I think there are two independent problems here:
(1) The packet is *fragmented* and that is plain wrong here. I'm
asking for USO not UFO in vnethdr.
(2) The fragmentation attempt is broken, the IPv4 fragmentation bits are clear.
Please advise. I would assume transmitting UDP_GSO packets off tap is
a typical thing to do.
I was able to repro this on a 6.4 kernel.
For a moment I thought it's a `ethtool -K X rx-udp-gro-forwarding on`
bug, but I'm not sure anymore.
Marek