Differences

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

doc:howto:clientmode [2012/11/07 04:24]
uvray313 Spelling and grammer
doc:howto:clientmode [2013/12/07 21:49] (current)
timmillerdyck how to identify when mac80211 drivers are in use
Line 1: Line 1:
====== Client Mode Wireless ====== ====== Client Mode Wireless ======
-This article outlines several variants to realize wireless connectivity using //Client// or //Station// mode.+This article outlines several methods of connecting devices wirelessly using [[Client Mode|Client]] or [[Station Mode|Station]] mode.
-First of all, there are various reasons to do such a kind of setup, examples are+There are a variety of different possibilities:
-  * possibility to connect a single device or a whole network segment to an existing wireless access point +  * Connect a single device or [[wp>Network_segment|network segment]] to a [[wp>Wireless_access_point|wireless access point]]. 
-  * implementing a point-to-point link to connect two network segments +  * Create a point-to-point link,  
-  * swapping roles of access point and client due to driver limitations +  * Reverse the roles of access point and client to accomodate driver limitations. 
-  * being able to take down the OpenWrt device without interrupting the rest of the network+  * Allow shutting down a single device without effecting 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//).+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 - Wireless Distribution System =====
-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.+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 be able to use WDS one should use the same hard- and software on all deployed wireless devices to have the best possible compatibility.+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: 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 +  * [[wp>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+  * AP-to-Sta WDS - 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 Layer 2 transparency enabling bridging and broadcasting across wireless connections - all connected network devices form one common broadcast domain.+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|}} {{:doc:recipes:wds.png|}}
Line 32: Line 32:
==== AP-to-Sta WDS (Madwifi, mac80211) === ==== AP-to-Sta WDS (Madwifi, mac80211) ===
-[[doc:recipes:atheroswds|WDS (atheros)]]+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 ===== ===== Routed Client Mode =====
-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).+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. With routed client mode there are two possibilities to implement the network topology, depending on the specific requirements.
Line 43: Line 50:
==== Masqueraded ==== ==== Masqueraded ====
-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. +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}} {{: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 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.+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. See the [[doc:recipes:routedclient#using.masquerade|Routed Client (Using MASQUERADE)]] article for configuration instructions.
-==== Routed Topology ====+==== Routed ====
-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.+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}} {{:doc:howto:802.11-routed-client.png|Routed network topology}}
-Hosts from the client network (red) are able to reach hosts in the AP network (blue) and vice versa. +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.
-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 [[doc:recipes:routedclient#using.routing|Routed Client (Using Routing)]] article for configuration instructions. See the [[doc:recipes:routedclient#using.routing|Routed Client (Using Routing)]] article for configuration instructions.
Line 66: Line 69:
===== Bridged Client Mode (brcm-2.4 only) ===== ===== Bridged Client Mode (brcm-2.4 only) =====
-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 [[doc:howto:clientmode#why.it.works.on.brcm-2.4|technical background section]]).+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}} {{:doc:howto:802.11-wet.png|WET Mode}}
Line 90: Line 93:
{{:doc:howto:802.11-no-bridge-plain.png|Problem with bridging in a plain AP-to-STA setup}} {{:doc:howto:802.11-no-bridge-plain.png|Problem with bridging in a plain AP-to-STA setup}}
-The normal 802.11 standard only uses three MAC addresses for frames transmitted between the Access Point and the Station.+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. 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.
Line 121: Line 124:
==== Why it works on brcm-2.4 ==== ==== Why it works on brcm-2.4 ====
-The propretary //wl.o// Broadcom wireless driver implements an ARP-NAT (Layer 2 address translation) mechanism called //WET mode//.+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. ARP-NAT is comparable to //Masquerading// used on Layer 3 to connect multiple hosts using only one globally routed public IP address.
Line 160: Line 163:
'' | '' |
-===== ClientMode using WEP ===== 
-Using WEP in client mode is simple; two more options need to be set: 
-| ''config 'wifi-iface+===== Client Mode with WPA2 Enterprise PEAP-GTC Authentication ===== 
-        *.. +  -Make sure you have the full wpa_supplicant package that support EAP/PEAP authentication. 
-        option 'encryption'   'wep+  -Use UCI or modify the /etc/config/wireless file to set the following options 
-        option 'key'       ' '   '' |+        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'
-===== ClientMode using WPA/WPA2 ===== +  -Enter //uci commit wireless// on the command line 
-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" [[oldwiki:wireless.nas]] to get this stuff working -- see section below.  Don't blame me, man, I didn't do it.+ -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
-==== wpa_supplicant ==== +  ctrl_interface=/var/run/wpa_supplicant-wlan0 
- +    
-:!: FIXME The sections below are outdated, configuration of wpa_supplicant should be done in [[doc:uci:wireless|/etc/config/wireless]] . +   network={ 
- +        scan_ssid=1 
-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 [[http://hostap.epitest.fi/wpa_supplicant/|other chipets]], it supports the two wireless chipsets supported by OpenWRT, Atheros and the Broadcom wl.o binary. +        ssid="YOUR_SSID_HERE"
- +
-It is available as a precompiled package in Kamikaze 7.09, and is in the "Network" category of buildroot's <code>make menuconfig</code> +
-+
- +
-Note: wpa_supplicant.conf should have permissions of 600 and ownership of root:root. +
- +
-=== Example /etc/wpa_supplicant.conf === +
- +
-| ''ctrl_interface=/var/run/wpa_supplicant +
-ctrl_interface_group=0 +
-# Obviously, different networks will require different options.  The wpa_supplicant documentation covers them +
-# This is what most Radius authentication (corporate, school, etc) networks look like +
-network={ +
-        ssid="RadiusAuthNetwork"+
        key_mgmt=WPA-EAP         key_mgmt=WPA-EAP
-        pairwise=CCMP TKIP +        proto=WPA2 
-        group=CCMP TKIP +        eap=PEAP 
-        eap=PEAP TLS +        phase2="auth=gtc
-        identity="" +        identity="YOUR_ID_HERE
-        password="" +        password=""  <----delete this line and save the file 
-        phase2="auth=MSCHAPV2+   }
-        priority=10 +
-+
-# wpa_supplicant supports multiple networks, hence the "priority" option +
-# it also supports open APs +
-network={ +
-        ssid="OpenAP" +
-        key_mgmt=NONE +
-        priority=5 +
-+
-# WPA-PSK/TKIP +
-network={ +
-        ssid="example wpa-psk network" +
-        key_mgmt=WPA-PSK +
-        proto=WPA +
-        pairwise=TKIP +
-        group=TKIP +
-        psk="secret passphrase" +
-}'' | +
- +
-More examples can be found at http://hostap.epitest.fi/wpa_supplicant/ down at the bottom +
- +
-=== Running WPA Supplicant === +
- +
-WPA supplicant is run like this (for an Atheros device): <code>wpa_supplicant -d -c /etc/wpa_supplicant.conf -i ath0 -D wext</code> +
- +
- +
-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 +
- +
-==== Using Broadcom's nas (Network Authentication Service) as a WPA supplicant ==== +
-Broadcom has a proprietary network authentication service binary, called "nas. +
- +
-On Kamikaze, you can use: +
- +
-<code> +
-nas -P /tmp/nas.lan.pid -l br0 -H 34954 -i wl0 -A -m 4 -k MYKEY -s MYSSID -w 4 -g 3600 +
-</code> +
- +
-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 [[doc:uci|the Unified Configuration Interface documentation]] for more on parsing OpenWrt config files.) +
- +
-/etc/init.d/nas +
-| ''#!/bin/sh /etc/rc.common +
-START=55 +
- +
-start() { +
-        # Remember, friends don't let friends use awk to extract config values.  Use +
-        # uci instead! A public service announcement from jf@feldman.org +
-        #                                           +
-        MYKEY=$(uci get wireless.@wifi-iface[0].key)   +
-        MYSSID=$(uci get wireless.@wifi-iface[0].ssid)                                   +
-        nas -P /tmp/nas.lan.pid -l br0 -H 34954 -i wl0 -A -m 4 -k $MYKEY -s $MYSSID -w 4 +
-}        +
- +
-stop() {           +
-        killall nas +
-}'' | +
- +
-<code>ln -s /etc/init.d/nas /etc/rc.d/S55nas +
-chmod 755 /etc/rc.d/S55nas +
-sync</code> +
- +
-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): +
- +
-=== nas command === +
- +
-<code>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    ?????? +
-</code> +
- +
-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+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.

Back to top

doc/howto/clientmode.1352258667.txt.bz2 · Last modified: 2012/11/07 04:24 by uvray313