This Network Engineering SE link Four layer-2 addresses in 802.11 frame header explains quite well the difference between Ethernet and Wifi.
Wifi requires additional MAC addresses for communication: in addition to the Sender Address (SA) and Destination Address (DA) which are the same as Ethernet's source and destination MACs, Wifi needs Transmitter Address (TA) and Receiver Address (RA) to work: this makes a total of 4 MACs addresses. Since the common case is that when the client (STA) sends, TA = SA and when the Access Point (AP) sends to the STA, DA = RA, usually only 3 addresses are needed, and that's how AP are configured: to use only 3 addresses out of the 4 possible.
A client in bridge mode means that above TA != SA or DA != RA and all 4 addresses are needed, while the AP is configured for 3 only. That's why in common configurations it's not possible to bridge Wifi. 4 addresses mode must be enabled on both the AP and the STA for client bridging to work. This is usually called Wireless distribution system (WDS), but there are probably multiple incompatible implementations. AP and all STA must use a compatible implementation.
So:
if the system bridging is the AP, then you can bridge wifi without issue: that's what are doing all APs, using the default 3 addresses mode.
if the system trying to bridge is a simple client (STA), it won't work. Recent drivers will even prevent setting the wireless interface as bridge port with this kind of error:
# ip link set wlan0 master bridge0
Error: Device does not allow enslaving to a bridge.
if you can configure both the AP and the STA into a compatible WDS, for example if all are running Linux with drivers compatible with mac80211, this can be enabled on the STA with:
# iw dev wlan0 set 4addr on
Then it can be enslaved:
# ip link set wlan0 master bridge0
# ip link show wlan0
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue master bridge0 state DOWN mode DEFAULT group default qlen 1000
[...]
Some documentation about 4 addresses mode with the iw command can be found on the linux wireless wiki: Using 4-address for AP and client mode
Configuring the AP is out of scope here. When using hostapd, there's a specific setting to enable:
# WDS (4-address frame) mode with per-station virtual interfaces
# (only supported with driver=nl80211)
# This mode allows associated stations to use 4-address frames to allow layer 2
# bridging to be used.
#wds_sta=1
There's still a workaround allowing to use multiple containers or VMs simultaneously with separate IPs over a single Wifi default mode (3-addresses mode) connection, but using only one MAC address (the one used as STA): it's thus usually not compatible with DHCP which by default relies on the MAC address (unless the DHCP server is accepting the dhcp-client-identifier option). It's called IPVLAN (usually for containers) and its TAP counterpart (usually for VMs) is called IPVTAP. When used in L2 mode it gives what looks like a standard ethernet interface.
For a (simple ip netns network) container this could be used like this after having already established a Wifi connection in the IP LAN 192.0.2.0/24 with gateway 192.0.2.1, on the host using interface wlan0:
# ip netns add testwifi
# ip link add link wlan0 name ipvl0 type ipvlan mode l2
# ip link set dev ipvl0 netns testwifi up
# ip -n testwifi address add 192.0.2.99/24 dev ipvl0
# ip -n testwifi route add default via 192.0.2.1
# ip netns exec testwifi ping -q -c1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 5.372/5.372/5.372/0.000 ms
I seriously doubt that NetworkManager has any option related to 4 addresses mode. As for IPVLAN/IPVTAP this has to be supported by the container/virtualization application, like LXC or libvirt (which doesn't appears to support IPVTAP natively), not really by NetworkManager.
