Home
Developer Resources

WiFi Configuration Using WPA and WEP

PDF Documents
Caution: This version of this document is no longer maintained. For the latest documentation, see http://www.qnx.com/developers/docs.

WiFi Configuration Using WPA and WEP

This chapter includes:

802.11 a/b/g Wi-Fi Support

Wi-Fi capability is built into the two hc variants of the stack (io-pkt-v4-hc and io-pkt-v6-hc). The NetBSD stack includes its own separate 802.11 MAC layer that's independent of the driver. Many other implementations pull the 802.11 MAC inside the driver; as a result, every driver needs separate interfaces and configuration utilities. If you write a driver that conforms to the stack's 802.11 layer, you can use the same set of configuration and control utilities for all wireless drivers.

The networking Wi-Fi solution lets you join or host WLAN (Wireless LAN) networks based on IEEE 802.11 specifications. Using io-pkt, you can:

Ad hoc mode lets you create a wireless network quickly by allowing wireless nodes within range (for example, the wireless devices in a room) to communicate directly with each other without the need for a wireless access point. While being easy to construct, it may not be appropriate for a large number of nodes because of performance degradation, limited range, non-central administration, and weak encryption.

Infrastructure mode is the more common network configuration where all wireless hosts (clients) connect to the wireless network via a WAP (Wireless Access Point). The WAP centrally controls access and authentication to the wireless network and provides access to rest of your network. More than one WAP can exist on a wireless network to service large numbers of wireless clients.

The io-pkt manager supports WEP, WPA, WPA2, or no security for authentication and encryption when acting as the WAP or client. WPA/WPA2 is the recommended encryption protocol for use with your wireless network. WEP isn't as secure as WPA/WPA2 and is known to be breakable. It's available for backward compatibility with already deployed wireless networks.

For information on connecting your client, see "Using wpa_supplicant to manage your wireless network connections" later in this chapter.

NetBSD 802.11 layer

