Bug 1182105

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)

*** Bug 1122700 has been marked as a duplicate of this bug. ***

*** Bug 1213313 has been marked as a duplicate of this bug. ***

lets go for the short-time solution in rhel


https://github.com/lnykryn/systemd-rhel/commit/05f3e4b89d6503a4a327be9bee9802097bc8c860
->post

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.

https://rhn.redhat.com/errata/RHBA-2015-2092.html

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
  load_module()
    mod_sysfs_setup()
      kobject_uevent(&mod->mkobj.kobj, KOBJ_ADD);
    ...
    do_init_module()
      br_init()
        br_netfilter_init()
          register_net_sysctl()

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 
#!/bin/bash
exec >> /tmp/bridgetest.log

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

which gives following output

triggered..
Wed Aug  3 14:39:45 EEST 2016
sleeping...
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

The status of this Bug is "CLOSED".  Does the last response not warrant it to be re-opened?

(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.