A WLAN client is normally an endpoint in a network. If you want to connect more IP’s to it, you use routing. It’s as simple as that and this will always work. Then people started to use game consoles with ethernet ports, of course located far away from the WLAN Access Point. Just wire it with UTP and you’re good to go. Well, so far the theory. In real life, having UTP across the living room might provoke some comments. So you put up a second WLAN router as client and connect the game console “behind” it with a short ethernet lead. Problem solved? Yes, but this setup requires a routing entry on the WLAN Access Point. After all, the wired network “behind” the WLAN client router must be made known to the outside world. And now we hit a problem (Houston ?). For example, you cannot configure static routes on an Apple Airport router. The second problem is that with routing, you have created two separated broadcast domains. If you want to connect an ethernet only printer this way, PC’s on the WLAN might not find it, since broadcast driven discovery does not “see” the printer on the 2nd network. However, if you want to isolate a chatty windows PC from the WLAN, this is your best option…
The solution?
One solution is using routing with NAT on the WLAN client router. Because of the NAT, no routing entry on the WLAN access point is required. In order to connect to systems “behind” the client access point, you need to configure port forwarding rules. Disadvantages: complex configuration (but doable) and still separated broadcast domains. But for a game console with only outgoing connections a perfect solution.
From a functional point of view, you just want to bridge the ethernet ports on the WLAN client router to the WLAN. No routing means no static routes required, bridging means a single broadcast domain. Problem solved? Unfortunately not.
WLAN’s are protected. Part of this protection involves the MAC address on the WLAN link. On a LAN, a single switch port has no MAC address limitation (in general). The source will communicate with multiple destinations. And when I connect a second switch to this port, multiple sources communicate with multiple destinations. This is not possible on a WLAN. WLAN links are limited to 3 MAC address: one source, the client, and two destinations: the Access Point and the “real” destination MAC address. Note that WDS (Wireless Distribution System) works differently. The OpenWRT Wiki explains the various client modes here.
Wireless Ethernet Transceiver
This might all sound familiar to the problem of using public and private IP addresses. There you have multiple devices that want to communicate to the internet, but you are given only one public IP. Broadcom engineers invented Wireless Ethernet Transceiver (WET) as a solution to the problem. WET is in effect NAT on OSI layer 2 where multiple MACs are hidden behind a single MAC. The WLAN MAC address limitation is now circumvented but as always at a cost. With WET (just as with NAT) you need a table to keep track of things. In case of NAT, you track which port communicates with which IP and you hide multiple (private) IP’s behind a single (public) one. So OSI layer 3 (IP) and layer 4 (TCP/UDP port number) are related here. With WET, a table is used to track which MAC address communicates with which IP, hiding multiple IPs behind a single MAC. So here OSI laver 2 and layer 3 are related. The WLAN link still uses max. 3 MACs, even when multiple IPs are used “behind” the WLAN client router.
Limitations
Then WET will have the same limitation as NAT, being the diode effect? With NAT, the table is build using outgoing traffic. Without the table, incoming traffic cannot be mapped. Indeed, without a WET table, incoming MAC addresses cannot be mapped to IPs. However this limitation is in practice in most scenarios not a problem. For example, a game console will upon startup most likely contact the DHCP server on the WLAN Access Point. This is outgoing traffic and is enough to build the WET table. Note that with Wireless Ethernet Transceiver, the ARP tables on each side of the bridge are different! The famous WRT54G supports this form of wireless client bridging with OpenWRT or DD-WRT.