Wireless/Access point

Purpose of this document
Many drivers these days automatically create an access point, but some will need to create their own if they have to use an older driver or if they want to use multiple access points. The access point also called in some places the "Interface" is the client, software created, viewport to a wireless network. It is necessary to have one to connect wireless network (station). Buy a wireless card that supports "master mode"

What we need for a wireless "base-station" or "access-point" is a wireless network card that does "master mode", which allows our Linux box to behave just like products from the likes of Linksys, Netgear and Belkin - later sections of this HOWTO should be pretty much the same whether you can find a 802.11a, 802.11b or g card that does master mode in Linux.

Do be careful when buying a card for this project - WLAN cards documented as Linux-supported often become no longer available and it's not uncommon for manufacturers of wireless cards to sell completely different cards with a completely new chipset under the model number of a card that is already currently sold. I guess this saves them the trouble and expense of having new packaging and advertising printed, but it causes copious confusion for the Linux-loving enthusiast. Also look out for D-Link's evil naming conventions - the 3 different revisions of the DWL-520 are all different from the DWL-520+, which is different from the DWL-G520, which is different from the DWL-A520 and so on. When you throw into the mix the eight different cards with "DWL" and "650" in their names it can give you a headache just trying to work out which one your supplier is listing, never mind installing the drivers.

Kernels 2.6.33 and above
Starting with these kernels, all WiFi drivers now use the new mac80211/cfg80211 interface. If you use such a kernel, this section should be enough for you.

A list of drivers and their supported modes are available here. Note that this list doesn't take the staging drivers into account.

Prism (HostAP)
Jason Boxman provides quite an excellent description of these drivers: HostAP enables 802.11b access point functionality utilizing the secondary (STA) firmware of Intersil's Prism2, Prism2.5, or Prism3 chipsets for time sensitive tasks. All other functionality is handled via the driver, including WEP and passing frames off to a port authenticator, like FreeRADIUS. Presently, HostAP works with Intersil's Prism chipset and cards utilizing PCI and PC Card interfaces to the host system. (PLX bridging is also supported)

Atheros chipsets (MadWifi)
These cards are well-supported by Linux. See Atheros 5xxx for a compatibility list.

NDISwrapper
NDISwrapper cards are not suitable for base-station use - they don't do master mode. NDISwrapper is basically a layer of interfacing glue to use Microsoft Windows drivers with Linux, and so it denies access to some of the more interesting and/or esoteric functions of the wireless card (because NDIS has no programming interface for them).

If you have a wireless card that you're currently using with NDISwrapper then it's possible that there are native drivers for it - I've seen quite a few posters to the Ubuntu forums suggesting using NDISwrapper with Ralink cards, for instance - but it's more likely that you'll have to bin it (or put it in your sister's Windows PC) and get a card with native drivers that interface properly with the kernel. Note: You can accomplish a similar goal with an Ad-Hoc network; this might help.

Prism54
I wanted a card that supported the Prism54 drivers, as they seemed to be about the most mature ones for "54G" wireless cards under Linux at the time I was looking - my Powerbook has Airport Extreme, Apple's name for 802.11g, so I might as well make use of it. I took a good look through the supported cards and decided upon the Allnet ALL0271. It seemed to be fairly well-recommended on the Prism54.org forums - there are too many short comments saying "worked for me" for me to post all the individual links, so do a search & read all the threads for yourself.

You can order the ALL0271 from the US, from Germany or if you're in the UK, I actually bought a handful, so email me if you'd like to buy one. I also recently got one of these cards working on a friend's SuSE 9.1 box, although the process isn't as brain-dead as it is under Gentoo - portage & the ebuilds automate the process so well.

Ralink rt2400
Its unable to set master mode on rt2400 (using rt2400-cvs-2008051522 driver) - this driver supports only ad-hoc and managed mode.

Ralink rt2500
As I see on the rt2x00 project page, the new branch rt2x00 beta drivers support master mode and all advanced features, but legacy rt2500, rt2570, rt61 drivers do not, but I have no way to test such setup.

