Re: [PATCH (RFC and a half?)] network: add rule to nftables backend that zeroes checksum of DHCP responses
On 10/24/24 2:12 PM, Laine Stump wrote:
On 10/24/24 12:36 PM, Daniel P. Berrangé wrote:
>> [...]
>
> AFAIR, it isn't actually a bug with virtio-net usage as this last
> bit suggests. Rather it is a result of feature negotiation with QEMU
> on the host, whereby the guest & QEMU mutually agree to turn off
> checksums because they are redundant when the "link" is just local
> memory not a physical cable.
>
> IOW, packets don't arrive in the guest with a bad checksum. They
> arrive in the guest with no checksum *as requested* by the guest.
>
> The DHCP client decides this is a bad checksum, as it wasn't
> aware of the checksum offload usage.
>
> [...]
>
> ....and in Fedora/RHEL context it was fixed 18 years ago, as we
> first hit this when working on Xen integration in 2006 :-)
I think you would have to say "in Fedora/RHEL+Xen context it was fixed
18 years ago", since the specific test case that I recall working with
was a RHEL5 guest that couldn't get an address from DHCP. So RHEL still
had the problem, it just took switching to QEMU + virtio + vhost packet
processing to make it visible :-)
>
>> A few quick tests proved that it was the same old "bad checksum"
>> problem from 2010 come back to haunt us.
>
> 2006 :-)
Interesting - so my origin story is at least partially a false memory :-/
But if you had this problem with Xen in 2006, how was it fixed then (and
why was it a surprised when it came up again in 2010 after vhost
processing was turned on? Or maybe it wasn't a surprise, and I just
thought so because I wasn't around in 2006 :-)
(The commit adding --checksum-fill rules to libvirt was fd5b15ff1, from
July 2010)