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
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:   Wed, 27 May 2020 21:27:02 +0100
From:   Russell King - ARM Linux admin <>
        Roopa Prabhu <>,
        Nikolay Aleksandrov <>
Subject: Weird bridge behaviour - suddenly dropping vlan packets


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

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

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?


RMK's Patch system:
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up

Powered by blists - more mailing lists