netdev - Confusion about (new?) bridge behavior

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>] [day] [month] [year] [list]

Date:   Fri, 25 May 2018 16:49:21 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     netdev@...r.kernel.org, nikolay@...ulusnetworks.com,
        arkadis@...lanox.com, ivecera@...hat.com, jiri@...lanox.com
Cc:     vivien.didelot@...oirfairelinux.com, andrew@...n.ch
Subject: Confusion about (new?) bridge behavior

Hi,

The DSA b53 driver currently (well, not quite currently, but at some
point) was forcing the CPU port VLAN membership to be tagged. The reason
for that is mostly because if we allow the CPU port to be untagged in
multiple VLANs we can't quite properly separate traffic at the CPU port
level, so we don't do that.

At some point v4.12, or maybe as far back as 4.9, I remember the
following from happening:

- it was not necessary to turn on vlan_filtering on the bridge to get
the DSA layer to program VLAN entries into the switch, I only get those
calls now if vlan_filtering is enabled, this is not a big issue, but I
do wonder if something did change here? Could be a DSA specific issue
here, I can bisect that later

- because the CPU port was configured tagged into VLAN 1, it was
necessary to either change the default bridge master device settings
(default being VID 1 pvid untagged) to pop the VLAN tag, and conversely
push the VLAN tag on egress path and/or create a network device such
that would be responsible for terminating the VLAN tag, e.g: br0.1

But now, this does not seem to be necessary and I just can't explain
why, it might very well be a switch driver configuration issue.

Now what I am seeing is the following:

1) Default configuration with vlan_filtering = 1

# bridge vlan show
port    vlan ids
gphy     1 PVID Egress Untagged

br0      1 PVID Egress Untagged

If I look at the CPU port, I can see that frames from switch to CPU have
VLAN tag 1, which is expected, yet frames that are from CPU to switch do
not have such a VLAN tag 1, and yet things work okay, dhcp + ping using
br0 work just fine. I suppose that is because of the pvid behavior which
assigns untagged frames to the default VLAN which happens to be 1 in
that case.

2) Changing the bridge to be in VLAN 1 no pvid, no untagged, still with
vlan_filtering = 1

# bridge vlan add vid 1 dev br0 self
# bridge vlan show
port    vlan ids
gphy     1 PVID Egress Untagged

br0      1

The frames from switch to CPU still have VLAN tag 1, now I need to
create a br0.1 device to insert the VLAN tag for dhcp + ping to work
using br0.1 in that case, though I still do not see the VLAN tag being
present for frames that are from CPU to switch...

Was I hallucinating before and things were equally broken, or did
something change recently?

Thank you!
-- 
Florian