Bridging Ethernet Clients over Wi-Fi: Check the Four-Address Requirement
A Wi-Fi station that can reach the Internet is not automatically a transparent bridge for Ethernet devices behind it. The design must preserve both the wireless-hop addresses and the original Ethernet source and destination. For the Linux AP/station design examined here, that requires compatible four-address operation at both ends, followed by a real multi-client forwarding test.
The reference scope is Linux 6.12 mac80211, hostapd 2.11 with its nl80211 driver, and wpa_supplicant 2.11. It excludes mesh forwarding, Wi-Fi Direct, MLO and vendor-specific “repeater” modes. Firmware-offloaded devices need equivalent vendor evidence. No bridge, AP, interface or security setting was changed for this article.
Write down which addresses must survive
Consider Ethernet clients C1 and C2 behind a gateway whose Wi-Fi station address is S. The upstream AP address is A, and the destination Ethernet server is D. A transparent bridge must deliver frames from C1 and C2 upstream with those distinct source identities. Merely making the gateway’s own IP connection work does not exercise this requirement.
In ordinary station-to-AP three-address data framing, the fields provide the receiving AP, the transmitting/source station and the final destination. There is no separate field for an original Ethernet source behind that transmitting station. In the four-address branch, Linux 6.12 constructs receiver, transmitter, destination and source independently. Both To DS and From DS are set. Linux 6.12 ieee80211_build_hdr()
| Uplink data frame | Address 1 | Address 2 | Address 3 | Address 4 |
|---|---|---|---|---|
| Ordinary station-originated traffic | A: receiver/BSSID | S: transmitter/source | D: destination | Absent |
| Four-address traffic from C1 | A: receiver | S: transmitter | D: destination | C1: original source |
| Four-address traffic from C2 | A: receiver | S: transmitter | D: destination | C2: original source |
These symbolic addresses describe header roles, not captured packets. They explain why changing a bridge configuration alone cannot create missing over-the-air semantics. Address rewriting, proxying or IP routing may provide useful connectivity, but each has a different contract from preserving arbitrary downstream Ethernet identities.
Qualify both endpoints and the authentication path
The Linux wireless guide requires AP and client support for its four-address mode and warns against assuming interoperability with other WDS implementations. A product label saying “WDS” is therefore insufficient. Record the actual mode, driver and AP implementation on each side. The guide also contains historical kernel notes; use the pinned implementation and a target test rather than applying those old notes to every current kernel. Linux wireless four-address guidance
Hostapd 2.11 documents wds_sta for per-station four-address interfaces with nl80211. Its wds_bridge setting can select a bridge distinct from the ordinary AP bridge. Verify the resulting interface membership instead of assuming that enabling the option puts downstream traffic into the intended broadcast domain. hostapd 2.11, hostapd.conf WDS section
The AP_VLAN interface used for this per-station mechanism is not, by its name alone, proof that an IEEE 802.1Q tag is carried on the Ethernet uplink. Treat station isolation, bridge membership and any actual tagged VLAN configuration as separate facts.
Authentication also needs the correct receive path. The Linux guide calls for the supplicant’s bridge-interface option when the station interface is bridged; wpa_supplicant 2.11 exposes that option as -b. Determine how the actual network manager supplies the bridge context rather than launching a competing supplicant. wpa_supplicant 2.11 README and interface configuration
Do not require every frame in a capture to contain four addresses. The pinned mac80211 station transmit branch excludes the configured control-port protocol from its ordinary four-address conversion. Classify authentication/control traffic separately from the forwarded data being tested. Association and key establishment must remain intact throughout the bridge experiment.
Run a two-client preservation test
- Choose bridge or route intentionally. List the actual requirement: upstream visibility of individual MAC addresses, same-link discovery, permitted broadcast protocols or simply IP access to a service. If transparent Layer 2 is unnecessary, a reviewed routing design may avoid the unsupported bridge requirement.
- Capture the baseline topology. Record station and AP modes, bridge ports, forwarding policy and the supported four-address configuration. Keep credentials and unrelated network identifiers out of the shared evidence.
- Test C1 and C2 concurrently. Use distinct dedicated test MAC addresses and numbered payloads. Inspect upstream Ethernet captures and bridge forwarding entries for both original sources. One successful downstream client can hide a single-address translation limitation.
- Verify both directions. Send permitted unicast traffic from each client to D and from D to each client. Confirm destination identity at the receiving Ethernet port. Do not rely only on a gateway-originated ping.
- Exercise required group traffic. Test the specific broadcast or multicast protocols the product needs, including IPv4 or IPv6 neighbor discovery where applicable. Successful unicast alone does not prove these paths or the network’s isolation policy.
- Repeat after reassociation. Restart the authorized test connection and check that per-station interfaces, bridge membership, key establishment and learned forwarding state recover. Verify both clients again rather than accepting the gateway’s own online indicator.
Use the first failing boundary to choose the repair
If association fails after bridging, inspect authentication delivery and manager ownership. If the gateway itself works but C1 and C2 do not, inspect four-address compatibility and AP-side station interface creation. If upstream sees only S as a source, establish whether translation or routing is occurring before calling the result transparent. If both sources survive but replies fail, inspect learning, return forwarding and policy at the observed failure point.
A hypothetical controller installation needs two legacy Ethernet instruments to retain separate MAC identities on the plant LAN. Its AP accepts ordinary station connections but offers no qualified compatible four-address mode. That evidence supports changing the access-network architecture or requirements; cloning one instrument’s address onto the station does not satisfy the two-client contract.
The source paths were inspected, but no packet capture or hardware forwarding test was executed. Acceptance requires the exact AP/client pair, two-client bidirectional identity evidence, required group-traffic results and recovery behavior. Keep the conclusion limited to that verified bridge design rather than promising that any Wi-Fi module can replace an Ethernet cable.
