netdev - Weird bridge behaviour - suddenly dropping vlan packets

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]

Message-ID: <20200527202702.GR1551@shell.armlinux.org.uk>
Date:   Wed, 27 May 2020 21:27:02 +0100
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     netdev@...r.kernel.org, bridge@...ts.linux-foundation.org,
        Roopa Prabhu <roopa@...ulusnetworks.com>,
        Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
Subject: Weird bridge behaviour - suddenly dropping vlan packets

Hi,

I've just had a weird problem on my network - I have a clearfogbase
(ARM) platform which has three network ports, running 5.6.  These
three network ports are bridged together, and the bridge has vlan
filtering enabled.

I need two ports (eno0 and eno1) to forward VLAN V between them, so
I've added that in the interfaces file:

iface brlan inet static
	...
	bridge-ports eno0 eno1 eno2
	bridge-wait 0
	...
        up ip link set $IFACE type bridge vlan_filtering 1
	up bridge vlan add vid V dev eno0
	up bridge vlan add vid V dev eno1

This vlan is used for WiFi.

This worked fine for some time, until recently (possibly this
evening) when someone complained that they couldn't connect to the
wifi.

Debugging using tcpdump revealed that native traffic was passing
through the bridge fine, but the bridge was blocking all VLAN V
traffic - I could see packets (mostly ARPs being broadcast for
IPs on either side of the bridge) arriving on both interfaces, but
not leaving.

Anything beyind the vlan configuration on the bridge should be fine
otherwise I would have expected problems with the untagged LAN
traffic.

The fdb entries seemed to be correct; I tried flushing them with
"ip li set brlan type bridge fdb_flush" - no apparent effect.  It
seemed to learn the MAC addresses on either side and associate them
with the vlan.

I tried adding the vlan to the brlan interface too, which was
successfully added, but no, there were no vlan packets there either
despite plenty of activity on the incoming interfaces for that vlan.

It basically seems that the Linux software bridge decided on its own
accord that it would drop all the vlan packets on the floor with no
explanation what so ever.

I tried turning vlan filtering off - even that didn't help.

Having tried a number of other things (including removing the vids
from each interface and adding them back) I decided that the only way
to get the network working again was to reboot the machine.  Hey
presto, things started working again.

This now means that there's nothing to debug, because the problem
has gone away.  However, I suspect it may return in another 49 or
so days.

It could have been some weird network driver issue, but I don't see
how that could produce valid vlan packets to tcpdump but prevent
the bridge from forwarding them.

It isn't some accidental reconfiguration; the machine has not had
anyone logged in to be able to make any changes for the last month
and it certainly has worked during that period - and there is no
other way to make changes other than being logged in (it has a
minimal debian stable install.)

Has anyone seen this kind of behaviour?

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up