[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJPywTKDdjtwkLVUW6LRA2FU912qcDmQOQGt2WaDo28KzYDg+A@mail.gmail.com>
Date: Wed, 12 Jul 2023 16:00:31 +0200
From: Marek Majkowski <marek@...udflare.com>
To: network dev <netdev@...r.kernel.org>, Yan Zhai <yan@...udflare.com>,
kernel-team <kernel-team@...udflare.com>
Subject: Broken segmentation on UDP_GSO / VIRTIO_NET_HDR_GSO_UDP_L4 forwarding path
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
Powered by blists - more mailing lists