netdev - packets trickling out of STP-blocked ports

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

Message-ID: <20211230230740.GA1510894@euler>
Date:   Thu, 30 Dec 2021 15:07:40 -0800
From:   Colin Foster <colin.foster@...advantage.com>
To:     netdev@...r.kernel.org
Cc:     Vladimir Oltean <olteanv@...il.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Horatiu Vultur <horatiu.vultur@...rochip.com>
Subject: packets trickling out of STP-blocked ports

Hi all,

I'm not sure who all to include in this email, but I'm starting with
this list to start.

Probably obvious to those in this email list, I'm testing a VSC7512 dev
board controlled via SPI. The patches are still out-of-tree, but I
figured I'll report these findings, since they seem real.

My setup is port 0 of the 7512 is tied to a Beaglebone Black. Port 1 is
tied to my development PC. Ports 2 and 3 are tied together to test STP.

I run the commands:

ip link set eth0 up
ip link set swp[1-3] up
ip link add name br0 type bridge stp_state 1
ip link set dev swp[1-3] master br0
ip addr add 10.100.3.1/16 dev br0
ip link set dev br0 up

After running this, the STP blocks swp3, and swp1/2 are forwarding.

Periodically I see messages saying that swp2 is receiving packets with
own address as source address.

I can confirm that via ethtool that TX packets are increasing on swp3. I
believe I captured the event via tshark. A 4 minute capture showed three
non-STP packets on swp2. All three of these packets are ICMPv6 Router
Solicitation packets. 

I would expect no packets at all to egress swp3. Is this an issue that
is unique to me and my in-development configuration? Or is this an issue
with all Ocelot / Felix devices?

If this is an Ocelot thing, I can try to come up with a different test 
setup to capture more data... printing the packet when it is received,
capturing the traffic externally, capturing eth0 traffic to see if it is
coming from the kernel or being hardware-forwarded...

(side note - if there's a place where a parser for Ocelot NPI traffic is
hidden, that might eventually save me a lot of debugging in Lua)

An idea of how frequently this happens - my system has been currently up
for 3700 seconds. Eight "own address as source address" events have
happened at 66, 96, 156, 279, 509, 996, 1897, and 3699 seconds. 

Thanks, 

Colin Foster