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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 12 Sep 2020 07:37:42 +0000 From: Nikolay Aleksandrov <nikolay@...dia.com> To: "olteanv@...il.com" <olteanv@...il.com> CC: "stephen@...workplumber.org" <stephen@...workplumber.org>, "andrew@...n.ch" <andrew@...n.ch>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "kuba@...nel.org" <kuba@...nel.org>, "davem@...emloft.net" <davem@...emloft.net>, "f.fainelli@...il.com" <f.fainelli@...il.com>, Roopa Prabhu <roopa@...dia.com> Subject: Re: [PATCH net-next] net: bridge: pop vlan from skb if filtering is disabled but it's a pvid On Sat, 2020-09-12 at 10:23 +0300, Vladimir Oltean wrote: > On Sat, Sep 12, 2020 at 06:56:12AM +0000, Nikolay Aleksandrov wrote: > > Could you point me to a thread where these problems were discussed and why > > they couldn't be resolved within DSA in detail ? > > See my discussion with Florian in this thread: > http://patchwork.ozlabs.org/project/netdev/patch/20200907182910.1285496-5-olteanv@gmail.com/ > There's a bunch of unrelated stuff going on there, hope you'll manage. > Thanks! I'm traveling and will be back on Sun evening, will go through the thread then. > > > - the bridge API only offers a race-free API for determining the pvid of > > > a port, br_vlan_get_pvid(), under RTNL. > > > > > > > The API can be easily extended. > > > > If you can help, cool. > > > > And in fact this might not even be a situation unique to DSA. Any driver > > > that receives untagged frames as pvid-tagged is now able to communicate > > > without needing an 8021q upper for the pvid. > > > > > > > I would prefer we don't add hardware/driver-specific fixes in the bridge, when > > vlan filtering is disabled there should be no vlan manipulation/filtering done > > by the bridge. This could potentially break users who have added 8021q devices > > as bridge ports. At the very least this needs to be hidden behind a new option, > > but I would like to find a way to actually push it back to DSA. But again adding > > hardware/driver-specific options should be avoided. > > > > Can you use tc to pop the vlan on ingress ? I mean the cases above are visible > > to the user, so they might decide to add the ingress vlan rule. > > > > Thanks, > > Nik > > I can, but I think that all in all it's a bit strange for the bridge to > not untag pvid-tagged frames. > > Thanks! > -Vladimir If vlan filtering is disabled the bridge shouldn't do any vlan processing, that's the expected behaviour. If tc is a viable option then I'd explore that further and avoid adding more code.
Powered by blists - more mailing lists