25.3 Wireless Networking

Written by Eric Anderson.

25.3.1 Introduction

It can be very useful to be able to use a computer without the annoyance of having a network cable attached at all times. FreeBSD can be used as a wireless client, and even as a wireless “access point”.

25.3.2 Wireless Modes of Operation

There are two different ways to configure 802.11 wireless devices: BSS and IBSS. BSS Mode

BSS mode is the mode that typically is used. BSS mode is also called infrastructure mode. In this mode, a number of wireless access points are connected to a wired network. Each wireless network has its own name. This name is called the SSID of the network.

Wireless clients connect to these wireless access points. The IEEE 802.11 standard defines the protocol that wireless networks use to connect. A wireless client can be tied to a specific network, when a SSID is set. A wireless client can also attach to any network by not explicitly setting a SSID. IBSS Mode

IBSS mode, also called ad-hoc mode, is designed for point to point connections. There are actually two types of ad-hoc mode. One is IBSS mode, also called ad-hoc or IEEE ad-hoc mode. This mode is defined by the IEEE 802.11 standards. The second is called demo ad-hoc mode or Lucent ad-hoc mode (and sometimes, confusingly, ad-hoc mode). This is the old, pre-802.11 ad-hoc mode and should only be used for legacy installations. We will not cover either of the ad-hoc modes further.

25.3.3 Infrastructure Mode Access Points

Access points are wireless networking devices that allow one or more wireless clients to use the device as a central hub. When using an access point, all clients communicate through the access point. Multiple access points are often used to cover a complete area such as a house, business, or park with a wireless network.

Access points typically have multiple network connections: the wireless card, and one or more wired Ethernet adapters for connection to the rest of the network.

Access points can either be purchased prebuilt, or you can build your own with FreeBSD and a supported wireless card. Several vendors make wireless access points and wireless cards with various features. Building a FreeBSD Access Point Requirements

In order to set up a wireless access point with FreeBSD, you need to have a compatible wireless card. Currently, only cards with the Prism chipset are supported. You will also need a wired network card that is supported by FreeBSD (this should not be difficult to find, FreeBSD supports a lot of different devices). For this guide, we will assume you want to bridge(4) all traffic between the wireless device and the network attached to the wired network card.

The hostap functionality that FreeBSD uses to implement the access point works best with certain versions of firmware. Prism 2 cards should use firmware version 1.3.4 or newer. Prism 2.5 and Prism 3 cards should use firmware 1.4.9. Older versions of the firmware way or may not function correctly. At this time, the only way to update cards is with Windows® firmware update utilities available from your card's manufacturer. Setting It Up

First, make sure your system can see the wireless card:

# ifconfig -a
        inet6 fe80::202:2dff:fe2d:c938%wi0 prefixlen 64 scopeid 0x7
        inet netmask 0xff000000 broadcast
        ether 00:09:2d:2d:c9:50
        media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps)
        status: no carrier
        ssid ""
        stationname "FreeBSD Wireless node"
        channel 10 authmode OPEN powersavemode OFF powersavesleep 100
        wepmode OFF weptxkey 1

Do not worry about the details now, just make sure it shows you something to indicate you have a wireless card installed. If you have trouble seeing the wireless interface, and you are using a PC Card, you may want to check out pccardc(8) and pccardd(8) manual pages for more information.

Next, you will need to load a module in order to get the bridging part of FreeBSD ready for the access point. To load the bridge(4) module, simply run the following command:

# kldload bridge

It should not have produced any errors when loading the module. If it did, you may need to compile the bridge(4) code into your kernel. The Bridging section of this handbook should be able to help you accomplish that task.

Now that you have the bridging stuff done, we need to tell the FreeBSD kernel which interfaces to bridge together. We do that by using sysctl(8):

# sysctl net.link.ether.bridge.enable=1
# sysctl net.link.ether.bridge.config="wi0,xl0"
# sysctl net.inet.ip.forwarding=1

On FreeBSD versions earlier than 5.2, you need to use the following options instead:

# sysctl net.link.ether.bridge=1
# sysctl net.link.ether.bridge_cfg="wi0,xl0"
# sysctl net.inet.ip.forwarding=1

Now it is time for the wireless card setup. The following command will set the card into an access point:

# ifconfig wi0 ssid my_net channel 11 media DS/11Mbps mediaopt hostap up stationname "FreeBSD AP"

The ifconfig(8) line brings the wi0 interface up, sets its SSID to my_net, and sets the station name to FreeBSD AP. The media DS/11Mbps sets the card into 11Mbps mode and is needed for any mediaopt to take effect. The mediaopt hostap option places the interface into access point mode. The channel 11 option sets the 802.11b channel to use. The wicontrol(8) manual page has valid channel options for your regulatory domain.

