netdev - Re: 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-prev] [day] [month] [year] [list]
Date:   Sat, 1 Jan 2022 18:04:29 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Colin Foster <colin.foster@...advantage.com>
Cc:     netdev@...r.kernel.org,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Horatiu Vultur <horatiu.vultur@...rochip.com>
Subject: Re: packets trickling out of STP-blocked ports

On Fri, Dec 31, 2021 at 02:28:23AM +0200, Vladimir Oltean wrote:
> Traditionally, DSA has made a design decision that all switch ports
> inherit the single MAC address of the DSA master. IOW, if you have 1 DSA
> master and 4 switch ports, you have 5 interfaces in the system with the
> same MAC address. It was like this for a long time, and relatively
> recently, Xiaofei Shen added the ability for individual DSA interfaces
> to have their own MAC address stored in the device tree.

I thought a bit more in the back of my head and I need to make a
correction to what I said. It doesn't matter that DSA interfaces have
the same MAC address, because swp2 and swp3 are both bridge ports, and
therefore, their MAC addresses are both local FDB entries, even if
unique. So the bridge would still complain that it receives packets with
a MAC SA equal to a local FDB entry.

ip link add veth0 type veth peer name veth1
ip link add br0 type bridge
ip link set veth0 master br0
[   84.987666] br0: port 1(veth0) entered blocking state
[   84.992857] br0: port 1(veth0) entered disabled state
[   84.998172] device veth0 entered promiscuous mode
ip link set veth1 master br0
[   87.083140] br0: port 2(veth1) entered blocking state
[   87.088280] br0: port 2(veth1) entered disabled state
[   87.093625] device veth1 entered promiscuous mode
ip link set br0 type bridge stp_state 1
ip link set br0 up
ip link set veth0 up
ip link set veth1 up
[  116.758260] IPv6: ADDRCONF(NETDEV_CHANGE): veth1: link becomes ready
[  116.764899] br0: port 2(veth1) entered blocking state
[  116.771353] br0: port 2(veth1) entered listening state
[  116.778272] IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
[  116.785703] br0: port 1(veth0) entered blocking state
[  116.790776] br0: port 1(veth0) entered listening state
[  117.112892] br0: port 2(veth1) entered blocking state
[  132.312686] br0: port 1(veth0) entered learning state
[  133.740183] br0: received packet on veth0 with own address as source address (addr:c2:fc:33:30:4c:bf, vlan:0)
[  145.752889] br0: received packet on veth0 with own address as source address (addr:c2:fc:33:30:4c:bf, vlan:0)
[  147.672675] br0: port 1(veth0) entered forwarding state
[  147.677978] br0: topology change detected, propagating
[  147.683388] IPv6: ADDRCONF(NETDEV_CHANGE): br0: link becomes ready
[  149.741219] br0: received packet on veth0 with own address as source address (addr:c2:fc:33:30:4c:bf, vlan:0)
[  176.472805] br0: received packet on veth0 with own address as source address (addr:c2:fc:33:30:4c:bf, vlan:0)
[  181.742095] br0: received packet on veth0 with own address as source address (addr:c2:fc:33:30:4c:bf, vlan:0)
[  238.552814] br0: received packet on veth0 with own address as source address (addr:c2:fc:33:30:4c:bf, vlan:0)
[  245.742659] br0: received packet on veth0 with own address as source address (addr:c2:fc:33:30:4c:bf, vlan:0)
bridge link
6: veth1@...h0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state blocking priority 32 cost 2
7: veth0@...h1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 2

Looking at br_fdb_update(), the print is pretty harmless - the bridge is
smart enough to not actually relearn the local FDB entry towards an
external port. No FDB update is being done. The print is also
rate-limited. So it's just that - a warning. I am not sure whether it's
worth disabling IPv6 Router Solicitations, given that, as mentioned,
basically any other traffic sent through the plain bridge port will
trigger this. I consider it a non-problem.

ip addr add 192.168.100.1/24 dev veth1
ping 192.168.100.2
PING 192.168.100.[ 1434.033119] br0: received packet on veth0 with own address as source address (addr:c2:fc:33:30:4c:bf, vlan:0)
2 (192.168.100.2) 56(84) bytes of data.
[ 1435.112977] br0: received packet on veth0 with own address as source address (addr:c2:fc:33:30:4c:bf, vlan:0)
[ 1436.152991] br0: received packet on veth0 with own address as source address (addr:c2:fc:33:30:4c:bf, vlan:0)
[ 1437.193428] br0: received packet on veth0 with own address as source address (addr:c2:fc:33:30:4c:bf, vlan:0)
>From 192.168.100.1 icmp_seq=1 Destination Host Unreachable
>From 192.168.100.1 icmp_seq=2 Destination Host Unreachable
>From 192.168.100.1 icmp_seq=3 Destination Host Unreachable
[ 1438.232784] br0: received packet on veth0 with own address as source address (addr:c2:fc:33:30:4c:bf, vlan:0)
[ 1438.260075] br0: received packet on veth0 with own address as source address (addr:c2:fc:33:30:4c:bf, vlan:0)
[ 1439.272769] br0: received packet on veth0 with own address as source address (addr:c2:fc:33:30:4c:bf, vlan:0)
[ 1440.312904] br0: received packet on veth0 with own address as source address (addr:c2:fc:33:30:4c:bf, vlan:0)
>From 192.168.100.1 icmp_seq=4 Destination Host Unreachable
^C
--- 192.168.100.2 ping statistics ---
7 packets transmitted, 0 received, +4 errors, 100% packet loss, time 6280ms
pipe 4