For more details on this driver see the project homepage.

You may also want to check Wireless/libnl Access Point. I was in fact able to put my rt2500-based card in Master mode using the instructions from there.

Broadcom 43xx cards (b43)
Broadcom cards support master mode using the reverse-engineered kernel driver. You need to enable (or make as a module) the Softmac wireless extensions and b43 wireless driver.

Realtek RTL8180 cards (rtl8180-sa2400 project)
Master mode is working correctly together with promiscuous mode, but there are problems with Wireless Extensions with version available in Portage together with kernels >=2.6.19 and the card may be handled incorrectly by init scripts. Supports WEP open encryption and possibly TKIP/CCMP(not tested). Broken with new(2.6.20+) kernels. Supports only 1/2/5.5/11M modes.

Texas Instruments ACX100/ACX111
In cards based on this chip (ex. D-Link DWL-520+) master mode is not fully implemented (as of 2007-01-01 driver) and there are some different problems like sometimes no beacons are broadcasted and card can't be properly initiated. Supports 1/2/5.5/11M(b) and 22M(b+) modes.

Intel PRO/Wireless series
For the Intel cards (ipw2100/ipw2200/ipw2915, iwl3945/iwl4965) unfortunately there is no way to use them as AP.

Build a base Gentoo system
This guide assumes you've built Gentoo before - according to the Gentoo Quick Install Guide.

In order to run your wireless drivers you need a couple of options enabled in your kernel, so you might as well do this during your original build. Look for:

Find and enable your drivers
To determine type of your card, emerge pciutils if you haven't done before, and lspci.

You'll have to look under Wireless LAN category mentioned above, or in the portage, in the net-wireless category. Sometimes, when you choose to use driver from kernel, you should also pull in firmware for your card from portage, but not for every card.

To install in-kernel driver enable it either statically or as a module, by pressing y or m over desired item, then recompile and install new kernel or kernel modules.

If you want to use driver outside of kernel tree, proceed to next section.

Requirements
If you want to use driver outside of the kernel tree or your kernel driver depends on a firmware, you'll have to find it in portage, for example by checking /usr/portage/net-wireless/ or by using eix to list all packages: eix net-wireless/. Then you can use emerge to install the package.

Some of the driver packages are available only with testing keyword, others (e.g. rt2x00) require setting USE flags.

Set the testing keyword:

Set the right USE flags:

Of course replace package names and use flags with ones you need.

If you've compiled your wireless driver as a module, don't forget to ensure that it's loaded at boot:

The ebuild is clever enough to pull in everything else it needs:

So now you're ready to go. Neither of the above should be masked, but if they are add them to /etc/portage/package.keywords the same as you did for the driver itself above. If you've chosen just to use the drivers supplied with your kernel then you'll need to emerge these two ebuilds separately.

Please load, if not already done, the proper module for your wireless card using modprobe. Then use iwconfig to check if your card has already been recognized.

eth0     no wireless extensions.

lo       no wireless extensions.

wlan0    NOT READY! ESSID:off/any Mode:Managed Channel:6  Access Point: 00:00:00:00:00:00 Tx-Power=31 dBm  Sensitivity=0/200 Retry min limit:0  RTS thr=0 B   Fragment thr=0 B          Link Quality:0  Signal level:0  Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0  Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0   Missed beacon:0 In this example eth0 is the wired Ethernet network card.

It's fairly obvious from the above that wlan0 is the wireless card. So note now which interface name iwconfig is showing for your wireless card, because you'll need it later on.

Setup the wireless interface

You'll need to create a symlink first. The "-s" option causes the ln to act upon the symlink, rather than following it to the original file.

Here's all the configuration for the wireless interface - eth1 was indicated by iwconfig earlier:

Note: You can alternatively put this is /etc/conf.d/wireless - both files seem to be parsed equally by the init scripts, but /etc/conf.d/wireless is now deprecated. They also have the same format, which I didn't initially realize from reading /etc/conf.d/wireless.example - /etc/conf.d/net.example is also worth perusing.

