lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 19 Sep 2018 11:10:22 +0200
From:   Johannes Wienke <jwienke@...hfak.uni-bielefeld.de>
To:     netdev@...r.kernel.org
Subject: Bridge connectivity interruptions while devices join or leave the
 bridge

I am sorry for probably misusing this list, but I couldn't find any
other mailing list suitable for asking in-detail Linux networking
questions. As I am not subscribed, please CC me in a potential reply.

I am currently tracking down a connectivity issues of docker containers
on a custom bridge network, which I could reduce to the Linux network
stack without docker being involved.

The situation that I am observing is the following: I have a bridge
device, which is connected to the outer world using forwarding and
masquerading (so the bridge does not contain the outgoing network
interface of the host). This bridge is used to perform network
operations by a long-running process, which is restricted to this bridge
using network namespaces and veth devices (exactly what docker does
internally). What I see is that every time a (virtual) network device is
added to or removed from the bridge, the communication of the
long-running process is interrupted.

I have created two scripts that can be used to replicate the situation.
They are available at:
https://gist.github.com/languitar/9ac8dc5c8db7cf4a89e1546f6e32ca7b

setup.bash sets up the bridge, veth devices, network namespace and the
iptables rules to replicate the network setup and simulates the
long-running process by periodically performing (volatile) UDP DNS
requests in a while loop.

When launching this script, all DNS requests should succeed and you
should see success messages at a regular pace.

To simulate devices joining and leaving the bridge, you can start
interruptor.bash.

As soon as this script is running, you can observe that DNS requests
will be delayed frequently and some of them even fail. In a parallel
pcap you would see that sometimes the UDP packages from the DNS lookup
are not routed to the outside world, but instead end up at the bridge
device without ever leaving the host system.

Can someone explain what is happening here and why adding and removing
devices to a bridge results in the connectivity issues? How to avoid
this behavior? I'd be glad for any hint on that.

Kind regards
Johannes
-- 
Johannes Wienke, Researcher at CoR-Lab / CITEC, Bielefeld University
Address: Inspiration 1, D-33619 Bielefeld, Germany (Room 1.307)
Phone: +49 521 106-67277

Powered by blists - more mailing lists