[Qemu-devel] virtio-net & dhcp & udp checksum

[Qemu-devel] virtio-net & dhcp & udp checksum

[Alexey Kardashevskiy]

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?


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.


-- 
Alexey

Re: [Qemu-devel] virtio-net & dhcp & udp checksum

[Michael S. Tsirkin]

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

Re: [Qemu-devel] virtio-net & dhcp & udp checksum

[Alexey Kardashevskiy]

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/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.

Sure, I am just trying to educate myself and understand what to expect and
what is broken :)



-- 
Alexey

Re: [Qemu-devel] virtio-net & dhcp & udp checksum

[Michael S. Tsirkin]

On Tue, Sep 06, 2016 at 09:00:30PM +1000, Alexey Kardashevskiy wrote:
> 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?

It's returned in the aux data. See linux commit below.

> 
> > 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?

Yes - no one bothered teaching tcpdump about this commit:

    commit 8dc4194474159660d7f37c495e3fc3f10d0db8cc
    Author: Herbert Xu <herbert@gondor.apana.org.au>
    Date:   Sun Feb 4 23:31:32 2007 -0800
        [PACKET]: Add optional checksum computation for recvmsg


> >>
> >> 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.
> 
> Sure, I am just trying to educate myself and understand what to expect and
> what is broken :)

If you have the time, try adding the patch to dhcp in debian.
Maybe it was ubuntu that was carrying it? You can try that ...


> 
> 
> -- 
> Alexey