Page 39 / 141
DTUS065 rev A.7 – June 27, 2014
When using a client station to bridge a wired network to an AP, the situation
is different. What appears to the AP as a single device with a single MAC
address (that of the radio card), is hiding several wired devices, each of them
having its own MAC address. Since they do not participate in the association
process to the AP, they did not authenticate, hence the AP will not accept
frames containing their MAC address as a source. If the client changes the
source MAC address to its own, other problems appear, see picture below.
Sample problem bridging several devices with a single wireless client
V.6.2
Solutions
There are four ways to overcome this limitation and allow bridging the
devices behind the client station:
•
Routing. Let the wired LAN on the client side be an IP subnetwork,
and let the client be a router or a NAT. This is a very clean solution
but needs to manage the subnetwork. Strictly spoken, this is routing
(layer 3 networking), not bridging (layer 2 networking).
•
Masquerading. Let the client change the wired devices MAC address
to its own and back, an approach also known as “Level 2.5 NAT” or
“ARPNAT”. This is the default operation in the WLn products
“
client (infrastructure)
”mode. It is described in more details in
section “
Masquerading (ARPNAT)
” below.
•
Cloning. Let the client use the MAC address of the wired device.
This is limited to one wired device though (Supported since firmware
version 2.4.0).
•
Using the “
client (infrastructure)
” and “
4 addresses format
”
bridging mode, involving a more sophisticated frame format. The
802.11 standard provides a “4-addresses” frame format to solve this
kind of issues but it does not fully specify it; hence this mode is not
always compatible between clients and APs from different vendors.
The WLn products, as several Linux-based clients and APs, support
this mode described in section
V.6.2.2
below.
Note that the mesh mode (not an infrastructure mode) also allows bridging.
