Bug 1182105 - sysctl.conf / sysctl.conf.d settings should be applied after bridge is added
Summary: sysctl.conf / sysctl.conf.d settings should be applied after bridge is added
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: systemd
Version: 7.0
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: systemd-maint
QA Contact: Vaclav Danek
: 1122700 1213313 (view as bug list)
Depends On:
Blocks: 1205796 919472
TreeView+ depends on / blocked
Reported: 2015-01-14 12:57 UTC by Michal Sekletar
Modified: 2019-12-16 04:37 UTC (History)
13 users (show)

Fixed In Version: systemd-219-2.el7
Doc Type: Bug Fix
Doc Text:
Cause: Settings from sysctl.conf for bridges were applied only during boot. Problem is that the kernel bridge module could be loaded later, so such settings is not applied. Consequence: Fix: We have added a udev rule which applies those setting when bridge module is loaded. Result:
Clone Of: 1122700
Last Closed: 2015-11-19 15:04:10 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2092 0 normal SHIPPED_LIVE systemd bug fix and enhancement update 2015-11-19 12:13:57 UTC

Comment 2 Laine Stump 2015-02-23 19:52:14 UTC
This was posted to the original of this BZ (filed against Fedora) last week:

(Scott Shambarger from comment #43 of Bug 634736)
> Just noticed the boot message:
> bridge: automatic filtering via arp/ip/ip6tables has been deprecated. Update
> your scripts to load br_netfilter if you need this.
> The new module appears to export the bridge sysctl values, but the udev rule
> in /lib/udev/rules.d/99-bridge.rules still refers to the bridge module (not
> the br_netfilter module), and so the bridge netfilter values after loading
> br_netfilter are:
> net.bridge.bridge-nf-call-arptables = 1
> net.bridge.bridge-nf-call-ip6tables = 1
> net.bridge.bridge-nf-call-iptables = 1
> Granted, if you load br_netfilter explicitly, you probably want to use it,
> but then /usr/sysctl.d/50-bridge.conf should probably be removed as it is no
> longer needed to disable bridge netfilter (by default) anymore.

Here is my comment on that, lifted from the same BZ:

(Laine Stump from comment #44 of Bug 634736)
> After all these years of asking for the default of bridge filtering to be
> "disabled" and the change being refused by the kernel maintainers, now the
> filtering has been moved into a separate module that isn't loaded (by
> default) when the bridge module is loaded, effectively making the default
> "disabled". Yay!
> I *think* this is in the kernel as of 3.17 (It definitely is in kernel
> 3.18.7-200.fc21, and appears to be in git prior to the tag "v3.17-rc4")
> So again the problem has disappeared for our case, so we're happy, but the
> general problem (as in the latest version of this bug's summary) is still
> there. What is the proper action for this BZ then? Do we leave it around
> (knowing that, based on the experience up to now, the general problem will
> likely never be fixed), close it as WONTFIX, or close it with one or another
> of the "resolved" reasons, since our particular problem has been fixed by
> the addition of the new module?

There is a similar question for RHEL - when RHEL7 moves up to a new enough kernel (or backports the br_netfilter module) should this BZ be closed as a result, or do we leave it open in the likely fruitless hope that a general purpose solution for setting non-compiled-in defaults of kernel module settings at module load time will be implemented?

Or, do we leave it open in the expectation that it will take the RHEL7 kernel a long time to catch up, and continue to ask for a systemd-based fix in the meantime? (I don't really like that idea, but wanted to put all the options up)

Comment 3 David Shea 2015-04-14 17:45:58 UTC
*** Bug 1122700 has been marked as a duplicate of this bug. ***

Comment 4 David Shea 2015-04-20 13:08:44 UTC
*** Bug 1213313 has been marked as a duplicate of this bug. ***

Comment 5 Lukáš Nykrýn 2015-05-13 15:13:11 UTC
lets go for the short-time solution in rhel


Comment 7 errata-xmlrpc 2015-11-19 15:04:10 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Comment 8 Milos Vyletel 2016-08-17 12:49:40 UTC
I'm sorry to revive this old BZ but the fixed pulled in does not really work.
there is a quite large window between raising the udev event in kernel and
actually creating the sysctls. looking at 7.2 kernel source we do

init_module() syscall
      kobject_uevent(&mod->mkobj.kobj, KOBJ_ADD);

if the udev event is processed anywhere between the mod_sysfs_setup() and
br_netfilter_init() the setting do not get set. one customer noticed this and
as a test created simple udev rule that triggers at this time and runs

[root@compute-1 ~]# cat /lib/udev/rules.d/41-kha.rules 
# do not edit this file, it will be overwritten on update

# reload sysctl.conf / sysctl.conf.d settings when the bridge module is loaded
ACTION=="add", SUBSYSTEM=="module", KERNEL=="bridge", RUN+="/root/bridgetest.sh"
[root@compute-1 ~]# cat bridgetest.sh 
exec >> /tmp/bridgetest.log

echo triggered..
ls -l /proc/sys/net/bridge
echo sleeping...
sleep 1
ls -l /proc/sys/net/bridge
[root@compute-1 ~]# 

which gives following output

Wed Aug  3 14:39:45 EEST 2016
Wed Aug  3 14:39:46 EEST 2016
total 0
-rw-r--r--. 1 root root 0 Aug  3 14:39 bridge-nf-call-arptables
-rw-r--r--. 1 root root 0 Aug  3 14:39 bridge-nf-call-ip6tables
-rw-r--r--. 1 root root 0 Aug  3 14:39 bridge-nf-call-iptables
-rw-r--r--. 1 root root 0 Aug  3 14:39 bridge-nf-filter-pppoe-tagged
-rw-r--r--. 1 root root 0 Aug  3 14:39 bridge-nf-filter-vlan-tagged
-rw-r--r--. 1 root root 0 Aug  3 14:39 bridge-nf-pass-vlan-input-de

note that the first ls does not show anything...

question really is how to fix this. kernel can be quite easily modified to
trigger the event after do_init_module() finishes but this is not in upstream
so there may be some pushback or we can pull in the split to br_netfilter
and reduce the number of use cases where this happens. in any case what we
have now does not seem to be sufficient

Comment 10 ilmostro7 2016-10-22 21:04:57 UTC
The status of this Bug is "CLOSED".  Does the last response not warrant it to be re-opened?

Comment 11 Michal Sekletar 2016-10-24 07:17:10 UTC
(In reply to ilmostro7 from comment #10)
> The status of this Bug is "CLOSED".  Does the last response not warrant it
> to be re-opened?

We need to file a new bug against kernel.

Note You need to log in before you can comment on or make changes to this bug.