You will need to load the interface:

You will probably want to bring the wireless interface up at boot:

Now other computers should be able to connect to your access point. It is still unprotected and you cannot access WAN but you can try to ping it. You do not have DHCP enabled on your server yet so you need to think of an own IP in the range 192.168.0.XXX. The access point has the IP 192.168.0.1 and the subnet 255.255.255.0. Make sure you set up your machine you're testing with to be on the right subnet. If you are connected with your access point, you can use ping 192.168.0.1 to check if you can reach your server from outside.

Simple NAT-forwarding setup
The server has access to WAN but if you are connected using your access point, you cannot access it. This is because you need to forward all WAN traffic from your LAN interface (eth0) to your WLAN interface (wlan0). If you are using a PPPoE connection that is established on eth0, you probably have to use the interface ppp0. The following lines were copied from The Gentoo Home Router Guide, so if you have any problems with this, the best place is to look there. Here's the essentials, but you should consider putting a bit more in there, like the way vapier does it.

Save your configuration, and make it reload at boot:

Then add or uncomment the following lines in /etc/sysctl.conf:

If you do not want to set up an IP address manually on each machine, you can also use DHCP. Then your clients assign an IP from the server automatically.

WEP
Now that we have a usable setup, we'd better enable some encryption, so our neighbours don't start making free with our connection. There are two ways to generate a WEP key from the command-line; the more traditional way would involve cat /dev/random and piping it somewhere, but when I did this a few times to get the syntax right I found that I ran out of entropy pretty quick. Since we all have OpenSSL installed (and you would think that OpenSSL's random number generator might be particularly good, anyway) here's how I obtained a random WEP key:

There are loads of pages on the web that will generate a WEP key randomly for you, but I wanted to do it entirely from the terminal, to save you copying & pasting from a web-browser. man openssl explains that openssl rand 13 generates 13 "pseudo-random bytes" and the xxd converts these bytes into a hex string. The next line adds the random string to /etc/conf.d/net in a suitable format for the init scripts to parse it, and finally we need to see what the key is, so we can make a note of it and enter it on the other machine.

The above generates a "128-bit" WEP key - actually, the "13" indicates that you're actually only generating 8 x 13 = 104 bits, but in fact there are another 20 non-random bits on each WEP key, so the name is a bit of a misnomer. If you want a WEP key of only 40 bits, then change the 13 to 5.

If you restart the interface, your other machine should now tell you that Tux is a secure network and ask you for the key.

WPA
It's possible to use WPA encryption together with master mode, but as it requires hostapd, it can be only supported on Prism and Atheros-based cards. In future, maybe it could be used with any card using Mac80211 stack. It can support anything from dynamic WEP through WPA-PSK to WPA2 (RSN) with AES/CCMP encryption with RADIUS accounting. Check out [1] for more information. Note: If you have an Atheros card, add "hostapd madwifi" to your /etc/portage/package.use.

Start by emerging hostapd.

Now you need to edit the /etc/hostapd/hostapd.conf. This is just an example, change as necessary.

Now you need to test that everything is working:

Check that hostapd is working by running:

If everything is working, you should see something like this: hostapd -dd /etc/hostapd/hostapd.conf When that is working, you can kill hostapd and use its init script:

Your client machines are now going to need wpa_supplicant to associate. See Wireless/Configuration and 2 for more information.

Bridging the wired and wireless segments
Our setup will work great so far if you're plugging an Ethernet cable-modem into the wired NIC and only using wireless clients with it - but there are some things it doesn't do so well. If we have one machine connected to the router's wired port and another connecting wirelessly, we won't be able to stream music between them, for instance - that requires them both to be on the same subnet. You'll need to get the bridging tools - the init.d scripts depend upon these:

And ensure that your kernel supports bridging:

Your /etc/conf.d/net will require a complete overhaul - probably best to back it up first! Add the following settings to your /etc/conf.d/net for a bridge with two interfaces.

route -n should now show you the following routes: route -n There must not be a ath0-route. WLAN is already working but if you try to connect using ethernet, it will use the ath0 device instead of br0 so that the pings fail. ath0 occurs in the routing table list because you have set an IP for it in /etc/conf.d/net. Set it to null and your problems should vanish. If there are other routes, that are not mentioned in the list above and you do not know what they are for, it is best to delete all net.* from your runlevels (using rc-update del net. ) and only add net.ppp0 (if you are connecting via PPPoE, otherwise it will be net.eth0) and net.br0. Placing the bridge in the default runlevel Now you need to change the interfaces of your HostAP and of the Dnsmasq.

Emerging dnsmasq.

For Dnsmasq, edit the line interface /etc/dnsmasq.conf so that it points to br0 instead of ath0:

Then add the lines interface=ath0 and bridge=br0 to your hostapd.conf:

If you are using dhcpcd instead of Dnsmasq, you need to change the line DHCPD_IFACE:

The best way to test your setup is to reboot. The bridge should successfully bring the interface net.ath0 up before coming up itself due to the presence of the depends statement. Please check out brctl show to see if the interfaces have been bridged properly.

Now you should now be able to ping across the bridge without needing any forwarding enabled. In the example below I'm sitting at my desktop computer, 192.168.1.71 and ping first the bridge and then a laptop connected to the wireless network. Notice how the first ping response from the laptop is delayed, as the bridge initialises its stuff. Testing the bridge If you have more interfaces, you could of course create NAT on the interface not in the bridge, so computers on wireless and wired segments not only see each other, but also have Internet access, in case of having only one IP, exactly the same way as written in NAT section.

Unwanted IP-based bridge filtering
Sometimes after bridge is being set up, only ARP and STP packets are coming through the bridge. The first symptom is that PCs from the other side of the bridge are in the ARP caches but no communication is possible, and communication with the bridge itself is possible. Try pinging hosts on the other side of the bridge and then run:

It applies not only to wireless bridging. It's fault of Bridged IP/ARP filtering enabled which lets iptables/arptables see and manipulate bridged traffic. To fix it we have to either disable the following in kernel option in kernel:

Or we have to disable some "features" in /proc/sys/net/bridge: Disabling netfilter on bridge And don't forget to add some lines to /etc/sysctl.conf so everything is correct on boot:

Wireless card is unable to transmit packets with other source MAC than it's own
Sometimes only packets transmitted from wireless segment are forwarded to wired segment but do not in opposite direction. The cause of it is a "feature" of wireless NIC, that it can't transmit packets with other source MAC address than it's own. This is most probably dependent on card's firmware as EXACTLY the same chips are used in commercial hardware APs. If you know which cards/chips/drivers suffer this problem, please write it! To fix it we'll need ebtables. Assuming you have already configured your bridge, you have to enable ebtables in your kernel if you didn't already:

I would also recommend enabling other filters/targets, but possibly you'll have to use the fix written before. Don't forget to recompile and set up the kernel or to load apropriate modules. The next thing you have to do is:

After emerge completes, we have to know the MAC address (HWAddr) of WLAN card. Assuming your wireless card is eth1, to get it type: ifconfig eth1 And lastly, enable the MAC Source NAT: Enabling MAC address Source NAT:

Alternatively, use this script to automatically create the rule, don't forget to replace eth1 with correct interface name

Or this sysfs version, which, of course, requires sysfs be mounted but may not work with older drivers if they lack the address sysfs entry...

As of ebtables-2.0.8.2 there is an official init script which I made, utilizing ebtables-save and ebtables-restore so saving and restoring configuration is pretty easy.

Saving rules and adding ebtables to default runlevel

 * 1) Save the already enabled rules:


 * 1) Add the script to the default runlevel:

Now everything should be working fine.

Init script failing with net.wlan0
If you have problems with the init script asking for net.wlan0 which doesn't exist because your interface is named different, you can fix this by modifying /etc/conf.d/hostapd.