Your message dated Tue, 15 Jan 2019 13:40:56 +0100
with message-id <[email protected]>
and subject line Configuration problem, closing the bug
has caused the Debian Bug report #835420,
regarding bridge-utils: enabling rp_filter causes network to hang
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
835420: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835420
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: bridge-utils
Version: 1.5-9
Severity: important
Dear Maintainer,
As I was strolling through the nightmares of the Debian and/or real world....
Well.
When you set up a bridge (as far as I can tell, any) based on an existing
interface (such as eth0) and then run a firewall that will enable rp_filter for
that bridge device, the entire network will hang including the origin device of
the bridge.
In this case the thing was configured using:
/etc/network/interfaces:
iface eth0 inet dhcp
iface eth0:1 inet manual
iface br1 inet static
bridge_ports eth0:1
bridge_fd 0
address <address>
netmask 255.255.255.0
Each time the firewall would run, the network would block until I found it was
basically caused by a single line, saying:
echo 1 > /proc/sys/net/ipv4/conf/br1/rp_filter
I do not know how this works behind the schemes .. but activiting this on an
unrelated bridge (that does not have any ports mapped to it) does not actually
kill the connection in the same way.
Since br1 is based on eth0:1 which is based on eth0, it apparently just kills
that by whatever I don't know, and the system does not have other devices for
connecting to it, so I cannot test anything else.
I should note that the system runs 3.16.0-4-amd64 from Debian 3.16.7-ckt25-2 on
Jessie from (2016-04-08) on x64-64 virtualized within QEMU (i440FX, PIIX, 1996)
although that will probably be quite irrelevant.
This happens irrespective of any firewall rules being present and also with a
default routing table.
Meaning, I can kill my network using the above command no matter what the state
of my system is. As long as the bridge is activated and put online, I assume.
Regards, Dryden.
Oh, I can usually (but not always) reverse the situation by echoing 0 into it
again. For some reason that never seems to work all that well when more stuff
has happened, but I'm not sure. Thus far I have been able to revert it after
manually causing it.
-- System Information:
Debian Release: 8.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages bridge-utils depends on:
ii libc6 2.19-18+deb8u4
bridge-utils recommends no packages.
Versions of packages bridge-utils suggests:
ii ifupdown 0.7.53.1
-- no debconf information
--- End Message ---
--- Begin Message ---
This bug was a configuration problem rather than a bug, I'm closing it.
Regards.
--
Manty/BestiaTester -> http://manty.net
--- End Message ---
