Date:	Thu, 27 Sep 2012 23:17:04 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Chris Clayton <chris2553@...glemail.com>,
	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org, gpiez@....de
Subject: Re: Possible networking regression in 3.6.0

On Thu, 2012-09-27 at 23:03 +0200, Eric Dumazet wrote:
> On Thu, 2012-09-27 at 19:05 +0100, Chris Clayton wrote:
> > On 09/27/12 13:14, Eric Dumazet wrote:
> > > On Thu, 2012-09-27 at 12:50 +0100, Chris Clayton wrote:
> > >> Just for information - I've pulled Linus' tree this morning and the
> > >> problem is still present. Also, Gunther Piaz has reported, via the
> > >> bugzilla entry, that he too has hit this regression.
> > >
> > > I tried to reproduce the bug, and my kvm guests have no problem.
> > >
> > > I guess you need to precisely describe how you setup your network, so
> > > that I can reproduce the problem and eventually fix it.
> > >
> > 
> > You've seen the bits from my firewall setup script that relate to this 
> > issue. I start the WinXP client with another script:
> > 
> > #!/bin/sh
> > if [ -e $HOME/kvm/var/run/kvm-winxp.pid ]; then
> >      echo "winxp is already running ..." > /dev/stderr
> >      exit 1
> > fi
> > 
> > # make sure the kvm modules are loaded
> > if test -z "$(grep '\<kvm\>' /proc/misc)"; then
> >      sudo modprobe kvm-intel
> >      while test -z "$(grep '\<kvm\>' /proc/misc)"; do
> >          true
> >      done
> > fi
> > 
> > # make sure tun module is loaded
> > if test ! -e /dev/net/tun; then
> >      sudo modprobe tun
> > fi
> > 
> > # figure out the cpu to use
> > QVER=$(qemu-kvm --version | cut -d' ' -f 4 | sed 's/,/./')
> > # assumes major version is 1
> > MINORVER=$(echo $QVER | cut -d'.' -f 2)
> > if [ $MINORVER -ge 1 ]; then
> >      CPU="host"
> > else
> >      CPU="qemu64"
> > fi
> > 
> > # set up the network interface
> > TAPDEV=$(sudo tunctl -b -u $(whoami))
> > sudo ifconfig $TAPDEV 192.168.200.254 netmask 255.255.255.0 broadcast 
> > 192.168.200.255
> > 
> > # start Windows XP
> > qemu-kvm -drive file=$HOME/kvm/winxp.qcow2,index=0,cache=none,if=virtio 
> > -cpu $CPU -smp cores=1,threads=2 -soundhw es1370 \
> >      -m 768 -net nic,model=virtio,macaddr=$(getmacaddr) -net 
> > tap,ifname=$TAPDEV -startdate $(date +%Y-%m-%dT%H:%M:%S) \
> >      -name kxplaptop -pidfile $HOME/kvm/var/run/kvm-winxp.pid $*
> > 
> > # stop the network interface
> > sudo ifconfig $TAPDEV down
> > sudo tunctl -d $TAPDEV &>/dev/null
> > 
> > # tidy up
> > rm -f $HOME/kvm/var/run/kvm-winxp.pid
> > 
> > 
> > The call to getmacaddr just returns the next in a sequence of mac 
> > addresses. qemu-kvm is a symlink to /usr/bin/qemu-system-i386. I first 
> > found the problem whilst running qemu-kvm version 1.1.1 although I've 
> > since updated to 1.2.0.
> > 
> > By the way, I doubt it will make a difference, but, although my laptop 
> > has a 64bit CPU, I am running a 32 bit kernel and, obviously, user space.
> > 
> > Let me know if you need anything else.
> 
> It works for me.
> 
> Hmm, maybe your guest is using DHCP and DHCP fails ?

Yes it seems the problem. On the host I tried :

# ip ro get 8.8.8.8 from 192.168.200.1 iif tap1
8.8.8.8 from 192.168.200.1 via 172.30.42.1 dev eth0 
    cache  iif *

So if the guest tries to send a frame to 8.8.8.8 we are going to forward
the packet to eth0

But if the guest tries to send to 255.255.255.255, we try to deliver the
packet to the host itself, instead of broadcasting to eth0

# ip ro get 255.255.255.255 from 192.168.200.1 iif tap1
broadcast 255.255.255.255 from 192.168.200.1 dev lo 
    cache <local,brd>  iif *


David, maybe you'll have an idea ?

Thanks


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists