tcpdump doesn't capture WiFi-to-WiFi traffic

Question

I have configured a transparent bridge on a network that should capture all the traffic of its connected devices with tcpdump (see diagram 1).

The bridge is configured on a Debian 11 server and has an uplink (eth1) to the router which also handles DHCP, etc.. Ethernet/LAN devices are connected via a network-HUB (not shown in the diagram) on eth2. Wi-Fi devices are connected via a USB 3.0 NIC (ALFA AWUS1900) by using hostapd (wlan0). All the interfaces (eth1, eth2, wlan0) are configured as a bridge (br0).

When I try to capture PING-Traffic from different devices with

tcpdump -i br0

I can see the requests and responses from WLAN<->Internet, LAN<->Internet and LAN<->LAN. However when I try to ping from one WLAN device to another WLAN device (for example from 192.168.0.21 to 192.168.0.22) the traffic doesn't get captured by tcpdump even though I get responses for the ping. Furthermore absolutely no traffic gets captured from one WLAN device to another.

Here is the relevant snipped of my /etc/network/interfaces:

# Bridge interface
iface eth1 inet manual
iface eth2 inet manual
iface wlan0 inet manual

auto br0
iface br0 inet static
  bridge_ports eth1 eth2

My /etc/hostapd/hostapd.conf:

# INTERFACE CONFIGURATION
interface=wlan0
driver=nl80211
bridge=br0
ctrl_interface=/var/run/hostapd
ctrl_interface_group=0

# WI-FI CONFIGURATION
ssid=****
hw_mode=g
country_code=AT
channel=1
auth_algs=1
macaddr_acl=0
# WPA
wpa=2
wpa_passphrase=****
wpa_key_mgmt=WPA-PSK
rsn_pairwise=CCMP

What am I missing here that WLAN to WLAN traffic doesn't get captured? Any help would be really appreciated!

Edit: Here is the output of ip -a address

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP group default qlen 1000
    link/ether ac:1f:6b:00:00:00 brd ff:ff:ff:ff:ff:ff
    altname enp25s0f0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP group default qlen 1000
    link/ether 00:c0:ca:00:00:00 brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
    link/ether 00:60:6e:00:00:00 brd ff:ff:ff:ff:ff:ff
5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ca:a0:96:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.3/24 brd 192.168.0.255 scope global br0
       valid_lft forever preferred_lft forever

Answer 1

You need ap_isolate=1 in hostapd's settings to prevent the Wireless driver to perform low-level bridging of the wireless frames coming from Wifi and sent back to same Wifi which short-circuits the network stack and the bridge br0.

But ap_isolate alone results in Wifi client isolation: it can't see anymore other Wifi clients without additional settings.

Wii-to-Wifi goes from:

wlan0 -----> AP -----> wlan0
             X

            br0

to (nowhere, or useless broadcasts the the Ethernet ports: loss of connectivity):

wlan0 ---> (AP) ---> br0 X
     

As a bridge never sends back traffic to the port it came from by default, Wifi-to-Wifi connectivity is disabled (that's why the parameter is called ap_isolate in the first place). This kind of traffic must be enabled back on the bridge for this case: hairpinning

bridge link set dev wlan0 hairpin on

(alternative command for exactly the same result: ip link set dev wlan0 type bridge_slave hairpin on)

Now traffic becomes:

wlan0 ---> (AP) --->
                    br0
wlan0 <--- (AP) <---
          

As switched traffic goes through br0 because of ap_isolate=1, without disruption thanks to hairpinning, tcpdump will now be able to capture Wifi-to-Wifi on br0 (or directly on the wlan0 port).