netdev - Re: [PATCH 1/1] bridge: remove BR_GROUPFWD_RESTRICTED for arbitrary forwarding of reserved addresses

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 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <09307ccf-02d6-ce63-7030-fcc560e93f23@cumulusnetworks.com>
Date:   Tue, 2 Oct 2018 17:59:31 +0300
From:   Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
To:     Richard Weinberger <richard@....at>,
        Ido Schimmel <idosch@...sch.org>
Cc:     Stephen Hemminger <stephen@...workplumber.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        bernhard.thaler@...et.at, "David S. Miller" <davem@...emloft.net>,
        bridge@...ts.linux-foundation.org, netdev@...r.kernel.org,
        David Gstir <david@...ma-star.at>, roopa@...ulusnetworks.com
Subject: Re: [PATCH 1/1] bridge: remove BR_GROUPFWD_RESTRICTED for arbitrary
 forwarding of reserved addresses

On 01/10/2018 22:10, Richard Weinberger wrote:
> Am Montag, 1. Oktober 2018, 21:04:33 CEST schrieb Ido Schimmel:
>> On Mon, Oct 01, 2018 at 08:54:08PM +0200, Richard Weinberger wrote:
>>> So the only option is having a bridge and transport STP via tc-mirred
>>> or patching the bridge code (what we do right now).
>>
>> And I vote for the first option. I understand it involves more typing,
> 
> hehe, it is not about typing. The setup is done by a script.
> And we both know that getting a patch upstream is much more work than
> typing a few lines of hacky bash scripts.
> Since I want a decent solution and feedback I'm bringing this up here.
> 
> I could also just go with my in-house patch and don't tell anyone...
> 
>> but I see no reason to push more complexity into the kernel - and break
>> standards - when you can relatively easily accomplish the same thing in
>> other ways.
> 
> If having a bridge plus u32+mirred for STP bypass is the preferred solution,
> I'm fine with it.
> So far we use the kernel patch and didn't test the mirred-bypass a lot.
> My fear was that mirred rules from eth0 to eth1 and back might cause a
> loop or confuse the bridge...
> 
>> Adding Nik and Roopa who now maintain the bridge code and should
>> eventually decide about this.
> 
> Thanks,
> //richard 
> 
> 
> 
> 

Richard please check commit:
commit 5af48b59f35c
Author: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
Date:   Wed Sep 27 16:12:44 2017 +0300

    net: bridge: add per-port group_fwd_mask with less restrictions
    
    We need to be able to transparently forward most link-local frames via
    tunnels (e.g. vxlan, qinq). Currently the bridge's group_fwd_mask has a
    mask which restricts the forwarding of STP and LACP, but we need to be able
    to forward these over tunnels and control that forwarding on a per-port
    basis thus add a new per-port group_fwd_mask option which only disallows
    mac pause frames to be forwarded (they're always dropped anyway).
    The patch does not change the current default situation - all of the others
    are still restricted unless configured for forwarding.
    We have successfully tested this patch with LACP and STP forwarding over
    VxLAN and qinq tunnels.
    
    Signed-off-by: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
    Signed-off-by: David S. Miller <davem@...emloft.net>


Will this work for you ?
It's in the bridge since v4.15.

Thanks,
 Nik