Thu Feb 08, 2024 12:31 am
Problem with your "dumb switch" , is that for this to work the switch must do some smart special things, if the data over wifi is for multiple cabled devices.
Not as in a normal cabled "dumb switch" where the data-packets keep their original source/destination MAC addresses, as these are also the transmitter/receiver MAC addresses. A wifi link (802.11) has other transmitter/receiver than the source/destination. Not a problem normally, but the 802.11 standard only defines 3 MAC addresses in a packet. Source, transmitter and only one MAC address for the receiver (supposed to be the destination).
There are solutions for this, but they are vendor and software specific. The 4 address-mode is active between MT wifi , if both run the WLAN driver, or both use the wifiwave2-driver, and the 4-address mode is triggered (set as AP-bridge and station-bridge with WLAN, the wifiwave2 AP will react on the station-bridge of the wifiwave2 (only)). All other cases is 3-address mode. ( WDS is another wifi 4-address mode)
There are 3 solutions for this 3-address mode ...
1. Use the router function on the wifi-station (normally with NAT). The AP will send all data to the station IP/MAC address That station will forward/reverse NAT/route the answer to the proper device. Behind NAT, the devices must take the initiative for the communication, to make the proper entries in the FW connection table. Or a set of DST-NAT addresses/ports must be configured. (manual table).
2. One can create a L2 tunnel between the wifi AP and station. The outer skin of the tunnel carries the IP/MAC addresses of AP and wifi station only. Inside the tunnel, it is like an ethernet cable.
3. The third possibility is to make that "dumb switch" smarter, and let it do the dispatching, based on IP addresses (not on MAC addresses). Intelligence is gathered when the clients on the cable transmit packets via the wifi-station. That is the "station-pseudobridge" use case. For a single wired device "station-pseudobridge-clone MAC" is expected to work a bit better. (receiver MAC = destination MAC)
The 3th solution is problematic. As network-software developpers do not expect to see different devices' IP addresses with all the same MAC. DHCP is such a software dilemma. MAC addresses in the packet-headers should not be used , but the MAC addresses in the payload are for DHCP. In all the other cases, DHCP header and payload MAC are identical, not in this "L2.5" pseudo-bridge case. Where the DHCP server has to send the DHCP offer as answer? To payload or header MAC? Header MAC is wrong, but payload MAC will never reach its destination, unless flooding is used.
Some solutions work with "proxy arp". Results do vary, and DHCP is among the first network functions to fail. Results are timing dependent (cached info gets flushed), difficult to diagnose. Using wifi-repeaters bring similar problems. (Everyone behind the repeater uses the same Hotspot MAC-cookie, FW gets confused, etc ...)
Last edited by
bpwl on Fri Feb 09, 2024 4:21 pm, edited 4 times in total.