Now you should have a complete functioning access point up and running. You are encouraged to read wicontrol(8), ifconfig(8), and wi(4) for further information.

It is also suggested that you read the section on encryption that follows. Status Information

Once the access point is configured and operational, operators will want to see the clients that are associated with the access point. At any time, the operator may type:

# wicontrol -l
1 station:
00:09:b7:7b:9d:16  asid=04c0, flags=3<ASSOC,AUTH>, caps=1<ESS>, rates=f<1M,2M,5.5M,11M>, sig=38/15

This shows that there is one station associated, along with its parameters. The signal indicated should be used as a relative indication of strength only. Its translation to dBm or other units varies between different firmware revisions. Clients

A wireless client is a system that accesses an access point or another client directly.

Typically, wireless clients only have one network device, the wireless networking card.

There are a few different ways to configure a wireless client. These are based on the different wireless modes, generally BSS (infrastructure mode, which requires an access point), and IBSS (ad-hoc, or peer-to-peer mode). In our example, we will use the most popular of the two, BSS mode, to talk to an access point. Requirements

There is only one real requirement for setting up FreeBSD as a wireless client. You will need a wireless card that is supported by FreeBSD. Setting Up a Wireless FreeBSD Client

You will need to know a few things about the wireless network you are joining before you start. In this example, we are joining a network that has a name of my_net, and encryption turned off.

Note: In this example, we are not using encryption, which is a dangerous situation. In the next section, you will learn how to turn on encryption, why it is important to do so, and why some encryption technologies still do not completely protect you.

Make sure your card is recognized by FreeBSD:

# ifconfig -a
        inet6 fe80::202:2dff:fe2d:c938%wi0 prefixlen 64 scopeid 0x7
        inet netmask 0xff000000 broadcast
        ether 00:09:2d:2d:c9:50
        media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps)
        status: no carrier
        ssid ""
        stationname "FreeBSD Wireless node"
        channel 10 authmode OPEN powersavemode OFF powersavesleep 100
        wepmode OFF weptxkey 1

Now, we can set the card to the correct settings for our network:

# ifconfig wi0 inet netmask ssid my_net

Replace and with a valid IP address and netmask on your wired network. Remember, our access point is bridging the data between the wireless network, and the wired network, so it will appear to the other devices on your network that you are on the wired network just as they are.

Once you have done that, you should be able to ping hosts on the wired network just as if you were connected using a standard wired connection.

If you are experiencing problems with your wireless connection, check to make sure that you are associated (connected) to the access point:

# ifconfig wi0

should return some information, and you should see:

status: associated

If it does not show associated, then you may be out of range of the access point, have encryption on, or possibly have a configuration problem. Encryption

Encryption on a wireless network is important because you no longer have the ability to keep the network contained in a well protected area. Your wireless data will be broadcast across your entire neighborhood, so anyone who cares to read it can. This is where encryption comes in. By encrypting the data that is sent over the airwaves, you make it much more difficult for any interested party to grab your data right out of the air.

The two most common ways to encrypt the data between your client and the access point are WEP, and ipsec(4). WEP

WEP is an abbreviation for Wired Equivalency Protocol. WEP is an attempt to make wireless networks as safe and secure as a wired network. Unfortunately, it has been cracked, and is fairly trivial to break. This also means it is not something to rely on when it comes to encrypting sensitive data.

It is better than nothing, so use the following to turn on WEP on your new FreeBSD access point:

# ifconfig wi0 inet up ssid my_net wepmode on wepkey 0x1234567890 media DS/11Mbps mediaopt hostap

And you can turn on WEP on a client with this command:

# ifconfig wi0 inet netmask ssid my_net wepmode on wepkey 0x1234567890

Note that you should replace the 0x1234567890 with a more unique key. IPsec

ipsec(4) is a much more robust and powerful tool for encrypting data across a network. This is definitely the preferred way to encrypt data over a wireless network. You can read more about ipsec(4) security and how to implement it in the IPsec section of this handbook. Tools

There are a small number of tools available for use in debugging and setting up your wireless network, and here we will attempt to describe some of them and what they do. The bsd-airtools Package

The bsd-airtools package is a complete toolset that includes wireless auditing tools for WEP key cracking, access point detection, etc.

The bsd-airtools utilities can be installed from the net/bsd-airtools port. Information on installing ports can be found in Chapter 4 of this handbook.

