On 10/14/24 5:35 AM, Richard W.M. Jones wrote:
On Mon, Oct 14, 2024 at 09:52:13AM +0100, Daniel P. Berrangé wrote:
Urgh, I wonder if this is fallout from switching to NFT instead of iptables.
I can list the firewall rules if you tell me what I'm looking for ...
IIUC, the NFT kernel maintainers didn't implement for checksum fixup rules,
since they believe that all modern distros would have long ago fixed their
bugs wrt mangled checksums.
That's the first thing that came to my mind too - maybe RHEL5 *isn't*
the only guest OS that has this problem. (I certainly hope that isn't
the case :-/)
There are two ways to test out this theory:
1) change the setting of "firewall_backend" in /etc/libvirt/network.conf
to "iptables" and restart virtnetworkd
(if that does work, then switch back to nftables, restart virtnetworkd,
and test again just to make sure the issue wasn't caused by some
out-of-place rule)
or
2) tell qemu to setup the virtio-net device to do its packet processing
in userspace rather than the kernel. You do this by adding
<driver name='qemu'/>
to the <interface> section.
If I understand the trace correctly, the bad checksum originates on
the Linux host (the reply sent by dnsmasq).
I need to try it again to verify, but my recollection is that (when
you're using virtio-net with default settings) the checksums of DHCP
packets in one direction or the other *always* show up in tcpdump as
having bad checksums, but they still end up getting to the other end
with a proper checksum. Sometime in the distant past I *may have* had it
explained to me why this happens, but I don't recall now. Anyway, I'm
just saying this so that you know the validity of the UDP checksum
shouldn't be used as an indicator of whether or not things are "working".