The net80211 layer provides functionality required by wireless cards. If you've downloaded the Core Networking source from Foundry27 (http://community.qnx.com/sf/sfmain/do/home), you'll find the net80211 layer under sys/net80211. The code is meant to be shared between FreeBSD and NetBSD, and you should try to keep NetBSD-specific bits in the source file ieee80211_netbsd.c (likewise, there's ieee80211_freebsd.c in FreeBSD).

For more information about the ieee80211 interfaces, see Chapter 9 (Kernel Internals) of the NetBSD manual pages at http://www.netbsd.org/documentation/.

The responsibilities of the net80211 layer are as follows:

The ieee80211 layer positions itself logically between the device driver and the ethernet module, although for transmission it's called indirectly by the device driver instead of control passing straight through it. For input, the ieee80211 layer receives packets from the device driver, strips any information useful only to wireless devices, and in case of data payload proceeds to hand the Ethernet frame up to ether_input.

Device management

The way to describe an ieee80211 device to the ieee80211 layer is by using a struct ieee80211com, declared in <sys/net80211/ieee80211_var.h>. You use it to register a device to the ieee80211 from the device driver by calling ieee80211_ifattach(). Fill in the underlying struct ifnet pointer, function callbacks, and device-capability flags. If a device is detached, the ieee80211 layer can be notified with ieee80211_ifdetach().

Nodes

A node represents another entity in the wireless network. It's usually a base station when operating in BSS mode, but can also represent entities in an ad hoc network. A node is described by a struct ieee80211_node, declared in <sys/net80211/ieee80211_node.h>. This structure includes the node unicast encryption key, current transmit power, the negotiated rate set, and various statistics.

A list of all the nodes seen by a certain device is kept in the struct ieee80211com instance in the field ic_sta and can be manipulated with the helper functions provided in sys/net80211/ieee80211_node.c. The functions include, for example, methods to scan for nodes, iterate through the node list, and functionality for maintaining the network structure.

Crypto support

Crypto support enables the encryption and decryption of the network frames. It provides a framework for multiple encryption methods, such as WEP and null crypto. Crypto keys are mostly managed through the ioctl() interface and inside the ieee80211 layer, and the only time that drivers need to worry about them is in the send routine when they must test for an encapsulation requirement and call ieee80211_crypto_encap() if necessary.

Using Wi-Fi with io-pkt

When you're connecting to a Wireless Network in Neutrino, the first step that you need to do is to start the stack process with the appropriate driver for the installed hardware. For information on the available drivers, see the devnp-* entries in the Utilities Reference. For this example, we'll use the driver for network adapters using the RAL chipset, devnp-ral.so. After a default installation, all driver binaries are installed under the staging directory /cpu/lib/dll.


Note: The io-pkt-v4 stack variant doesn't have the 802.11 layer built in, and therefore you can't use it with Wi-Fi drivers. If you attempt to load a Wi-Fi driver into io-pkt-v4, you'll see a number of unresolved symbol errors, and the driver won't work.

In this example, start the stack using one of these commands:

If the network driver is installed to a location other than /lib/dll, you'll need to specify the full path and filename of the driver on the command line.

Once you've started the stack and appropriate driver, you need to determine what wireless networks are available. If you already have the name (SSID or Service Set Identifier) of the network you want to join, you can skip these steps. You can also use these steps to determine if the network you wish to join is within range and active:

  1. To determine which wireless networks are available to join, you must first set the interface status to up:
    ifconfig ral0 up
      
  2. Check to see which wireless networks have advertised themselves:
    wlanctl ral0
      

    This command lists the available networks and their configurations. You can use this information to determine the network name (SSID), its mode of operation (ad hoc or infrastructure mode), and radio channel, for example.

  3. You can also force a manual scan of the network with this command:
    ifconfig ral0 scan
      

    This will cause the wireless adapter to scan for WAP stations or ad hoc nodes within range of the wireless adapter, and list the available networks, along with their configurations. You can also get scan information from the wpa_supplicant utility (described later in this document).

Once you've started the appropriate driver and located the wireless network, you'll need to choose the network mode to use (ad hoc or infrastructure mode), the authentication method to attach to the wireless network, and the encryption protocol (if any) to use.


Note: We recommend that you implement encryption on your wireless network if you aren't using any physical security solutions.

By default, most network drivers will infrastructure mode (BSS), because most wireless networks are configured to allow network access via a WAP. If you wish to implement an ad hoc network, you can change the network mode by using the ifconfig command:

For information about your driver's media options, see its entry in the Utilities Reference. When you're in ad hoc mode, you advertise your presence to other peers that are within physical range. This means that other 802.11 devices can discover you and connect to your network.

Whether you're a client in infrastructure mode, or you're using ad hoc mode, the steps to implement encryption are the same. You need to make sure that you're using the authentication method and encryption key that have been chosen for the network. If you wish to connect with your peers using an ad hoc wireless network, all peers must be using the same authentication method and encryption key. If you're a client connecting to a WAP, you must use the same authentication method and encryption key as have been configured on the WAP.

Connecting to a wireless network

For the general case of connecting to a Wi-Fi network, we recommend that you use the wpa_supplicant daemon. It handles unsecure, WEP, WPA, and WPA2 networks and provides a mechanism for saving network information in a configuration file that's scanned on startup, thereby removing the need for you to constantly reenter network parameters after rebooting or moving from one network domain to another. The information following covers the more specific cases if you don't want to run the supplicant.

You can connect to a wireless network by using one of the following:

We will also be rolling out a new Wi-Fi configuration GUI as part of Photon that interfaces into wpa_supplicant directly.

Once connected, you need to configure the interface in the standard way:

Using no encryption


Caution: If you're creating a wireless network with no encryption, anyone who's within range of the wireless network (e.g. someone driving by your building) can easily view all network traffic. It's possible to create a network without using encryption, but we don't recommend it unless the network has been secured by some other mechanism.

Many consumer devices (wireless routers to connect your internal LAN to the Internet for example) are shipped with security features such as encryption turned off. We recommend that you enable encryption in these devices rather than turn off encryption when creating a wireless network.


To connect using no encryption or authentication, type:

ifconfig ral0 ssid "network name" -nwkey

The -nwkey option disables WEP encryption and also deletes the temporary WEP key.


Note: The io-pkt manager doesn't support a combination of Shared Key Authentication (SKA) and WEP encryption disabled.

Once you've entered the network name, the 802.11 network should be active. You can verify this with ifconfig. In the case of ad hoc networks, the status will be shown as active only if there's at least one other peer on the (SSID) network:

ifconfig ral0

ral0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500%%
    ssid "network name" %%
    powersave off %%
    bssid 00:11:22:33:44:55 chan 11%%
    address: 11:44:88:44:88:44%%
    media: IEEE802.11 autoselect (OFDM36 mode 11g) %%
    status: active%%

Once the network status is active, you can send and receive packets on the wireless link.

You can also use wpa_supplicant to associate with a security-disabled Wi-Fi network. For example, if your /etc/wpa_supplicant.conf file can contain a network block as follows:

network = {
    ssid = "network name"
    key_mgmt = NONE
}

you can then run:

wpa_supplicant -i ral0 -c/etc/wpa_supplicant.conf

You may also use wpa_cli to tell wpa_supplicant what you want to do. You can use either ifconfig or wpa_cli to check the status of the network. To complete your network configuration, see "Client in infrastructure or ad hoc mode" in the section on TCP/IP interface configuration.

Using WEP (Wired Equivalent Privacy) for authentication and encryption

WEP can be used for both authentication and privacy with your wireless network. Authentication is a required precursor to allowing a station to associate with an access point. The IEEE 802.11 standard defines the following types of WEP authentication:

Open system authentication
The client is always authenticated with the WAP (i.e. allowed to form an association). Keys that are passed into the client aren't checked to see if they're valid. This can have the peculiar effect of having the client interface go "active" (become associated), but data won't be passed between the AP and station if the station key used to encrypt the data doesn't match that of the station.

Note: If your WEP station is active, but no traffic seems to be going through (e.g. dhcp.client doesn't work), check the key used for bringing up the connection.

Shared key authentication
This method involves a challenge-response handshake in which a challenge message is encrypted by the stations keys and returned to the access point for verification. If the encrypted challenge doesn't match that expected by the access point, then the station is prevented from forming an association.

Unfortunately, this mechanism (in which the challenge and subsequent encrypted response are available over the air) exposes information that could leave the system more open to attacks, so we don't recommended you use it. While the stack does support this mode of operation, the code hasn't been added to ifconfig to allow it to be set.

Note that many access points offer the capability of entering a passphrase that can be used to generate the associated WEP keys. The key-generation algorithm may vary from vendor to vendor. In these cases, the generated hexadecimal keys must be used for the network key (prefaced by 0x when used with ifconfig) and not the passphrase. This is in contrast to access points, which let you enter keys in ASCII. The conversion to the hexadecimal key in that case is a simple conversion of the text into its corresponding ASCII hexadecimal representation. The stack supports this form of conversion.

Given the problems with WEP in general, we recommend you use WPA / WPA2 for authentication and encryption where possible.

The network name can be up to 32 characters long. The WEP key must be either 40 bits long or 104 bits long. This means you have to give either 5 or 13 characters for the WEP key, or a 10- or 26-digit hexadecimal value.

You can use either ifconfig or wpa_supplicant to configure a WEP network.

If you use ifconfig, the command is in the form:

ifconfig if_name ssid the_ssid nwkey the_key

For example, if your interface is ral0, and you're using 128-bit WEP encryption, you can run:

ifconfig ral0 ssid "corporate lan" nwkey corpseckey456 up

Once you've entered the network name and encryption method, the 802.11 network should be active (you can verify this with ifconfig). In the case of ad hoc networks, the status will be shown as active only if there's at least one other peer on the (SSID) network:

ifconfig ral0 
ral0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 
    ssid "corporate lan" nwkey corpseckey456
    powersave off
    bssid 00:11:22:33:44:55 chan 11
    address: 11:44:88:44:88:44
    media: IEEE802.11 autoselect (OFDM36 mode 11g)
    status: active

Once the network status is active, you can send and receive packets on the wireless link.

If you use wpa_supplicant, you need to edit a configuration file to tell it what you want to do. For example:

network = {       
  ssid = "corporate lan"      # The Wi-Fi network you want to associate to.
  key_mgmt= NONE              # NONE is for WEP or no security.
  wep_key0 = "corpseckey456"  # Most of the time, you may specify a list
                              # from wep_key0 to wep_key3 and use
                              # key index to specify which one to use. 
}

Then you may run:

wpa_supplicant -i ral0 -c your_config_file

By default, the configuration file is /etc/wpa_supplicant.conf. Alternatively you may use wpa_cli to tell the wpa_supplicant daemon what you want to do. To complete your network configuration, see "Client in Infrastructure or ad hoc mode" in the section on TCP/IP interface configuration.

Using WPA/WPA2 for authentication and encryption

Background on WPA

The original security mechanism of the IEEE 802.11 standard wasn't designed to be strong and has proven to be insufficient for most networks that require some kind of security. Task group I (Security) of the IEEE 802.11 working group (http://www.ieee802.org/11/) has worked to address the flaws of the base standard and has in practice completed its work in May 2004. The IEEE 802.11i amendment to the IEEE 802.11 standard was approved in June 2004 and published in July 2004.

The Wi-Fi Alliance used a draft version of the IEEE 802.11i work (draft 3.0) to define a subset of the security enhancements, called Wi-Fi Protected Access (WPA), that can be implemented with existing WLAN hardware. This has now become a mandatory component of interoperability testing and certification done by Wi-Fi Alliance. Wi-Fi provides information about WPA at its website, http://www.wi-fi.org/.

The IEEE 802.11 standard defined a Wired Equivalent Privacy (WEP) algorithm for protecting wireless networks. WEP uses RC4 with 40-bit keys, a 24-bit initialization vector (IV), and CRC32 to protect against packet forgery. All these choices have proven to be insufficient:

WPA is an intermediate solution for these security issues. It uses the Temporal Key Integrity Protocol (TKIP) to replace WEP. TKIP is a compromise on strong security, and it's possible to use existing hardware. It still uses RC4 for the encryption as WEP does, but with per-packet RC4 keys. In addition, it implements replay protection and a keyed packet-authentication mechanism.

Keys can be managed using two different mechanisms; WPA can use either of the following:

WPA-Enterprise
An external authentication server (e.g. RADIUS) and EAP, just as IEEE 802.1X is using.
WPA-Personal
Pre-shared keys without the need for additional servers.

Both mechanisms generate a master session key for the Authenticator (AP) and Supplicant (client station).

WPA implements a new key handshake (4-Way Handshake and Group Key Handshake) for generating and exchanging data encryption keys between the Authenticator and Supplicant. This handshake is also used to verify that both Authenticator and Supplicant know the master session key. These handshakes are identical regardless of the selected key management mechanism (only the method for generating master session key changes).

WPA utilities

The wlconfig library is a generic configuration library that interfaces to the supplicant and provides a programmatic interface for configuring your wireless connection. If you've downloaded the source from Foundry27 (http://community.qnx.com/sf/sfmain/do/home), you can find it under trunk/lib/wlconfig.

The main utilities required for Wi-Fi usage are:

wpa_supplicant
Wi-Fi Protected Access client and IEEE 802.1X supplicant. This daemon provides client-side authentication, key management, and network persistence.

The wpa_supplicant requires the following libraries and binaries be present:

  • libcrypto.so -- crypto library
  • libssl.so -- Secure Socket Library (created from OpenSSL)
  • random -- executable that creates /dev/urandom for random-number generation
  • libm.so -- math library required by random
  • libz.so -- compression library required by random

The wpa_supplicant also needs a read/write filesystem for creation of a ctrl_interface directory (see the sample wpa_supplicant.conf configuration file).


Note: You can't use /dev/shmem because it isn't possible to create a directory there.

wpa_cli
WPA command-line client for interacting with wpa_supplicant.
wpa_passphrase
Set the WPA passphrase for a SSID.
hostapd
Server side (Access Point) authentication and key-management daemon.

There are also some subsidiary utilities that you likely won't need to use:

wiconfig
Configuration utility for some wireless drivers. The ifconfig utility can handle the device configuration required without needing this utility.
wlanctl
Examine the IEEE 802.11 wireless LAN client/peer table.

Connecting with WPA or WPA2

Core Networking supports connecting to a wireless network using the more secure option of WPA (Wi-Fi Protected Access) or WPA2 (802.11i) protocols.

The wpa_supplicant application can manage your connection to a single access point, or it can manage a configuration that includes settings for connections to multiple wireless networks (SSIDs) either implementing WPA, or WEP to support roaming from network to network. The wpa_supplicant application supports IEEE802.1X EAP Authentication (referred to as WPA), WPA-PSK, and WPA-NONE (for ad hoc networks) key-management protocols along with encryption support for TKIP and AES (CCMP). A WAP for a simple home or small office wireless network would likely use WPA-PSK for the key-management protocol, while a large office network would use WAP along with a central authentication server such as RADIUS.

To enable a wireless client (or supplicant) to connect to a WAP configured to use WPA, you must first determine the network name (as described above) and get the authentication and encryption methods used from your network administrator. The wpa_supplicant application uses a configuration file (/etc/wpa_supplicant.conf by default) to configure its settings, and then runs as a daemon in the background. You can also use the wpa_cli utility to change the configuration of wpa_supplicant while it's running. Changes done by the wpa_cli utility are saved in the /etc/wpa_supplicant.conf file.

The /etc/wpa_supplicant.conf file has a rich set of options that you can configure, but wpa_supplicant also uses various default settings that help simplify your wireless configuration. For more information, see http://netbsd.gw.com/cgi-bin/man-cgi?wpa_supplicant.conf++NetBSD-4.0.

If you're connecting to a WAP, and your WPA configuration consists of a network name (SSID) and a pre-shared key, your /etc/wpa_supplicant.conf would look like this:

network={ 
    ssid="my_network_name"  #The name of the network you wish to join 
    psk="1234567890"        #The preshared key applied by the access point 
}

Note: Make sure that only root can read and write this file, because it contains the key information in clear text.

Start wpa_supplicant as:

wpa_supplicant -B -i ral0 -c /etc/wpa_supplicant.conf

The -i option specifies the network interface, and -B causes the application to run in the background.

The wpa_supplicant application by default negotiates the use of the WPA protocol, WPA-PSK for key-management, and TKIP or AES for encryption. It uses infrastructure mode by default.

Once the interface status is active (use ifconfig ral0, where ral0 is the interface name, to check), you can apply the appropriate TCP/IP configuration. For more information, see "TCP/IP configuration in a wireless network," later in this chapter.

If you were to create an ad hoc network using WPA, your /etc/wpa_supplicant.conf file would look like this:

network={
    mode=1                   # This sets the mode to be ad hoc.
                             # 0 represents Infrastructure mode 
    ssid="my_network_name"   # The name of the ad hoc network 
    key_mgmt=NONE            # Sets WPA-NONE 
    group=CCMP               # Use AES encryption  
    psk="1234567890"         # The preshared key applied by the access point 
 }  

Note: Again, make sure that this file is readable and writable only by root, because it contains the key information in clear text.

Start wpa_supplicant with:

wpa_supplicant -B -i ral0 -c /etc/wpa_supplicant.conf

where -i specifies the network interface, and -B causes the application to run in the background.

Personal-level authentication and Enterprise-level authentication

WPA is designed to have the following authentication methods:

This section is about the Enterprise-level authentication.

The Enterprise-level authentication methods that have been selected for use within the Wi-Fi certification body are:

The io-pkt manager supports all the above, except for EAP-SIM. Certificates are placed in /etc/cert/user.pem, and CA certificates in /etc/cert/root.pem. The following example is the network definition for wpa_supplicant for each of the above Enterprise-level authentication methods:

ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
update_config=1

# 3.1.2 linksys -- WEP
network={
    ssid="linksys"
    key_mgmt=NONE
    wep_key0="LINKSYSWEPKEY"
}


# 3.1.3 linksys -- WPA
network={
    ssid="linksys"
    key_mgmt=WPA-PSK
    psk="LINKSYSWPAKEY"
}

# 3.1.4 linksys -- WPA2
network={
    ssid="linksys"
    proto=RSN
    key_mgmt=WPA-PSK
    psk="LINKSYS_RSN_KEY"
}

# 3.1.5.1 linksys -- EAP-TLS
network={
   ssid="linksys"
   key_mgmt=WPA-EAP
   eap=TLS
   identity="client1"
   ca_cert="/etc/cert/root.pem"
   client_cert="/etc/cert/client1.pem"
   private_key="/etc/cert/client1.pem"
   private_key_passwd="wzhang"
}


# 3.1.5.2 linksys -- PEAPv1/EAP-GTC
network={
   ssid="linksys"
   key_mgmt=WPA-EAP
   eap=PEAP
   identity="client1"
   password="wzhang"
   ca_cert="/etc/cert/root.pem"
   phase1="peaplabel=0"
   phase2="autheap=GTC"
}

# 3.1.5.3 linksys -- EAP-TTLS/MSCHAPv2
network={
   ssid="linksys"
   key_mgmt=WPA-EAP
   eap=TTLS
   identity="client1"
   password="wzhang"
   ca_cert="/etc/cert/root.pem"
   phase2="autheap=MSCHAPV2"
}

# 3.1.5.4 linksys -- PEAPv1/EAP-MSCHAPV2
network={
   ssid="linksys"
   key_mgmt=WPA-EAP
   eap=PEAP
   identity="client1"
   password="wzhang"
   ca_cert="/etc/cert/root.pem"
   phase1="peaplabel=0"
   phase2="auth=MSCHAPV2"
}

Run wpa_supplicant as follows:

wpa_supplicant -i if_name -c full_path_to_your_config_file

to pick up the configuration file and get the supplicant to perform the required authentication to get access to the Wi-Fi network.

Using wpa_supplicant to manage your wireless network connections

The wpa_supplicant daemon is the "standard" mechanism used to provide persistence of wireless networking information as well as manage automated connections into networks without user intervention.

The supplicant is based on the open-source supplicant (albeit an earlier revision that matches that used by the NetBSD distribution) located at http://hostap.epitest.fi/wpa_supplicant/.

In order to support wireless connectivity, the supplicant:

A sample wpa_supplicant.conf file is installed in /etc for you. It contains a detailed description of the basic supplicant configuration parameters and network parameter descriptions (and there are lots of them) and sample network configuration blocks.

In conjunction with the supplicant is a command-line configuration tool called wpa_cli. This tool lets you query the stack for information on wireless networks, as well as update the configuration file on the fly.

We're also in the process of developing a library of routines that will be pulled into a GUI (or that you can use yourself to create a Wi-Fi configuration tool). This library can be found under the source tree in lib/wlconfig and creates a libwlconfig library for applications to use.

If you want wpa_cli to be capable of updating the wpa_supplicant.conf file, edit the file and uncomment the update_config=1 option. (Note that when wpa_cli rewrites the configuration file, it strips all of the comments.) Copy the file into /etc and make sure that root owns it and is the only user who can read or write it, because it contains clear-text keys and password information.

Given a system with a USB-Wi-Fi dongle based on the RAL chips, here's a sample session showing how to get things working with a WEP based WAP:

# cp $HOME/stage/etc/wpa_supplicant.conf /etc
# chown root:root /etc/wpa_supplicant.conf
# chmod 600 /etc/wpa_supplicant.conf
# io-pkt-v4-hc -dural
# ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192
    inet 127.0.0.1 netmask 0xff000000
ural0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
    ssid ""
    powersave off
    address: 00:ab:cd:ef:d7:ac
    media: IEEE802.11 autoselect
    status: no network
# wpa_supplicant -B -iural0
# wpa_cli
wpa_cli v0.4.9
Copyright (c) 2004-2005, Jouni Malinen <jkmaline@cc.hut.fi> and contributors

This program is free software. You can distribute it and/or modify it
under the terms of the GNU General Public License version 2.

Alternatively, this software may be distributed under the terms of the
BSD license. See README and COPYING for more details.


Selected interface 'ural0'

Interactive mode

> scan
OK
> scan_results
bssid / frequency / signal level / flags / ssid
00:02:34:45:65:76   2437    10  [WPA-EAP-CCMP]  A_NET
00:23:44:44:55:66   2412    10  [WPA-PSK-CCMP]  AN_OTHERNET
00:12:4c:56:a7:8c   2412    10  [WEP]   MY_NET
> list_networks
network id / ssid / bssid / flags
0   simple  any 
1   second ssid any 
2   example any 
> remove_network 0
OK
> remove_network 1
OK
> remove_network 2
OK
> add_network
0
> set_network 0 ssid "MY_NET"
OK
> set_network 0 key_mgmt NONE
OK
> set_network 0 wep_key0 "My_Net_Key234"
OK
> enable_network 0
OK
> save
OK
> list_network
network id / ssid / bssid / flags
0   QWA_NET any 
> status
<2>Trying to associate with 00:12:4c:56:a7:8c (SSID='MY_NET' freq=2412 MHz)
<2>Trying to associate with 00:12:4c:56:a7:8c (SSID='MY_NET' freq=2412 MHz)
wpa_state=ASSOCIATING
> status
<2>Trying to associate with 00:12:4c:56:a7:8c (SSID='MY_NET' freq=2462 MHz)
<2>Associated with 00:12:4c:56:a7:8c
<2>CTRL-EVENT-CONNECTED - Connection to 00:12:4c:56:a7:8c completed (auth)
bssid=00:12:4c:56:a7:8c
ssid=MY_NET
pairwise_cipher=WEP-104
group_cipher=WEP-104
key_mgmt=NONE
wpa_state=COMPLETED
> quit
# dhcp.client -i ural0
# ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192
    inet 127.0.0.1 netmask 0xff000000
ural0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    ssid MY_NET nwkey My_Net_Key234
    powersave off
    bssid 00:12:4c:56:a7:8c chan 11
    address: 00:ab:cd:ef:d7:ac
    media: IEEE802.11 autoselect (OFDM54 mode 11g)
    status: active
    inet 10.42.161.233 netmask 0xfffffc00 broadcast 10.42.160.252
# 

Using a Wireless Access Point (WAP)

A Wireless Access Point (WAP) is a system that allows wireless clients to access the rest of the network or the Internet. Your WAP will operate in BSS mode. A WAP will have at least one wireless network interface to provide a connection point for your wireless clients, and one wired network interface that connects to the rest of your network. Your WAP will act as a bridge or gateway between the wireless clients, and the wired intranet or Internet.

Creating A WAP

To set up your wireless access point, you first need to start the appropriate driver for your network adapters.


Note: Not all network adapter hardware will support operating as an access point. Refer to the documentation for your specific hardware for further information.

For the wireless access point samples, we'll use the devnp-ral.so driver for the RAL wireless chipsets, and the devnp-i82544.so driver for the wired interface. After a default installation, all driver binaries are installed under the directory $QNX_TARGET/cpu/lib/dll (or in the same location in your staging directory if you've built the source yourself).

Use one of the following commands:

If the driver is installed in a location other than /lib/dll, you need to specify the full path and filename of the driver on the command line.

The next step to configure your WAP is to determine whether it will be acting as a gateway or a bridge to the rest of the network, as described below.

Acting as a gateway

When your WAP acts as a gateway, it forwards traffic between two subnets (your wireless network and the wired network). For TCP/IP, this means that the wireless TCP/IP clients can't directly reach the wired TCP/IP clients without first sending their packets to the gateway (your WAP). Your WAP network interfaces will also each be assigned an IP address.

This type of configuration is common for SOHO (small office, home office) or home use, where the WAP is directly connected to your Internet service provider. Using this type of configuration lets you:

The TCP/IP configuration of a gateway and firewall is the same whether your network interfaces are wired or wireless. For details of how to configure a NAT, visit http://www.netbsd.org/documentation/.

Once your network is active, you will assign each interface of your WAP an IP address, enable forwarding of IP packets between interfaces, and apply the appropriate firewall and NAT configuration. For more information, see "DHCP server on WAP acting as a gateway" in the section on TCP/IP interface configuration.

Acting as a bridge

When your WAP acts as a bridge, it's connecting your wireless and wired networks as if they were one physically connected network (broadcast domain, layer 2). In this case, all the wired and wireless hosts are on the same TCP/IP subnet and can directly exchange TCP/IP packets without the need for the WAP to act as a gateway.

In this case, you don't need to assign your WAP network interfaces an IP address to be able to exchange packets between the wireless and wired networks. A bridged WAP could be used to allow wireless clients onto your corporate or home network and have them configured in the same manner as the wireless hosts. You don't need to add more services (such as DHCP) or manipulate routing tables. The wireless clients use the same network resources that the wired network hosts use.


Note: While it isn't necessary to assign your WAP network interfaces an IP address for TCP/IP connectivity between the wireless clients and wired hosts, you probably will want to assign at least one of your WAP interfaces an IP address so that you can address the device in order to manage it or gather statistics.

To enable your WAP to act as a bridge, you first need to create a bridge interface:

ifconfig bridge0 create

In this case, bridge is the specific interface type, while 0 is a unique instance of the interface type. There can be no space between bridge and 0; bridge0 becomes the new interface name.

Use the brconfig command to create a logical link between the interfaces added to the bridge (in this case bridge0). This command adds the interfaces ral0 (our wireless interface) and wm0 (our wired interface). The up option is required to activate the bridge:

brconfig bridge0 add ral0 add wm0 up

Note: Remember to mark your bridge as up, or else it won't be activated.

To see the status of your defined bridge interface, you can use this command:

brconfig bridge0

bridge0: flags=41<UP,RUNNING>
    Configuration:
        priority 32768 hellotime 2 fwddelay 15 maxage 20
    Interfaces:
        en0 flags=3<LEARNING, DISCOVER>
            port 3 priority 128
        ral0 flags=3<LEARNING,DISCOVER>
            port 2 priority 128
    Address cache (max cache: 100, timeout: 1200):

WEP access point


Note: If you're creating a new wireless network, we recommend you use WPA or WPA2 (RSN) rather than WEP, because WPA and WPA2 provide more better security. You should use WEP only if there are devices on your network that don't support WPA or WPA2.

Enabling WEP network authentication and data encryption is similar to configuring a wireless client, because both the WAP and client require the same configuration parameters.

To use your network adapter as a wireless access point, you must first put the network adapter in host access point mode:

ifconfig ral0 mediaopt hostap

You will also likely need to adjust the media type (link speed) for your wireless adapter as the auto-selected default may not be suitable. You can view all the available media types with the ifconfig -m command. They will be listed in the supported combinations of media type and media options. For example, if the combination of:

media OFDM54 mode 11g mediaopt hostap

is listed, you could use the command:

ifconfig ral0 media OFDM54 mediaopt hostap

to set the wireless adapter to use 54 Mbit/s.

The next parameter to specify is the network name or SSID. This can be up to 32 characters long:

ifconfig ral0 ssid "my lan"

The final configuration parameter is the WEP key. The WEP key must be either 40 bits or 104 bits long. You can either enter 5 or 13 characters for the key, or a 10- to 26-digit hexadecimal value. For example:

ifconfig ral0 nwkey corpseckey456

You must also mark your network interface as "up" to activate it:

ifconfig ral0 up

You can also combine all of these commands:

ifconfig ral0 ssid "my lan" nwkey corpseckey456 mediaopt hostap up

Your network should now be marked as up:

ifconfig ral0

ral0: flags=8943<UP,BROADCAST, RUNNING, PROMISC, SIMPLEX, MULTICAST> mtu 1500
    ssid "my lan" apbridge nwkey corpseckey456
    powersave off
    bssid 11:22:33:44:55:66 chan 2
    address: 11:22:33:44:55:66
    media: IEEE802.11 autoselect hostap (autoselect mode 11b hostap)
    status: active

WPA access point

WPA/WPA2 support in Neutrino is provided by the hostapd daemon. This daemon is the access point counterpart to the client side wpa_supplicant daemon. This daemon manages your wireless network adapter when in access point mode. The hostapd configuration is defined in the /etc/hostapd.conf configuration file.

Before you start the hostapd process, you must put the network adapter into host access point mode:

ifconfig ral0 mediaopt hostap

You will also likely need to adjust the media type (link speed) for your wireless adapter, as the auto-selected default may not be suitable. You can view all the available media types with the ifconfig -m command. They will be listed in the supported combinations of media type and media options. For example, if the combination of:

media OFDM54 mode 11g mediaopt hostap

is listed, you could use the command:

ifconfig ral0 media OFDM54 mediaopt hostap

to set the wireless adapter to use 54 Mbit/s.

The remainder of the configuration is handled with the hostapd daemon. It automatically sets your network interface as up, so you don't need to do this step with the ifconfig utility. Here's a simple hostapd configuration file (/etc/hostapd.conf):

interface=ral0
ssid=my home lan
macaddr_acl=0
auth_algs=1
wpa=1
wpa_passphrase=myhomelanpass23456
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP

This configuration uses WPA-PSK for authentication, and AES for data encryption.


Note: The auth_algs and wpa are bit fields, not numeric values.

You can now start the hostapd utility, specifying the configuration file:

hostapd -B /etc/hostapd.conf

The ifconfig command should show that the network interface is active:

ifconfig ral0

ral0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 2290
        ssid "my home lan" apbridge nwkey 2:"",0x49e2a9908872e76b3e5e0c32d09b0b52,0x00000000dc710408c04b32b07c9735b0,""
        powersave off
        bssid 00:15:e9:31:f2:5e chan 4
        address: 00:15:e9:31:f2:5e
        media: IEEE802.11 OFDM54 hostap (OFDM54 mode 11g hostap)
        status: active

Your WAP should now be available to your clients.

TCP/IP configuration in a wireless network

Client in infrastructure or ad hoc mode

Assigning an IP address to your wireless interface is independent of the 802.11 network configuration and uses the same utilities or daemons as a wired network. The main issue is whether your TCP/IP configuration is dynamically assigned, or statically configured. A static TCP/IP configuration can be applied regardless of the state of your wireless network connection. The wireless network could be active, or it could be unavailable until later. A dynamically assigned TCP/IP configuration (via the DHCP protocol) requires that the wireless network configuration be active, so that it can reach the DHCP server somewhere on the network. This is typically applied in a network that is centrally administered (using infrastructure mode with a WAP).

The most common usage case is that you're a client using a Wireless Access Point to connect to the network. In this kind of network, there should be a DHCP server available. After the 802.11 network status is active, you just need to start dhcp.client to complete your TCP/IP configuration. For example:

dhcp.client -iral0

As an alternative, you could use lsm-autoip.so. Auto IP is a special case in that it negotiates with its peers on the network as they become available; you don't need to wait until the network link becomes active to launch it. Auto IP will assign your network interface an IP address and resolve any IP address conflicts with your network peers as they're discovered when either your host or the peer changes its current IP address. You will be able to use this IP address once the wireless network is active. For more information, see the documentation for Auto IP.

The last configuration option is a static configuration, which doesn't change without intervention from the user. Here's an example of a static configuration that uses 10.0.0.5 for the wireless interface IP address, and 10.0.0.1 for the network gateway:

ifconfig ral0 10.0.0.5
route add default 10.0.0.1

cat /etc/resolv.conf

    domain company.com 
    nameserver 10.0.0.2 
    nameserver 10.0.0.3

The other usage case is an ad hoc network. This network mode is typically made up of a number of standalone peers with no central services. Since there's no central server, it's likely that DHCP services won't be available.

If there are Windows or Apple systems on your ad hoc network, they'll enable the Auto IP protocol to assign an IP address. By using Auto IP, you avoid IP address conflicts (two or more hosts using the same IP address), and you avoid having to configure a new IP address manually. Your IP address will be automatically configured, and you'll be able to exchange TCP/IP packets with your peers.

If you're using a static configuration in an ad hoc network, you'll have the added task of deciding what IP address to use on each system, making sure that there are no conflicts, and that all the IP addresses assigned are on the same subnet, so that the systems can communicate.

DHCP server on WAP acting as a gateway

If you've configured your WAP to act as a gateway, you will have your wireless network on a separate subnet from your wired network. In this case, you could be using infrastructure mode or ad hoc mode. The instructions below could work in either mode. You'll likely be using infrastructure mode, so that your network is centrally administered. You can implement DHCP services by running dhcpd directly on your gateway, or by using dhcprelay to contact another DHCP server elsewhere in the ISP or corporate network that manages DHCP services for subnets.

If you're running dhcpd on your gateway, it could be that your gateway is for a SOHO. In this case, your gateway is directly connected to the Internet, or to an IP network for which you don't have control or administrative privileges. You may also be using NAT in this case, as you've been given only one IP address by your Internet Service Provider. Alternatively, you may have administrative privileges for your network subnet which you manage.

If you're running dhcprelay on your gateway, your network subnet is managed elsewhere. You're simply relaying the DHCP client requests on your subnet to the DHCP server that exists elsewhere on the network. Your relay agent forwards the client requests to the server, and then passes the reply packets back to the client.

These configuration examples assume that you have an interface other than the wireless network adapter that's completely configured to exchange TCP/IP traffic and reach any servers noted in these configurations that exist outside of the wireless network. Your gateway will be forwarding IP traffic between this interface and the wireless interface.

Launching the DHCP server on your gateway

This section describes how to launch the DHCP server on the gateway.

DHCP server configuration file

This is a simple dhcpd configuration file, dhcpd.conf. This file includes a subnet range that's dynamically assigned to clients, but also contains two static entries for known servers that are expected to be present at certain IP addresses. One is a printer server, and the other is a network-enabled toaster. The DHCP server configuration isn't specific to wireless networks, and you can apply it to wired networks as well.

ddns-update-style none;

#option subnet-mask 255.255.255.224;
default-lease-time 86400;
#max-lease-time 7200;

subnet 192.168.20.0 netmask 255.255.255.0 {
        range 192.168.20.41 192.168.20.254;
        option broadcast-address 192.168.20.255;
        option routers 192.168.20.1;
        option domain-name-servers 192.168.20.1;
        option domain-name "soho.com";

        host printerserver {
               hardware ethernet 00:50:BA:85:EA:30;
               fixed-address 192.168.20.2;
        }

        host networkenabledtoaster {
               hardware ethernet 00:A0:D2:11:AE:81;
               fixed-address 192.168.20.40;
        }
}

The nameserver, router IP, and IP address will be supplied to your wireless network clients. The router IP address is the IP address of the gateway's wireless network interface that's connected to your wireless network. The nameserver is set to the gateway's wireless network adapter, since the gateway is also handling name serving services. The gateway nameserver will redirect requests for unknown hostnames to the ISP nameserver. The internal wireless network has been defined to be 192.168.20.0. Note that we've reserved IP address range 192.168.20.1 through 192.168.20.40 for static IP address assignment; the dynamic range starts at 192.168.20.41.

Now that we have the configuration file, we need to start dhcpd.

We need to make sure that the directory /var/run exists, as well as /var/state/dhcp. The file /var/state/dhcp/dhcpd.leases must exist. You can create an empty file for the initial start of the dhcpd binary.

When you start dhcpd, you must tell it where to find the configuration file if it isn't in the default location. You also need to pass an interface name, as you want only dhcpd to service your internal wireless network interface. If we used the adapter from the wireless discussion, this would be ral0:

dhcpd -cf /etc/dhcpd.conf ral0

Your DHCP server should now be running. If there are any issues, you can start dhcpd in a debugging mode using the -d option. The dhcpd daemon also logs messages to the system log, slogger.

Launching the DHCP relay agent on your gateway

The dhcprelay agent doesn't require a configuration file as the DHCP server does; you just need to launch a binary on the command line. What you must know is the IP address of the DHCP server that's located elsewhere on the network that your gateway is connected to. Once you've launched dhcprelay, it forwards requests and responses between the client on your wireless network and the DHCP server located elsewhere on the ISP or corporate network:

dhcprelay -i ral0 10.42.42.42

In this case, it relays requests from wireless interface (ral0), and forward these requests to the DHCP server 10.42.42.42.

Configuring an access point as a router

To configure an access point as a router:

  1. Make sure the outside network interface on your access point is active. That is, make sure your access point is active on the wired network that it's connected to.
  2. Configure the access point interface. The simplest mechanism to use for this is WEP.

    Say we want our wireless network to advertise MY_WIRELESS_NET, and our WEP secret is MYWIRELESSWEP. We have to do the following:

    1. Allow packets coming in from one interface to be forwarded (routed) out another:
      #sysctl -w net.inet.ip.forwarding=1
          
    2. Place the wireless interface into access point mode:
      #ifconfig in_nic mediaopt hostap
          
    3. Configure the wireless interface to be a WEP network with an associated key:
      #ifconfig in_nic ssid MY_WIRELESS_NET nwkey MYWIRELESSWEP
          
    4. Bring up the interface:
      #ifconfig in_nic 10.42.0.1 up
          
  3. See above for how you set up DHCP to distribute IP addresses to the wireless client. Briefly, you provide a dhcpd.conf with a configuration section as follows, which defines the internal network:
    subnet 10.42.42.0 netmask 255.255.255.0 {
        range 10.42.0.2 10.42.0.120;
        ...;
    }
      

    Then you run dhcpd:

    #dhcpd -cf full_path_to_your_dhcp_config_file -lf \
    full_path_to_your_release_file ni_nic
      

    You don't need to specify where your dhcpd.conf and release file are if you put them in the default place under /etc. For more information, see the entry for dhcpd in the Utilities Reference.

    To use WPA or WPA2, you need to set up and run hostapd (the server-side application associated with the client's wpa_supplicant) to do the authentication and key exchange for your network.

    You can also configure your access point as a NAT network router as follows:

    #mount -Ttcpip lsm-pfv4.so
      

    so that the PF module is loaded, and then use pfctl to do the configuration.

    For details of how to configure a NAT, visit http://www.netbsd.org/documentation/.