The program dstumbler is the packaged tool that allows for access point discovery and signal to noise ratio graphing. If you are having a hard time getting your access point up and running, dstumbler may help you get started.

To test your wireless network security, you may choose to use “dweputils” (dwepcrack, dwepdump and dwepkeygen) to help you determine if WEP is the right solution to your wireless security needs. The wicontrol, ancontrol and raycontrol Utilities

These are the tools you can use to control how your wireless card behaves on the wireless network. In the examples above, we have chosen to use wicontrol(8), since our wireless card is a wi0 interface. If you had a Cisco wireless device, it would come up as an0, and therefore you would use ancontrol(8). The ifconfig Command

The ifconfig(8) command can be used to do many of the same options as wicontrol(8), however it does lack a few options. Check ifconfig(8) for command line parameters and options. Supported Cards Access Points

The only cards that are currently supported for BSS (as an access point) mode are devices based on the Prism 2, 2.5, or 3 chipsets. For a complete list, look at wi(4). 802.11b Clients

Almost all 802.11b wireless cards are currently supported under FreeBSD. Most cards based on Prism, Spectrum24, Hermes, Aironet, and Raylink will work as a wireless network card in IBSS (ad-hoc, peer-to-peer, and BSS) mode. 802.11a & 802.11g Clients

The ath(4) device driver supports 802.11a and 802.11g. If your card is based on an Atheros chipset, you may be able to use this driver.

Unfortunately, there are still many vendors that do not provide schematics for their drivers to the open source community because they regard such information as trade secrets. Consequently, the developers of FreeBSD and other operating systems are left two choices: develop the drivers by a long and pain-staking process of reverse engineering or using the existing driver binaries available for the Microsoft® Windows platforms. Most developers, including those involved with FreeBSD, have taken the latter approach.

Thanks to the contributions of Bill Paul (wpaul), as of FreeBSD 5.3-RELEASE there is “native” support for the Network Driver Interface Specification (NDIS). The FreeBSD NDISulator (otherwise known as Project Evil) takes a Windows driver binary and basically tricks it into thinking it is running on Windows. This feature is still relatively new, but most test cases seem to work adequately.

In order to use the NDISulator, you need three things:

  1. Kernel sources

  2. Windows XP driver binary (.SYS extension)

  3. Windows XP driver configuration file (.INF extension)

You may need to compile the ndis(4) mini port driver wrapper module. As root:

# cd /usr/src/sys/modules/ndis
# make && make install

Locate the files for your specific card. Generally, they can be found on the included CDs or at the vendors' websites. In the following examples, we will use W32DRIVER.SYS and W32DRIVER.INF.

The next step is to compile the driver binary into a loadable kernel module. To accomplish this, as root, go into the if_ndis module directory and copy the Windows driver files into it:

# cd /usr/src/sys/modules/if_ndis
# cp /path/to/driver/W32DRIVER.SYS ./
# cp /path/to/driver/W32DRIVER.INF ./

We will now use the ndiscvt utility to create the driver definition header ndis_driver_data.h to build the module:

# ndiscvt -i W32DRIVER.INF -s W32DRIVER.SYS -o ndis_driver_data.h

The -i and -s options specify the configuration and binary files, respectively. We use the -o ndis_driver_data.h option because the Makefile will be looking for this file when it comes time to build the module.

Note: Some Windows drivers require additional files to operate. You may include them with ndiscvt by using the -f option. Consult the ndiscvt(8) manual page for more information.

Finally, we can build and install the driver module:

# make && make install

To use the driver, you must load the appropriate modules:

# kldload ndis
# kldload if_ndis

The first command loads the NDIS miniport driver wrapper, the second loads the actual network interface. Check dmesg(8) to see if there were any errors loading. If all went well, you should get output resembling the following:

ndis0: <Wireless-G PCI Adapter> mem 0xf4100000-0xf4101fff irq 3 at device 8.0 on pci1
ndis0: NDIS API version: 5.0
ndis0: Ethernet address: 0a:b1:2c:d3:4e:f5
ndis0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
ndis0: 11g rates: 6Mbps 9Mbps 12Mbps 18Mbps 36Mbps 48Mbps 54Mbps

From here you can treat the ndis0 device like any other wireless device (e.g. wi0) and consult the earlier sections of this chapter.

This, and other documents, can be downloaded from ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

For questions about FreeBSD, read the documentation before contacting <questions@FreeBSD.org>.
For questions about this documentation, e-mail <doc@FreeBSD.org>.

Hosting by: Hurra Communications Ltd.
Generated: 2007-01-26 17:58:43