This article outlines several variants to realize wireless connectivity using Client or Station mode.

First of all, there are various reasons to do such a kind of setup, examples are

• possibility to connect a single device or a whole network segment to an existing wireless access point
• implementing a point-to-point link to connect two network segments
• swapping roles of access point and client due to driver limitations
• being able to take down the OpenWrt device without interrupting the rest of the network

OpenWrt supports various client mode setups, including WDS (Wireless Distribution System), routed client mode or bridged client mode (only on brcm-2.4).

The WDS mode is a non-standard extension to the wireless 802.11 standard using a 4-address-format to allow transparent ethernet bridging on the station and to implement seamingless hand-over for wireless clients roaming between different access points.

Due to its non-standard nature, WDS is often differently implemented in wireless drivers and vendor firmwares making them incompatible to each other. In order to be able to use WDS one should use the same hard- and software on all deployed wireless devices to have the best possible compatibility.

In OpenWrt there are two flavours of WDS available, depending on the wireless chipset and driver in use:

• Broadcom WDS - available on Broadcom wireless chipsets using the proprietary wl.o driver
• AP-to-Sta WDS - available for both Madwifi and mac80211 supported wireless devices

The biggest advantage of WDS is the Layer 2 transparency enabling bridging and broadcasting accross the wireless connections - all involved network segments form one common broadcast domain.

The setup of Broadcom WDS is explained in the recipe article WDS (Broadcom).

WDS (atheros)

The routed client mode is the most generic possibility to implement client mode connectivity, it is supported on all wireless chipsets and drivers and requires no special modifications. The downside of routed client mode is the inability to bridge network segments or relay broadcast traffic, this affects for example the Windows Network Neighbourhood where hosts from two network segments cannot "see" each other as long as no domain controller is involved (connection by IP address or host name is still possible in any case).

With routed client mode there are two possibilities to implement the network topology, depending on the specific requirements.

Using masquerating (NAT) on the client router allows connecting a whole network segment behind the client to an existing wireless network without further modifications on the access point. The downside is that hosts on the AP side are not able to reach hosts behind the client router, this is comparable to the situation where hosts in the internet cannot directly connect to hosts in the LAN.

Hosts from the client network (red) are able to reach hosts in the AP network (blue), the client router masquerades outgoing traffic. Hosts on the AP side only see the client router, all traffic originating from client hosts uses the 192.168.1.30 as source address. No direct connection from LAN Host 1 or 2 to Client Host 1 or 2 is possible.

See the Routed Client (Using MASQUERADE) article for configuration instructions.

Using this variant requires a static route on the AP pointing to the subnet behind the client router using the client routers IP on the AP network as gateway. Advantage is that hosts on both segments are able to reach each other directly, downside is that one requires administrative access to the AP.

Hosts from the client network (red) are able to reach hosts in the AP network (blue) and vice versa. The rectangles represent static route entries.
The client router has two network interfaces, the LAN port and the wireless interface, on the AP LAN and W-LAN are bridged (OpenWrt default).

See the Routed Client (Using Routing) article for configuration instructions.

The bridged client mode is a proprietary Broadcom extension called WET mode. It is mostly Layer 2 transparent but has some disadvantages that may hinder network connectivity under certain circumstances (see technical background section).

All hosts are within the same subnet, W-LAN and LAN are bridged on both the AP and the client router. For a configuration example of bridged client mode, read the Bridged Client (Broadcom) article.

It is possible to achieve a bridge-like client mode setup with the help of relayd.

The setup is explained in the Routed Client with relayd (Pseudobridge) article.

Transparent client bridging or bridged client mode is not possible with vanilla OpenWrt on all platforms except brcm-2.4 with the proprietary Broadcom driver. It is possible to achieve this goal by using WDS, the background is explained below.

There are 3rd-party patches to implement ARP-NAT for platforms other than brcm-2.4 but those are not part of OpenWrt. The Kamikaze based Gargoyle firmware has support for it but is not officially supported by the OpenWrt developers.

The normal 802.11 standard only uses three MAC addresses for frames transmitted between the Access Point and the Station. Frames transmitted from the Station to the AP don't include the ethernet source MAC of the requesting host and response frames are missing the destination ethernet MAC to address the target host behind the client bridge.

1. Bridged Host sends a packet to the Target host
2. Frame is relayed via the W-LAN Client and the MAC address of the transmitting wireless adapter is used as source MAC, the sending ethernet MAC is discarded
3. W-LAN AP receives the frame and redirects it to the Target
4. Target receives the frame and generates a response
5. Target responds to the received frame using the (wrong) source MAC as destination
6. W-LAN AP relays the frame to the W-LAN Client with the given destination MAC
7. W-LAN Client receives the frame and assumes it is the final destination since it's wireless MAC is used in the frame, the packet is not forwarded
8. Bridged Host never sees a response frame since the W-LAN Client became the destination, no connection is possible

If WDS is used, both the AP and the Station switch to the 4-address-mode which enables transparent bridging on the client side.

1. Bridged Host sends a packet to the Target host
2. Frame is relayed via the W-LAN Client, the sending ethernet MAC is preserved
3. W-LAN AP receives the frame and redirects it to the Target using the second source MAC as sender address
4. Target receives the frame and generates a response
5. Target responds to the received frame using the given source MAC as destination
6. W-LAN AP relays the frame to the W-LAN Client with the right MAC as second destination address
7. W-LAN Client receives the frame and redirects it to the final destination using the second destination MAC as target
8. Bridged Host receives the response frame, connection is established

The propretary wl.o Broadcom wireless driver implements an ARP-NAT (Layer 2 address translation) mechanism called WET mode. ARP-NAT is comparable to Masquerading used on Layer 3 to connect multiple hosts using only one globally routed public IP address.

