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”.

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, 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.

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.

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.

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):

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.

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.

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.

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.

Replace 192.168.0.20 and 255.255.255.0
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 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 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:

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.

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.

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).

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.

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:

Kernel sources

Windows XP driver binary (.SYS extension)

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:

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: