netdev - Re: [RFC PATCH net-next 3/3] net: dsa: never skip VLAN configuration

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, 12 Sep 2022 15:30:18 +0000
From:   <Arun.Ramadoss@...rochip.com>
To:     <vladimir.oltean@....com>
CC:     <claudiu.manoil@....com>, <UNGLinuxDriver@...rochip.com>,
        <alexandre.belloni@...tlin.com>, <vivien.didelot@...il.com>,
        <andrew@...n.ch>, <idosch@...dia.com>, <linux@...pel-privat.de>,
        <petrm@...dia.com>, <f.fainelli@...il.com>, <hauke@...ke-m.de>,
        <martin.blumenstingl@...glemail.com>, <xiaoliang.yang_1@....com>,
        <kuba@...nel.org>, <pabeni@...hat.com>, <edumazet@...gle.com>,
        <netdev@...r.kernel.org>, <Woojung.Huh@...rochip.com>,
        <davem@...emloft.net>
Subject: Re: [RFC PATCH net-next 3/3] net: dsa: never skip VLAN configuration

On Tue, 2022-07-26 at 17:21 +0000, Vladimir Oltean wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
Hi Vladimir,
I am trying to bringup the kselftest for bridge_vlan_aware.sh, in that
I am facing problem during the ping test and all the tests are failing.

#ip vrf exec vlan1 ping 192.0.2.2
Cannot open network namespace: No such file or directory
Failed to get name of network namespace: No such file or directory

Is there any configurations need to be enabled in the linux kernel, can
you suggest/help me out in resolving it.

--
Arun


> 
> Hi Arun,
> 
> On Tue, Jul 26, 2022 at 03:10:24PM +0000, Arun.Ramadoss@...rochip.com
>  wrote:
> > I tried to update the ksz code and tested after applying this patch
> > series. Following are the observation,
> > 
> 
> (...)
> > In summary, only for pvid 1 below patch is working. Initially I
> > tried
> > with pvid 0, 21, 4095, it were not working, only for pvid 1 it is
> > working. Kindly suggest whether any changes to be done in patch or
> > testing methodology.
> 
> What are you saying exactly that you tried with pvid 0, 21, 4095?
> Do you mean
> (a) you changed the vlan_default_pvid of the bridge to these values,
> or
> (b) you edited "u16 pvid = 1" in ksz_commit_pvid() to "u16 pvid = 0"
> (or 21, 4095 etc)?
> 
> Either way, the fundamental reason why neither was going to work is
> the
> same, although the explanation is going to be slightly different.
> 
> What vlan_default_pvid means is what the bridge layer uses as a pvid
> value for VLAN-aware ports. The value of 0 is special and it means
> "don't add a PVID at all". It's the same as if you compiled your
> kernel
> with CONFIG_BRIDGE_VLAN_FILTERING=n.
> 
> The problem is that you're not making a difference between the bridge
> PVID and the hardware PVID.
> 
> See, things don't work due to the line highlighted below:
> 
> static int ksz_commit_pvid(struct dsa_switch *ds, int port)
> {
>         struct dsa_port *dp = dsa_to_port(ds, port);
>         struct net_device *br = dsa_port_bridge_dev_get(dp);
>         struct ksz_device *dev = ds->priv;
>         bool drop_untagged = false;
>         struct ksz_port *p;
>         u16 pvid = 1;       /* bridge vlan unaware pvid */   <---
> this line
> 
>         p = &dev->ports[port];
> 
>         if (br && br_vlan_enabled(br)) {
>                 pvid = p->bridge_pvid.vid;
>                 drop_untagged = !p->bridge_pvid.valid;
>         }
> 
>         ksz_set_pvid(dev, port, pvid);
> 
>         if (dev->dev_ops->drop_untagged)
>                 dev->dev_ops->drop_untagged(dev, port,
> drop_untagged);
> 
>         return 0;
> }
> 
>