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]

Date:   Mon, 1 Oct 2018 21:48:21 +0300
From:   Ido Schimmel <idosch@...sch.org>
To:     Richard Weinberger <richard@....at>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Richard Weinberger <richard.weinberger@...il.com>,
        Stephen Hemminger <stephen@...workplumber.org>,
        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>
Subject: Re: [PATCH 1/1] bridge: remove BR_GROUPFWD_RESTRICTED for arbitrary
 forwarding of reserved addresses

On Mon, Oct 01, 2018 at 08:32:12PM +0200, Richard Weinberger wrote:
> Am Montag, 1. Oktober 2018, 20:25:26 CEST schrieb Ido Schimmel:
> > On Mon, Oct 01, 2018 at 08:16:22PM +0200, Richard Weinberger wrote:
> > > Florian,
> > > 
> > > Am Montag, 1. Oktober 2018, 18:24:25 CEST schrieb Florian Fainelli:
> > > > If all you are doing is forwarding anything, one thing I experimented
> > > > with before is the following:
> > > > 
> > > > # tc qdisc add dev eth1 handle ffff: ingress
> > > > # tc qdisc add dev eth3 handle ffff: ingress
> > > > # tc filter add dev eth3 parent ffff: u32 \
> > > > > match u32 0 0 \
> > > > > action mirred egress redirect dev eth1
> > > > # tc filter add dev eth1 parent ffff: u32 \
> > > > > match u32 0 0 \
> > > > > action mirred egress redirect dev eth3
> > > > # ifconfig eth3 promisc
> > > > # ifconfig eth1 promisc
> > > > 
> > > > and this works just fine actually, bypassing the bridge layer entirely.
> > > 
> > > Yeah, mirred is a powerful knife. :-)
> > > 
> > > In my case it is too low level since I utilize the netfilter functionality of
> > > the bridge layer.
> > 
> > You can use mirred only for the specific packets you care about and let
> > the rest continue to the bridge.
> 
> This is my plan b, having a u32 classifier that transports STP directly
> to the other interface.
> But IMHO this all is a bit hacky and a "forward anything" bridge mode
> sounds more natural to me.

But "forwarding STP and PAUSE if the number of slaves is restricted to
2" is a hack. The Linux bridge (like other networking equipment) needs
to conform to standards and to the best of my knowledge what you're
requesting is explicitly forbidden by IEEE standards.

Also, if what you need is "forward anything", then Florian's suggestion
should work for you.