On Thu, Jan 08, 2015 at 01:51:36PM +0000, Mauro Santos wrote:

On 08-01-2015 00:00, Mark Lee wrote:

...

Salutations,

I was wondering what's the holdup on Linux 3.18. It's been in testing since 12/11/2014.

I suppose the reason is this: https://bugs.archlinux.org/task/43143?string=43143

Strange, is that an issue specific to Intel atom GPUs? I have not seen any problems on a dual Intel (Ci7 4800) and AMD graphics machine. Anyway, it is easy enough to just download and install the linux package directly, even if [testing] is disabled. BTW, to those updating, one notable (at least from my perspective) change with 3.18.y is the new module br_netfilter responsible for filtering traffic coming through a bridge. This module is not loaded automatically, so no firewall is enabled by default in bridges. Here is a dmesg snippet: --- kernel: [ 23.690774] bridge: automatic filtering via arp/ip/ip6tables has been deprecated. Update your scripts to load br_netfilter if you need this. --- Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

On Thu, Jan 08, 2015 at 07:18:25PM +0000, Mauro Santos wrote:

On 08-01-2015 18:57, Leonid Isaev wrote:

...

BTW, to those updating, one notable (at least from my perspective) change with 3.18.y is the new module br_netfilter responsible for filtering traffic coming through a bridge. This module is not loaded automatically, so no firewall is enabled by default in bridges. Here is a dmesg snippet: --- kernel: [ 23.690774] bridge: automatic filtering via arp/ip/ip6tables has been deprecated. Update your scripts to load br_netfilter if you need this. ---

I'm not sure I'm reading it right and a quick google search doesn't turn up much besides this[1]. Does this apply to filtering via iptables (traffic from/to localhost to/from machines on the bridge) or more specifically to ebtables (filter traffic between machines on the bridge)?

[1] http://ebtables.netfilter.org/documentation/bridge-nf.html

The former. It applies to filtering traffic passing through the bridge. If the module is loaded and /proc/sys/net/bridge/bridge-nf-* == 1 then you should be able to manipulate traffic _inside_ the bridge using iptables FORWARD chain. If the module is not loaded, or the above files contain 0, then the bridge acts as a "dumb" switch. So, you can use the FORWARD chain to forward packets _between_ the bridge and some other interface. The warning is because with linux < 3.18, bridge-netfilter was enabled by default, so you'd need a service that nullifies bridge-nf-*. Now, the module is not loaded by default, so the files are not there, and the existing service will fail. Basically there is no need to do what is suggested in [1] and [2]. (Note, that the sysctl was never the right approach to begin with, no idea who put it in thw wiki). [1] https://wiki.archlinux.org/index.php/QEMU#Creating_bridge_manually [2] https://bugzilla.redhat.com/show_bug.cgi?id=512206 Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D