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. Of course old dhclient ignores this flag. I think Debian used to carry a patch to make it take it into account. > > I read the old discussion at > http://www.mail-archive.com/kvm@vger.kernel.org/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. > > -- > Alexey
