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:   Thu, 14 Jul 2022 10:46:02 +0000
From:   <Arun.Ramadoss@...rochip.com>
To:     <martin.blumenstingl@...glemail.com>, <vladimir.oltean@....com>
CC:     <claudiu.manoil@....com>, <alexandre.belloni@...tlin.com>,
        <UNGLinuxDriver@...rochip.com>, <andrew@...n.ch>,
        <vivien.didelot@...il.com>, <petrm@...dia.com>,
        <idosch@...dia.com>, <linux@...pel-privat.de>,
        <f.fainelli@...il.com>, <hauke@...ke-m.de>,
        <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

Hi Vladimir,
We couldn't able to setup the selftests and failed during installation
of packages. In the mean time, We tried the following things

Setup - Host1 --> lan1 --> lan2 --> Host2. Packet transmitted from
Host1 and received by Host2.

Scenario-1: Vlan aware system and both lan1 & lan2 are in same vid
ip link set dev br0 type bridge vlan_filtering 1
bridge vlan add dev lan2 vid 10 pvid untagged
bridge vlan add dev lan1 vid 10 pvid untagged

Packet transmitted from Host1 with vid 10 is received by the Host2.
Packet transmitted from Host1 with vid 5 is not received by the Host2.

Scenario-2: Vlan unaware system 
ip link set dev br0 type bridge vlan_filtering 0

Now, irrespective of the vid, the packets are received by Host2
Packet transmitted from Host1 with vid 10 is received by the Host2.
Packet transmitted from Host1 with vid 5 is  received by the Host2.

Whether the above approach is correct or do we need to test anything
further.

Thanks
Arun 
On Sat, 2022-07-09 at 00:27 +0200, Martin Blumenstingl wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
> 
> Hi Vladimir,
> 
> On Fri, Jul 8, 2022 at 2:09 PM Vladimir Oltean <
> vladimir.oltean@....com> wrote:
> > 
> > On Fri, Jul 08, 2022 at 12:00:33PM +0200, Martin Blumenstingl
> > wrote:
> > > That made me look at another selftest and indeed: most of the
> > > local_termination.sh tests are passing (albeit after having to
> > > make
> > > some changes to the selftest scripts, I'll provide patches for
> > > these
> > > soon)
> > > 
> > > None (zero) of the tests from bridge_vlan_unaware.sh and only a
> > > single
> > > test from bridge_vlan_aware.sh ("Externally learned FDB entry -
> > > ageing
> > > & roaming") are passing for me on GSWIP.
> > > Also most of the ethtool.sh tests are failing (ping always
> > > reports
> > > "Destination Host Unreachable").
> > 
> > I don't recall having run ethtool.sh, so I don't know what's the
> > status
> > there.
> 
> OK, no worries there
> 
> > > I guess most (or at least more) of these are supposed to pass? Do
> > > you
> > > want me to open another thread for this or is it fine to reply
> > > here?
> > 
> > So yes, the intention is for the selftests to pass, but I wouldn't
> > be
> > surprised if they don't. They didn't when I started this effort for
> > the
> > ocelot/felix DSA driver either, it's most likely that individual
> > drivers
> > will need changes, that's kind of the whole point of having
> > selftests,
> > to have implementations that are uniform in terms of behavior.
> > For the ocelot driver, the tests symlinked in the DSA folder do
> > pass
> > (with the exception of the locked port test, which isn't
> > implemented,
> > and the bridge local_termination.sh tests, but that's a bridge
> > problem
> > and not a driver problem). I should have a remote setup and I
> > should be
> > able to repeat some tests if necessary.
> > 
> > I think it would be a good idea to create a new email thread with
> > the
> > relevant DSA maintainers for selftest status on GSWIP. You'll need
> > to
> > gather some information on what exactly fails when things fail.
> > The way I prefer to do this is to run the test itself with "bash -x
> > ./bridge_vlan_unaware.sh swp0 swp1 swp2 swp3", analyze a bit where
> > things get stuck, then edit the script, put a "bash" command after
> > the
> > failing portion, and run the selftest again; this gives me a
> > subshell
> > with all the VRFs configured from which I have more control and can
> > re-run the commands that just failed (I copy them from right above,
> > they're visible when run with bash -x). Then I try to manually
> > check
> > counters, tcpdump, things like that.
> 
> I already found "bash -x" and used a similar trick (launching tcpdump
> before the failing portion). But it's good to have it written down!
> Thanks a lot again for all your detailed explanations and the time
> you've taken to help me out!
> I'll start a new thread on this in the next few days.
> 
> 
> Best regards,
> Martin