Bridge in promisc mode strange behavior

Banana Pi Router design BPI-R4(MT7988)
1

I build on a Debian 10 with kernel 5.15 a bridge interface named brlan, that is running properly. Bridge is formed by lan0 to lan3 ports . Wan port is now isolated and down I connected a phisical device with 192.168.1.10 at lan0 , and my network switch at lan0 I set lan0 to lan3 in pomisc mode, and also eth0 and brlan interfaces. I’m able to ping to 192.168.1.10 from 192.168.1.40 without issues. I would like to capture all trafic passing trhough me bridge. With “tcpdump -i brlan”, I able to capture ARP and multicast packets…

root@bpir64:~# tcpdump -i brlan -p
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on brlan, link-type EN10MB (Ethernet), capture size 262144 bytes
20:39:04.541145 ARP, Request who-has 192.168.1.54 tell 192.168.1.10, length 46
20:39:04.542895 IP 192.168.1.170.38368 > 250.red-80-58-61.staticip.rima-tde.net.domain: 4752+ PTR? 54.1.168.192.in-addr.arpa. (43)
20:39:04.545941 IP 250.red-80-58-61.staticip.rima-tde.net.domain > 192.168.1.170.38368: 4752 NXDomain* 0/1/0 (102)
20:39:04.546478 IP 192.168.1.170.42951 > 250.red-80-58-61.staticip.rima-tde.net.domain: 13198+ PTR? 10.1.168.192.in-addr.arpa. (43)
20:39:04.549440 IP 250.red-80-58-61.staticip.rima-tde.net.domain > 192.168.1.170.42951: 13198 NXDomain* 0/1/0 (102)
20:39:04.550029 IP 192.168.1.170.52689 > 250.red-80-58-61.staticip.rima-tde.net.domain: 58299+ PTR? 170.1.168.192.in-addr.arpa. (44)
20:39:04.552860 IP 250.red-80-58-61.staticip.rima-tde.net.domain > 192.168.1.170.52689: 58299 NXDomain 0/1/0 (121)
20:39:04.553325 IP 192.168.1.170.46599 > 250.red-80-58-61.staticip.rima-tde.net.domain: 63912+ PTR? 250.61.58.80.in-addr.arpa. (43)
20:39:05.581075 ARP, Request who-has 192.168.1.54 tell 192.168.1.10, length 46
20:39:06.621438 ARP, Request who-has 192.168.1.54 tell 192.168.1.10, length 46
20:39:06.737673 IP 192.168.1.5 > 233.89.188.1: igmp v2 report 233.89.188.1
....
^C
33 packets captured
34 packets received by filter
1 packet dropped by kernel

I launh “tcpdump -i brlan icmp” to capture ping packets com a continous ping … Surprisingly , only 1 icmp request packet is captured during more than 10 minutes…¿?¿

root@bpir64:~# tcpdump -i brlan -p icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on brlan, link-type EN10MB (Ethernet), capture size 262144 bytes
20:40:08.609624 IP 192.168.1.35 > 192.168.1.10: ICMP echo request, id 2, seq 20825, length 40
^C
1 packet captured
1 packet received by filter
0 packets dropped by kernel

Can someone understand it?

2

If ping is not from/to r2/r64 it is switched without passing eth0 (switch mt753x only),so you cannot capture it. Arp/multicast are broadcast so sent to all devices in lan segment…so also your r2/r64

3

Then, why can i see one capturd packet on second capture?

root@bpir64:~# tcpdump -i brlan -p icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on brlan, link-type EN10MB (Ethernet), capture size 262144 bytes
20:40:08.609624 IP 192.168.1.35 > 192.168.1.10: ICMP echo request, id 2, seq 20825, length 40

20:40:08.609624 IP 192.168.1.35 > 192.168.1.10: ICMP echo request, id 2, seq 20825, length 40

4

Maybe the first reaches r2/r64 because your source device does not know mac from target (normaly this is done via arp broadcast) and send it to default gateway. Maybe switch does not have the mac stored and forward it to soc instead of switching

Without knowing full topology and your source arp cache it is only thinking :slight_smile:

5

It isn’t the first echo request packet… it appears few second after start capturing. And it doesn’t seem to be an ARP request… it’s a ICMPO Request packet. Could it be a DSA driver bug?

6

i guess it is a problem in dsa driver handling software-bridges, but i have no exact idea where to search for (except in drivers/net/dsa/mt7530.c). maybe you can ask MTK (landen chao) or deng qingfang, CC MTK mailinglist

7

If the fdb entries are learned through the DSA driver you could try to ‘break’ the mt7530_fdb_write() routine. Keep the DSA fdb empty. Check if no more self entries are listed by:

bridge fdb

If the entries are learned inside the hardware, you need to find a way to disable that. But I think this is disabled from 5.15 up, because of using CPU assisted learning

8

I will try it as soon as posible, Thanks. I will check if AL is enabled at my kernel.