However, the address translation used by the Broadcom driver is not fully transparent and can cause various hard to debug network issues:

• A host on the AP side may not be able to reach a host on the Station side until the other side made an initial connection attempt
• Layer 3 routing on the Station side using a host behind the AP as gateway is unreliable or does not work at all
• The mapping entries in the ARP-NAT table may time out causing sudden connection loss
• The translation table may run out of space resulting in connection problems for some hosts on the Station side

Cleanup Required! This page or section needs cleanup. You can edit this page to fix wiki markup, redundant content or outdated information.

The information below is outdated and parts of it do not really belong here - wireless encryption is covered in the wireless configuration documentation and should be covered by specific examples in the doc:recipes: namespace (tbd) — Jo-Philipp Wich 2010/01/09 03:53

Merge example sections and unify them, link top wep configuration in /etc/config/wireless.

/etc/config/wireless

Using WEP in client mode is simple; two more options need to be set:

WPA requires a "supplicant" – that is, code that deals with the whole encryption and authentication dealie. While some have had success with the proprietary Broadcom chipset and the wpa_supplicant package (more on that in a moment), others have had to utilize the Broadcom proprietary supplicant, "nas" wireless.nas to get this stuff working – see section below. Don't blame me, man, I didn't do it.

The sections below are outdated, configuration of wpa_supplicant should be done in /etc/config/wireless .

wpa_supplicant is the tool that deals with AP authentication, reconnects, etc. It can even be configured to scan and select APs (useful for hidden APs and APs broadcasting multiple ESSIDs from a single BSSID). Among other chipets, it supports the two wireless chipsets supported by OpenWRT, Atheros and the Broadcom wl.o binary.

It is available as a precompiled package in Kamikaze 7.09, and is in the "Network" category of buildroot's

make menuconfig

Note: wpa_supplicant.conf should have permissions of 600 and ownership of root:root.

More examples can be found at http://hostap.epitest.fi/wpa_supplicant/ down at the bottom

WPA supplicant is run like this (for an Atheros device):

wpa_supplicant -d -c /etc/wpa_supplicant.conf -i ath0 -D wext

Note: having wpa_supplicant interact with madwifi using the Linux wireless extensions (-d wext) is strongly recommended by the madwifi developers, and direct ioctl access (-d madwifi) is discouraged.

-B sends it to the background (use this once you get it working) -d increases debugging level

Broadcom has a proprietary network authentication service binary, called "nas."

On Kamikaze, you can use:

nas -P /tmp/nas.lan.pid -l br0 -H 34954 -i wl0 -A -m 4 -k MYKEY -s MYSSID -w 4 -g 3600

to get a broadcom chipset (such as the one on the Linksys or Asus series of routers) to work.

If you wish, you can even start this up when you reboot based on your config files. Imagine that!

Cut and paste this snippet into your SSH session – it will create a startup script that will parse your FIRST instance of wireless config and run every time you reboot. (See the Unified Configuration Interface documentation for more on parsing OpenWrt config files.)

/etc/init.d/nas

ln -s /etc/init.d/nas /etc/rc.d/S55nas
chmod 755 /etc/rc.d/S55nas
sync

It should be noted that the "-w 4" option above is for AES encryption. Below are the full options for the "nas" command (lifted from the old wiki):

Usage: nas [options]
        -l    LAN interface name
        -i    Wireless interface name
        -k    WPA share-key
        -m    2 - WPA
              4 - PSK
              32 - 802.1X
              64 - WPA2
              66 - WPA WPA2
              128 - PSK2
              132 - PSK PSK2
        -g    WPA GTK rotation interval
        -h    RADIUS server IP address
        -r    RADIUS secret
        -p    RADIUS server authentication UDP port
        -s    SSID
        -w    1 - WEP
              2 - TKIP
              4 - AES
              6 - AES+TKIP
        -P    nas pid file
        -I    WEP key index
        -K    WEP share key
        -H    UDP port on which to listen to requests
        -t    ??????

The -l option must be present first and then followed by -i … options for each wireless interface

On "Supplicant"/"Client" side -l option can't be used.

-S|-A = Authenticator (NAS) or Supplicant

Bridged client mode only works on brcm-2.4 all other platforms need non-standard patches or other workarounds

There are no bridged and routed modes on Kamikaze, per se. Instead, multiple interfaces are bridged with an entry in /etc/config/network like this:

Then in /etc/config/wireless, set the network to the same network specified in the bridge:

Alternatively, but a little less flexibly, you can use this line in /etc/config/network:

For routed mode, the wireless device needs to be used in a normal network configuration in /etc/config/network. Then, iptables rules are used to forward packets between the networks. The default gateway on each network (this is routing; you're connecting two networks together) needs to forward packets destined for the other network to the wifi router, or each host on each network needs to know that the wifi router is the router for packets to the respective network.

Both Broadcom and Atheros chipsets support scanning with the iwlist command. This command will scan all interfaces for networks:

iwlist scanning

• ifconfig
• iwconfig
• wpa_cli

If you're having trouble connecting to either a hidden AP or a virtual AP (usually because wpa_supplicant doesn't list it in a scan), make sure these options are set correctly in the wpa_supplicant config file:

• ap_scan (See the example wpa_supplicant.conf for more details)
  • 1: wpa_supplicant initiates scanning and AP selection
  • 0: driver takes care of scanning, AP selection, and IEEE 802.11 association parameters
  • 2: like 0, but associate with APs using security policy and SSID (but not BSSID).
• scan_ssid
  • 0: do not scan this SSID with specific Probe Request frames (default)
  • 1: scan with SSID-specific Probe Request frames (this can be used to find APs that do not accept broadcast SSID or use multiple SSIDs; this will add latency to scanning, so enable this only when needed)