User Tools

Site Tools


doc:howto:clientmode

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
doc:howto:clientmode [2012/11/29 16:36]
uvray313
doc:howto:clientmode [2015/12/30 19:35] (current)
tmomas [Client Mode Wireless] links fixed
Line 1: Line 1:
 +====== Client Mode Wireless ======
  
 +This article outlines several methods of connecting devices wirelessly using //Client// or //Station// mode.
 +
 +There are a variety of different possibilities:​
 +
 +  * Connect a single device or [[wp>​Network_segment|network segment]] to a [[wp>​Wireless_access_point|wireless access point]].
 +  * Create a point-to-point link, 
 +  * Reverse the roles of access point and client to accomodate driver limitations.
 +  * Allow shutting down a single device without affecting the rest of the network.
 +
 +OpenWrt supports various client modes, including bridging using //​[[wp>​Wireless_distribution_system|WDS (Wireless Distribution System)]]//,​ //routed client mode// or a //bridged client mode// implemented only on (old) //​brcm-2.4//​ hardware).
 +
 +===== WDS - Wireless Distribution System =====
 +
 +WDS mode is a non-standard extension to the wireless [[wp>​802.11]] standard using a //​4-address-format//​ to allow transparent ethernet bridging on the station and to implement seamless //​hand-over//​ for wireless clients roaming between different access points.
 +
 +Due to its non-standard nature, WDS is often implemented differently in wireless drivers and vendor firmwares making them incompatible with each other. In order to use WDS, one should use the same hardware and software on all deployed wireless devices to maintain compatibility.
 +
 +In OpenWrt there are two flavours of WDS available, depending on the wireless chipset and driver in use:
 +
 +  * [[wp>​Broadcom]] WDS - available on Broadcom wireless chipsets using the proprietary //wl.o// driver
 +  * AP-to-Sta WDS ("​4addr mode") - available for both //​[[http://​madwifi-project.org/​|Madwifi]]//​ and //​[[http://​wireless.kernel.org/​en/​developers/​Documentation/​mac80211|mac80211]]//​ supported wireless devices (such as Atheros wireless chipsets)
 +
 +The biggest advantage of WDS is the [[wp>​OSI_layer_2|Layer 2]] transparency enabling [[wp>​Bridging_(networking)|bridging]] and [[wp>​Broadcasting_(networking)|broadcasting]] across wireless connections - all connected network devices form one common [[wp>​Broadcast_domain|broadcast domain]].
 +{{:​doc:​recipes:​wds.png|}}
 +
 +==== Broadcom WDS ====
 +
 +The setup of Broadcom WDS is explained in the recipe article [[doc:​recipes:​broadcomwds|WDS (Broadcom)]].
 +
 +==== AP-to-Sta WDS (Madwifi, mac80211) ===
 +
 +The setup of Madwifi or mac80211 WDS is explained in the recipe article [[doc:​recipes:​atheroswds|WDS (atheros)]].
 +
 +This option is the preferred approach for wireless chipsets that support the Linux mac80211 wireless drivers (e.g. Atheros wireless chipsets). If the file /​etc/​config/​wireless looks like the following, then mac80211 drivers are in use.
 +
 +<​code>​
 +config wifi-device '​radio0'​
 +        option type '​mac80211'​
 +        ...
 +</​code>​
 +
 +===== Routed Client Mode =====
 +
 +The //routed client mode// is the most generic wireless option. It is supported by all 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 [[wp>​Host_(network)|hosts]] from two network segments cannot "​see"​ each other without a [[wp>​Domain_controller|domain controller]]. Connection by IP address or host name is still possible.
 +
 +With routed client mode there are two possibilities to implement the network topology, depending on the specific requirements.
 +
 +==== Masqueraded ====
 +
 +Using //​[[wp>​Network_address_translation|masquerading (NAT)]]// on a client router connects a network segment behind the client to an existing wireless network without further modifications to the access point. The downside is that hosts on the AP side cannot access hosts behind the client router.
 +{{:​doc:​howto:​802.11-routed-masq.png|Masqueraded}}
 +
 +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 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 [[doc:​recipes:​routedclient#​using.masquerade|Routed Client (Using MASQUERADE)]] article for configuration instructions.
 +
 +==== Routed ====
 +
 +This option requires a //​[[wp>​Static_routing|static route]]// on the AP pointing to the [[wp>​Subnetwork|subnet]] behind the client router using the client router'​s IP on the AP network as a gateway. This allows hosts on both segments to reach each other directly, but it requires administrative access to the AP in order to configure the static route.
 +
 +{{:​doc:​howto:​802.11-routed-client.png|Routed network topology}}
 +
 +Hosts from the client network (red) are able to directly communicate with hosts in the AP network (blue) and vice versa. The rectangles represent static route entries. ​
 +See the [[doc:​recipes:​routedclient#​using.routing|Routed Client (Using Routing)]] article for configuration instructions.
 +
 +
 +===== Bridged Client Mode (brcm-2.4 only) =====
 +
 +The //bridged client mode// is a proprietary Broadcom extension called //WET (Wireless Ethernet Transceiver) mode//. It is mostly Layer 2 transparent but has some disadvantages that may hinder network connectivity under certain circumstances (see [[doc:​howto:​clientmode#​why.it.works.on.brcm-2.4|technical background section]]).
 +
 +{{:​doc:​howto:​802.11-wet.png|WET Mode}}
 +
 +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 [[doc:​recipes:​bridgedclient|Bridged Client (Broadcom)]] article.
 +
 +===== Bridged Client Mode (with relayd) =====
 +
 +It is possible to achieve a bridge-like client mode setup with the help of //relayd//.
 +
 +{{:​doc:​howto:​802.11-routed-relay.png|Relayd Topology}}
 +
 +The setup is explained in the [[doc:​recipes:​relayclient|Routed Client with relayd (Pseudobridge)]] article.
 +
 +===== Bridged Client Mode Issues =====
 +
 +//​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 [[http://​www.gargoyle-router.com/​|Gargoyle]] firmware has support for it but is not officially supported by the OpenWrt developers.
 +
 +==== Problem using standard client mode ====
 +{{:​doc:​howto:​802.11-no-bridge-plain.png|Problem with bridging in a plain AP-to-STA setup}}
 +
 +The 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.
 +
 +  - //Bridged Host// sends a packet to the //Target// host
 +  - 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
 +  - //W-LAN AP// receives the frame and redirects it to the //Target//
 +  - //Target// receives the frame and generates a response
 +  - //Target// responds to the received frame using the (wrong) source MAC as destination
 +  - //W-LAN AP// relays the frame to the //W-LAN Client// with the given destination MAC
 +  - //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
 +  - //Bridged Host// never sees a response frame since the //W-LAN Client// became the destination,​ no connection is possible
 +
 +
 +==== Solution using WDS ====
 +
 +{{:​doc:​howto:​802.11-no-bridge-wds.png|Bridging possible by using WDS}}
 +
 +If WDS is used, both the AP and the Station switch to the //​4-address-mode//​ which enables transparent bridging on the client side.
 +
 +  - //Bridged Host// sends a packet to the //Target// host
 +  - Frame is relayed via the //W-LAN Client//, the sending ethernet MAC is preserved
 +  - //W-LAN AP// receives the frame and redirects it to the //Target// using the second source MAC as sender address
 +  - //Target// receives the frame and generates a response
 +  - //Target// responds to the received frame using the given source MAC as destination
 +  - //W-LAN AP// relays the frame to the //W-LAN Client// with the right MAC as second destination address
 +  - //W-LAN Client// receives the frame and redirects it to the final destination using the second destination MAC as target
 +  - //Bridged Host// receives the response frame, connection is established
 +
 +
 +==== Why it works on brcm-2.4 ====
 +
 +The proprietary //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
 +
 +
 +----
 +
 +{{page>​meta:​infobox:​cleanup&​noheader&​nofooter&​noeditbtn}}
 +
 +:!: The information below is outdated and parts of it do not really belong here - wireless encryption is covered in the [[doc:​uci:​wireless|wireless configuration documentation]] and should be covered by specific examples in the ''​doc:​recipes:''​ namespace (tbd)  --- //​[[xm@subsignal.org|Jo-Philipp Wich]] 2010/01/09 03:53//
 +
 +----
 +
 +===== ClientMode without authentication (open) =====
 +
 +:!: FIXME Merge example sections and unify them, link top wep configuration in [[doc:​uci:​wireless|/​etc/​config/​wireless]].
 +
 +/​etc/​config/​wireless
 +
 +| ''#​ This section is chipset specific
 +# Do not copy it for your own use
 +# config '​wifi-device'​
 +        #   ...
 +
 +config '​wifi-iface'​
 +        option '​device' ​      '​ '
 +        #   Set this to the /​etc/​config/​network network that it's linked to
 +        #   ​option network ​     ​
 +        #   '​sta'​ means client mode.
 +        option '​mode' ​        '​sta'​
 +        option '​ssid' ​        '​ '
 +''​ |
 +
 +
 +===== Client Mode with WPA2 Enterprise PEAP-GTC Authentication =====
 +  -Make sure you have the full wpa_supplicant package that support EAP/PEAP authentication.
 +  -Use UCI or modify the /​etc/​config/​wireless file to set the following options
 +        option network '​wwan'​
 +        option device '​radio0'​
 +        #set device and network as necessary
 +        option mode '​sta'​
 +        option ssid '​CHANGE_THIS_TO_YOUR_SSID'​
 +        option encryption '​wpa2+ccmp'​
 +        option eap_type '​peap'​
 +        option auth '​gtc'​
 +        option identity '​CHANGE_THIS_TO_YOUR_ID'​
 +
 +  -Enter //uci commit wireless// on the command line
 +  -Enter //wifi// on the command line
 +When the wireless configuration is committed and wifi is commanded, a wpa_supplicant-wlan0.conf (may be something besides wlan0 if you are using a different interface) file is created in the /var/run (same as /tmp/run) directory containing the necessary variables. This looks like the following
 +
 +   ​ctrl_interface=/​var/​run/​wpa_supplicant-wlan0
 +   
 +   ​network={
 +        scan_ssid=1
 +        ssid="​YOUR_SSID_HERE"​
 +        key_mgmt=WPA-EAP
 +        proto=WPA2
 +        eap=PEAP
 +        phase2="​auth=gtc"​
 +        identity="​YOUR_ID_HERE"​
 +        password="" ​ <​----delete this line and save the file
 +   }
 +
 +There is a bug that prevents PEAP-GTC from working. Because no password was specified in the wireless configuration file, uci translated this to password=""​ in the wpa_supplicant conf file, when the time comes to enter your OTP (one time pin) you will not get the prompt because wpa_supplicant accepts ""​ as a valid null password.
 +  -edit the wpa_supplicant-wlan0.conf file by removing the //​password=""//​ line.
 +  -from the command line enter //wpa_cli -p /​var/​run/​wpa_supplicant-wlan0//​ (change wlan0 to your interface as necessary)
 +This will bring up the wpa command line interface. This is necessary because the command line interface receives the OTP query from the wpa_supplicant.
 +  -First, reload the modified wpa supplicant configuration file by type //​reconfigure//​ in the wpa_cli interactive prompt.
 +  -Then, type //​reassociate//​
 +  -After a few seconds you should receive a prompt to enter your one time pin.
 +  -If you have more than one interface on which the wpa supplicant is running determine the //id// of the desired interface by typing //status// at the wpa_cli prompt. If you have only one interface it has id=0
 +  -At the wpa_cli prompt type //otp 0 your_password_here//​
 +  -If you are lucky and have been a good boy (or girl) you will receive a message saying that you have been authenticated and the interface is connected.
 +  -You may now quit wpa_cli
 +  -Continue with whatever else you were up to.
 +
 +
 +===== Bridged and routed client modes =====
 +
 +:!: FIXME Bridged client mode only works on //​brcm-2.4//​ all other platforms need non-standard patches or other workarounds
 +
 +==== Bridged ====
 +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:
 +
 +| ''​config '​interface'​
 +        option '​type' ​    '​bridge'​
 +        option '​ifname' ​  '​eth0.0'​
 +        *..''​ |
 +
 +Then in ''/​etc/​config/​wireless'',​ set the network to the same network specified in the bridge:
 +
 +| ''​config '​wifi-device ​ '
 +        *..
 +
 +config '​wifi-iface'​
 +        *..
 +        option '​network'''​ |
 +
 +Alternatively,​ but a little less flexibly, you can use this line in ''/​etc/​config/​network'':​
 +
 +| '' ​       # athx for Atheros, or wl0 for Broadcom
 +        option '​ifname' ​   '​eth0.0 ath0'''​ |
 +
 +==== Routed ====
 +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.
 +
 +===== Finding networks =====
 +Both Broadcom and Atheros chipsets support scanning with the iwlist command. ​ This command will scan all interfaces for networks:
 +
 +<​code>​
 +iwlist scanning
 +</​code>​
 +
 +===== Useful Commands =====
 +  * ifconfig
 +  * iwconfig
 +  * wpa_cli
 +
 +===== Tips =====
 +==== wpa_supplicant with hidden APs and virtual APs (VAP) ====
 +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 [[http://​hostap.epitest.fi/​gitweb/​gitweb.cgi?​p=hostap.git;​a=blob_plain;​f=wpa_supplicant/​wpa_supplicant.conf|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)