All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Hartmann <andihartmann@01019freenet.de>
To: netdev@vger.kernel.org
Cc: john.fastabend@gmail.com
Subject: Re: Linux 4.14 - regression: broken tun/tap / bridge network with virtio - bisected
Date: Mon, 27 Nov 2017 17:46:14 +0100	[thread overview]
Message-ID: <fc8cef7d-7b5a-d72a-9c31-5890fdac68c6@01019freenet.de> (raw)
In-Reply-To: <9615150a-eb78-2f9d-798f-6aa460932aec@01019freenet.de>

On 11/26/2017 at 03:17 PM Andreas Hartmann wrote:
> Hello!
> 
> Since Linux 4.14 (running as host), the virtual network based on bridge
> and tun/tap-devices is partly broken. Linux 4.13.x or earlier works
> perfectly.
> 
> 
> Given is the following architecture on host:
> 
> VM1 -> tun/tap -> br1
> VM2 -> tun/tap -> br0 / br1
> VM3 -> tun/tap -> br0
> 
> Example network configuration of the VMs:
> 
>     <interface type='bridge'>
>       <mac address='...'/>
>       <source bridge='br0'/>
>       <model type='virtio'/>
>     </interface>
> 
> 
> Host is connected through br1.
> 
> 
> VM2 is the router between two different networks provided by br1 and br0.
> 
> VM3 can be reached by the host via ssh through the router.
> There are some more VMs in the network provided by br0 - e.g. VM4.
> 
> Mostly all VMs are Centos 7 / 64bit (Linux 3.10.x) VMs provided by
> kvm_amd. VM1 uses Linux 4.4.x.
> 
> 
> Now, VM1 sends a UDP IPv4 package (it's the first radius message from
> hostapd during initialization of a EAP-TLS handshake with a WLAN client
> - Access Request) to VM3. This package is answered by VM3 (Access
> Challenge) and received by VM1.
> 
> Next, VM1 sends the second Access Request. I'm not sure, if this package
> is still received by VM3 or not. But this is sure: VM1 never gets any
> answer and the connection to VM3 is now *completely dead*. It isn't even
> possible to reach VM3 by ssh any more.
> 
> There aren't any log messages - neither on the host, nor on the VM.
> Other VMs aren't affected.
> 
> 
> Bisecting the problem leads to this patch:
> 
> 2ddf71e23cc246e95af72a6deed67b4a50a7b81c
> net: add notifier hooks for devmap bpf map
> 
> 
> It turns out, that the problem can be worked around by using e1000 as VM
> interface instead of virtio for VM1 and 3:
> 
>     <interface type='bridge'>
>       <mac address='52:54:00:15:ac:42'/>
>       <source bridge='br0'/>
>       <!-- <model type='virtio'/> -->
>       <model type='e1000'/>
>     </interface>
> 
> 
> Would it be possible to fix this problem to get it working again with
> virtio? Do you need some more information? Feel free to ask!

Some additional information:

Using virtio not just breaks the network completely as described above,
it even leaves a never stoppable or restartable qemu process (even kill
-9 doesn't work). It's absolutely necessary to *force* a reboot to exit
or restart the VM.

I switched back to linux 4.13 as 4.14 virtualization is quite unusable.

I'm not the only one affected:
https://bugzilla.kernel.org/show_bug.cgi?id=197861


Thanks,
Andreas

  reply	other threads:[~2017-11-27 16:48 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-26 14:17 Linux 4.14 - regression: broken tun/tap / bridge network with virtio - bisected Andreas Hartmann
2017-11-27 16:46 ` Andreas Hartmann [this message]
2017-11-27 16:55   ` Michal Kubecek
2017-11-27 19:09     ` Andreas Hartmann
2017-12-01 10:11 ` Andreas Hartmann
2017-12-03 11:35   ` Andreas Hartmann
2017-12-04 16:28     ` Andreas Hartmann
2017-12-05  3:50       ` Jason Wang
2017-12-05 16:23         ` Andreas Hartmann
2017-12-06  3:08           ` Jason Wang
2017-12-08  7:21             ` Andreas Hartmann
2017-12-08  8:47               ` Michal Kubecek
2017-12-08 10:31                 ` Andreas Hartmann
2017-12-08 11:40                   ` Michal Kubecek
2017-12-08 12:45                     ` Andreas Hartmann
2017-12-08 12:58                       ` Michal Kubecek
2017-12-08 13:13                         ` Andreas Hartmann
2017-12-08 15:11                           ` Jason Wang
2017-12-08 16:04                     ` Willem de Bruijn
2017-12-08 20:11                       ` Andreas Hartmann
2017-12-08 20:44                         ` Andreas Hartmann
2017-12-11 15:54                           ` Andreas Hartmann
2017-12-14 16:31                             ` Andreas Hartmann
2017-12-14 22:17                             ` Willem de Bruijn
2017-12-14 22:47                               ` Willem de Bruijn
2017-12-15  6:05                               ` Andreas Hartmann
2017-12-17 22:33                                 ` Willem de Bruijn
2017-12-18 17:11                                   ` Andreas Hartmann
2017-12-20 15:56                                     ` Andreas Hartmann
2017-12-20 22:44                                       ` Willem de Bruijn
2017-12-21 17:05                                         ` Andreas Hartmann
2017-12-21 17:11                                           ` Willem de Bruijn
2017-12-24 16:24                                       ` Andreas Hartmann
2017-12-24 18:54                                         ` Willem de Bruijn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fc8cef7d-7b5a-d72a-9c31-5890fdac68c6@01019freenet.de \
    --to=andihartmann@01019freenet.de \
    --cc=john.fastabend@gmail.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.