Having pondered this for a while, it's more complex than I at first thought. UDP checksums are optional (for IPv4) according to RFC 768:
"If the computed checksum is zero, it is transmitted as all ones (the equivalent in one's complement arithmetic). An all zero transmitted checksum value means that the transmitter generated no checksum (for debugging or for higher level protocols that don't care)." So it's up to the transmitting application, whether it will generate UDP checksums. Unlike TCP, traffic, for UDP traffic, it is not the IP stack or NIC driver's responsibility to generate the checksum. There is also no way to know whether an outgoing UDP packet actually has a valid checksum calculated by the application, or whether it's just junk data due to a lazy programmer not zeroing a buffer before use. Therefore, virtio cannot assume that the checksum is bogus and overwrite it with zeros. Strangely, two separate tcpdump captures of arbitrary UDP traffic inside two separate VMs on the same host, one with virtio NIC configured, and one with e1000 NIC, both had correct checksums for incoming packets (according to Wireshark). This doesn't really explain why setting the VM's virtual NIC type to e1000 fixes this problem on the dhcpd VM. It possibly implies that the virtio NIC emulation is tampering with the UDP checksum of incoming packets, causing dhcpd to complain. Or another way to look at it, the e1000 emulation may in fact be writing the _correct_ checksum into all UDP packets. I would need to capture the packets on the hypervisor host, before they enter the VM. The file "common/packet.c" from ISC dhcpd source is where this "bad udp checksum" error is being raised, and contains code that will skip the UDP checksum verification if the incoming packet's checksum is zero. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org