Re: FreeBSD dhcp failing with UDP checksum errors
On Mon, Oct 14, 2024 at 10:46:22AM -0400, Laine Stump wrote:
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)
I changed the setting between nftables and iptables a few times and I
can confirm that your theory seems to be correct.
iptables =>
"5 bad udp checksums in 5 packets" message is NOT seen
FreeBSD gets an immediate DHCPOFFER and boots quickly with network
nftables =>
FreeBSD sends 5 DHCPDISCOVER messages
"5 bad udp checksums in 5 packets" reappears
FreeBSD does NOT see DHCPOFFER, although it does seem to remember
the offer from the previous boot, so it does get a network
connection in the end.
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.
This also works (with nftables).
>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".
I have to say I also don't really understand what's happening here.
Isn't the Linux host sending DHCPOFFER? Why doesn't it set the UDP
checksum correctly and/or why would tcpdump report it wrongly if it is
setting it?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org