On 06/09/16 20:03, Michael S. Tsirkin wrote: > On Tue, Sep 06, 2016 at 02:32:27PM +1000, Alexey Kardashevskiy wrote: >> Hi! >> >> I am trying DHCP between 2 guests. So I am running first guest with: >> >> -netdev tap,id=TAP0,helper=/home/aik/qemu-bridge-helper \ >> -device "virtio-net-pci,id=vnet0,mac=C0:41:49:4b:ee:ee,netdev=TAP0" >> >> and second one with: >> >> -netdev tap,id=TAP0,vhost=on,helper=/home/aik/qemu-bridge-helper \ >> -device "virtio-net-pci,id=vnet0,mac=C0:41:49:4b:00:01,netdev=TAP0" \ >> >> >> Both tap are connected to br0 on the host: >> >> aik@fstn1-p1:~$ brctl show >> bridge name bridge id STP enabled interfaces >> br0 8000.fe397c73cecc no tap0 >> tap1 >> >> Both guests are debian8 with v4.7 kernel, one is running Dnsmasq version >> 2.72, the other - isc-dhclient-4.3.1. >> >> The very first response from dnsmasq has a bad UDP checksum: >> >> 04:19:04.946754 c0:41:49:4b:ee:ee > c0:41:49:4b:00:01, ethertype IPv4 >> (0x0800) >> , length 346: (tos 0xc0, ttl 64, id 60635, offset 0, flags [none], proto UDP >> ( >> 17), length 332) >> 192.168.1.250.67 > 192.168.1.1.68: [bad udp cksum 0x8595 -> 0x6e44!] >> BOOTP >> /DHCP, Reply, length 304, xid 0x38e6b51c, Flags [none] (0x0000) >> >> 0x8595 looks like a UDP header checksum. Unlike dhclient (which uses >> PF_PACKET), dnsmasq seems to use AF_INET and DGRAM so I am wondering what >> exactly should do this checksum calculations in this case and why it does >> not do this? > > Receiver should - the packet is clearly marked as such.
Where is that mark exactly? UDP header (unlikely)? IP header (cannot see it)? DHCP? > Of course old dhclient ignores this flag. I think Debian used to > carry a patch to make it take it into account. So seeing bad UDP checksum message in tcpdump of the _source_ (dnsmasq's tap) side is ok? >> >> I read the old discussion at >> http://www.mail-archive.com/[email protected]/msg41958.html >> >> but it seems that in my case the broken thing is dnsmasq (which is hard to >> believe). Running the dnsmasq's guest with >> >> -device virtio-net-pci,id=vnet0,csum=off,... >> >> fixes the problem. >> >> What is broken now? Thanks. > > Maybe debian dropped the patch from dhcp? > http://marc.info/?l=kvm&m=129347023113779 > > Or you can use the host-side workaround using a checksum rule. Sure, I am just trying to educate myself and understand what to expect and what is broken :) -- Alexey
