HOWTO Building a Wireless Access Point

From Gentoo Linux Wiki

If you have any comments or suggestions, feel free to email me.

[edit] 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).

[edit] 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 & 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 & expense of having new packaging & 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 8 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.

[edit] Prism (HostAP)

Note that cards using these drivers are 11MBPS only.

[edit] Atheros (Madwifi)

Atheros chipset cards can use the MadWifi drivers and tools. After making sure that you have the appropriate kernel support for wireless (not any particular chipset drivers), emerge the madwifi-ng package.

# emerge madwifi-ng

The card will enter standard mode by default, but you want to bring the driver up in master mode. To accomplish this, you need to edit the module options. Note that the default behavior of etc-update will be to remove this customization, so remember to do what is necessary to keep your changes after re-emerging madwifi-ng (say, after a kernel compile).

options ath_pci autocreate=ap

# update-modules

  ifconfig ath0 down
  wlanconfig ath0 destroy
  wlanconfig ath0 create wlandev wifi0 wlanmode ap

Note that in all the rest of the configuration you should use the 'ath0' device, rather than 'wifi0' which appears to just be a container for the rest of the stuff.

This is all just what I've learned trying to set mine up....you should probaby go to http://madwifi.org and read through their wiki and userdocs.

[edit] 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 Windows drivers with Linux, and so it denies access to some of the more interesting &/or esoteric functions of the wireless card (because NDIS has no programming interface for them, I guess).

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.

[edit] 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.

[edit] Ralink rt2400

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

[edit] 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.

[edit] Broadcom 43xx cards (bcm43xx.ko)

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 BCM43xx wireless driver.

[edit] 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.

[edit] 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.

[edit] Intel PRO/Wireless (ipwXXXX) series

For ipw2100/ipw2200, unfortunately there is no way to use them as AP, but this can be done for ipw3945 and ipw4965, maybe ipw2915 too, which are pretty good cards anyway, using fully open-source iwlwifi drivers, but it can't be done with old Intel drivers with closed microcode.

[edit] Build a base Gentoo system

I'm assuming you've built Gentoo before - I just followed the Gentoo Quick Install Guide.

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

CONFIG_HOTPLUG=y
  Bus options (PCI, PCMCIA, EISA, MCA, ISA) --->
    Support for hot-pluggable devices

CONFIG_FW_LOADER: m/y (either one will work)
  Generic Driver Options  --->
     Hotplug firmware loading support

CONFIG_NET_RADIO=y
  Device Drivers --->
    Networking support --->
      Wireless LAN (non-hamradio) --->

This is because:

Now it's time to 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.

[edit] Emerge the nitty-gritty

If you want to use driver outside of the kernel tree, you'll have to find it in portage, for example:

cd /usr/portage/net-wireless
ls
[...]
emerge acx # replace acx with your desired driver name

Some of driver package are available only with testing keyword, others (ex. rt2x00) require setting USE flags. In that case:

mkdir /etc/portage # If you haven't already done so
echo net-wireless/rtl8180 ~x86 >> /etc/portage/package.keywords # To set the testing keyword
echo net-wireless/rt2x00 rt2500 >> /etc/portage/package.use # To set right use flags

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

Finally, if you don't use coldplug or udev coldplugging, and you want your driver to be loaded at startup, add right module to right file in /etc/modules.autoload.d/.

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

• wireless-tools - uh, what it says. Remember the bit in /usr/src/linux/drivers/net/wireless/Kconfig about "a single set of tool can support all the variations of Wireless LANs"?
• hotplug - needed to "upload the firmware to the NIC's ram on initialization"

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.

[edit] First tests - checking your wireless card works

[edit] The technical way:

# modprobe -v prism54
insmod /lib/modules/2.6.8-gentoo-r3/kernel/drivers/net/wireless/prism54/prism54.ko
# iwconfig
eth0      no wireless extensions.

lo        no wireless extensions.

shaper0   no wireless extensions.

dummy0    no wireless extensions.

eth1      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 my wired Ethernet 10base100 network card, probably a Realtek 8139 or an Intel ee100 I had lying around. I compile drivers for the most common types of network cards - any I recognise the name of when I'm doing make menuconfig - statically into the kernel.

It's fairly obvious from the above that eth1 is the wireless card - I hear some folks like to name their wireless interface wlan0 or whatever, but for the life of me I couldn't get this to work. So note now which interface name iwconfig is showing for your wireless card, because you'll need it later on.

[edit] The melodious way:

I tried this hunched over my Macintosh with Kismac listening to its Airport card:
ifconfig eth1 up

BING-BONG! My network stumbler detects a new wireless entity! Macs make melodious announcement noises at every opportunity, you see.
iwconfig eth1 mode Master essid foobert channel 11
BONG-BING! The network stumbler indicates that the network called "foobert" on channel 11 is managed.

iwconfig eth1 essid foobert channel 11 key aabbccdd
BLOOOOP! The network stumbler shows the "foobert" network to have WEP encryption.

So now you know that your WLAN card works and that your kernel & modules are compiled correctly & stuff. If these tests don't work, go away now & have a think why that might be.

[edit] Ensure you have a baselayout which handles wireless config

Well, I don't really like using stuff which isn't in stable, but at the time of writing Roy Marples' work on wireless networking configuration is only just being integrated into the Portage tree.

I started this HOWTO with the intention that it should be entirely independent of Roy's documentation and that it should simply describe building a wireless AP the best way possible. Clearly "the best way possible" means conforming with Gentoo-Portage & ensuring maximum compatibility & future-proofing - there's no point in building our own init configuration scripts if there's already a blueprint for this in Gentoo's baselayout.

So:

echo "=sys-apps/baselayout-1.11.10-r4" >> /etc/portage/package.keywords

At the time of writing you may need to do the same with sys-apps/sysvinit, sys-libs/readline and app-shells/bash in order to satisfy dependencies.

emerge sync
emerge -ua world

I can see why Roy's work is being integrated into official Gentoo - it's really nice. I advise you to take a look at and revise the contents of /etc/conf.d/net - /etc/conf.d/net.example makes very good reading.

[edit] Set-up the wireless interface

You'll need to do this first:
cp -R /etc/init.d/net.eth0 /etc/init.d/net.eth1
The "-R" option causes the `cp` 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:

modules_eth1=( "iwconfig" )
ifconfig_eth1=( "192.168.0.1 netmask 255.255.255.0" )
mode_eth1="Master"
essid_eth1="MyNet"
channel_eth1="1"

You can alternatively put this is /etc/conf.d/net - both files seem to be parsed equally by the init scripts. They also have the same format, which I didn't initially realise from reading /etc/conf.d/wireless.example - /etc/conf.d/net.example is also worth perusing. You might wish to choose another channel - 6 and 11 are common, so you might find your neighbours are already using those.

  # Set the card's 802.11a/b/g mode:
  # Mode 0 = Autoselect (not sure if this is proper for an AP)
  #      1 = 802.11a
  #      2 = 802.11b
  #      3 = 802.11g
  iwpriv_ath0="mode 3"

  # Suppress ssid broadcast:
  iwpriv_ath0="hide_ssid 1"

  # Configure multiple iwpriv settings (example).
  iwpriv_ath0=(
      "mode 3"
      "hide_ssid 1"
  )

NOTE: Mode 0 is proper for an AP. In this mode client will determine speed. For example if I use B card it works in B mode and if I use G or SuperG card it works properly.

If you've compiled your wireless driver as a module, don't forget to ensure that it's loaded at boot:
# echo prism54 >> /etc/modules.autoload.d/kernel-2.6
Substitute ath_pci for prism54 if you're using the Madwifi driver.

And you'll probably want to bring the wireless interface up at boot, too: # rc-update add net.eth1 default

If I now run `/etc/init.d/net.eth1 start`, a message pops up on my Powerbook asking if I'd like to join the unsecured wireless network "MyNet". Cool! I test everything by rebooting the machine, to make sure I've remembered to type everything so far correctly.

At this point you'll need to set up the IP address manually on your laptop, but you should be able to ping the access-point from it. Make sure you set up the laptop you're testing with to be on the right subnet - I chose 192.168.0.1/255.255.255.0 for the IP of my access-point, so I'll need to choose an 192.168.0.XXX address for the laptop.

 Last login: Sat Jan  1 04:01:49 on ttyp2
 Welcome to Darwin!
 Powerboko:~ stroller$ ifconfig en1
 en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet6 fe80::20d:93ff:fe8a:f987 prefixlen 64 scopeid 0x5
        inet 192.168.0.5 netmask 0xffffff00 broadcast 192.168.0.255
        ether 00:0d:93:8a:f9:87
        media: autoselect status: active
        supported media: autoselect
 Powerboko:~ stroller$ ping 192.168.0.1
 PING 192.168.0.1 (192.168.0.1): 56 data bytes
 64 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=2.557 ms
 64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=1.103 ms
 64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=1.065 ms
 64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=1.205 ms
 ^C
 --- 192.168.0.1 ping statistics ---
 4 packets transmitted, 4 packets received, 0% packet loss
 round-trip min/avg/max = 1.065/1.482/2.557 ms
 Powerboko:~ stroller$

[edit] Simple NAT-forwarding setup

At first I'm just going set up simple NAT, which does just the same thing as the basic commercial access-points out there. I got this pretty much straight 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.

# iptables -F
# iptables -t nat -F
# iptables -A FORWARD -i eth1 -s 192.168.0.0/255.255.0.0 -j ACCEPT
# iptables -A FORWARD -i eth0  -d 192.168.0.0/255.255.0.0 -j ACCEPT
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
#  echo 1 > /proc/sys/net/ipv4/ip_forward

Note also how vapier saves his configuration for future boots:

# /etc/init.d/iptables save
# rc-update add iptables default
# nano /etc/sysctl.conf
Add/Uncomment the following lines:
net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1

If you set a valid DNS address on your laptop, you should be able to surf the web! Of course, since you've been looking at the Home Router Guide, you'll probably be thinking about setting up DHCP & DNS servers on your access-point right about now.

[edit] Enabling WEP encryption

Now that we have a usable setup, we'd better enable some encryption, so our neighbours don't start making free with our connection - we don't want them watching all our pr0n, now, do we?!?

I've found 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:

# WEPKEY=`openssl rand 13 | xxd -ps`
# echo key_MyNet="$WEPKEY" >> /etc/conf.d/wireless
# echo $WEPKEY
ec12f20c3e40dceded396d7a49

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 & to learn stuff; I found it quite interesting. man openssl explains that openssl rand 13 generates 13 "pseudo-random bytes" and the xxd command converts these bytes into a hex string. The next line adds the random string to /etc/conf.d/wireless 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 & enter it on our laptop.

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 64 bits 40 bits, then change the 13 to 5.

If you restart the interface, your laptop should now tell you that MyNet is a secure network and ask you for the key - I hope you remembered to take a note of it!

[edit] WPA Encryption

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.

Start by emerging hostapd with madwifi if you have an Atheros card.

 emerge -av hostapd

Now we need to edit hostapd.conf. This is just an example, change as necessary.

##### hostapd configuration file ##############################################
# Empty lines and lines starting with # are ignored
 
# AP netdevice name (without 'ap' postfix, i.e., wlan0 uses wlan0ap for
# management frames); ath0 for madwifi
interface=ath0
 
# In case of madwifi driver, an additional configuration parameter, bridge,
# must be used to notify hostapd if the interface is included in a bridge. This
# parameter is not used with Host AP driver.
#bridge=br0
 
# Driver interface type (hostap/wired/madwifi/prism54; default: hostap)
driver=madwifi
 
# hostapd event logger configuration
#
# Two output method: syslog and stdout (only usable if not forking to
# background).
#
# Module bitfield (ORed bitfield of modules that will be logged; -1 = all
# modules):
# bit 0 (1) = IEEE 802.11
# bit 1 (2) = IEEE 802.1X
# bit 2 (4) = RADIUS
# bit 3 (8) = WPA
# bit 4 (16) = driver interface
# bit 5 (32) = IAPP
#
# Levels (minimum value for logged events):
#  0 = verbose debugging
#  1 = debugging
#  2 = informational messages
#  3 = notification
#  4 = warning
#
logger_syslog=-1
logger_syslog_level=2
logger_stdout=-1
logger_stdout_level=1
 
# Debugging: 0 = no, 1 = minimal, 2 = verbose, 3 = msg dumps, 4 = excessive
debug=0
 
# Dump file for state information (on SIGUSR1)
dump_file=/tmp/hostapd.dump
 
# Interface for separate control program. If this is specified, hostapd
# will create this directory and a UNIX domain socket for listening to requests
# from external programs (CLI/GUI, etc.) for status information and
# configuration. The socket file will be named based on the interface name, so
# multiple hostapd processes/interfaces can be run at the same time if more
# than one interface is used.
# /var/run/hostapd is the recommended directory for sockets and by default,
# hostapd_cli will use it when trying to connect with hostapd.
ctrl_interface=/var/run/hostapd
 
# Access control for the control interface can be configured by setting the
# directory to allow only members of a group to use sockets. This way, it is
# possible to run hostapd as root (since it needs to change network
# configuration and open raw sockets) and still allow GUI/CLI components to be
# run as non-root users. However, since the control interface can be used to
# change the network configuration, this access needs to be protected in many
# cases. By default, hostapd is configured to use gid 0 (root). If you
# want to allow non-root users to use the contron interface, add a new group
# and change this value to match with that group. Add users that should have
# control interface access to this group.
#
# This variable can be a group name or gid.
#ctrl_interface_group=wheel
ctrl_interface_group=0
 
 
##### IEEE 802.11 related configuration #######################################
 
# SSID to be used in IEEE 802.11 management frames
ssid=SecureAP
 
# Station MAC address -based authentication
# 0 = accept unless in deny list
# 1 = deny unless in accept list
# 2 = use external RADIUS server (accept/deny lists are searched first)
macaddr_acl=0
 
# Accept/deny lists are read from separate files (containing list of
# MAC addresses, one per line). Use absolute path name to make sure that the
# files can be read on SIGHUP configuration reloads.
accept_mac_file=/etc/hostapd/hostapd.accept
deny_mac_file=/etc/hostapd/hostapd.deny
 
# IEEE 802.11 specifies two authentication algorithms. hostapd can be
# configured to allow both of these or only one. Open system authentication
# should be used with IEEE 802.1X.
# Bit fields of allowed authentication algorithms:
# bit 0 = Open System Authentication
# bit 1 = Shared Key Authentication (requires WEP)
auth_algs=1
 
# Associate as a station to another AP while still acting as an AP on the same
# channel.
#assoc_ap_addr=00:12:34:56:78:9a
 
##### IEEE 802.1X-2004 related configuration ##################################
 
# Require IEEE 802.1X authorization
#ieee8021x=1
 
# IEEE 802.1X/EAPOL version
# hostapd is implemented based on IEEE Std 802.1X-2004 which defines EAPOL
# version 2. However, there are many client implementations that do not handle
# the new version number correctly (they seem to drop the frames completely).
# In order to make hostapd interoperate with these clients, the version number
# can be set to the older version (1) with this configuration value.
#eapol_version=2
 
# Optional displayable message sent with EAP Request-Identity. The first \0
# in this string will be converted to ASCII-0 (nul). This can be used to
# separate network info (comma separated list of attribute=value pairs); see,
# e.g., draft-adrangi-eap-network-discovery-07.txt.
#eap_message=hello
#eap_message=hello\0networkid=netw,nasid=foo,portid=0,NAIRealms=example.com
 
# WEP rekeying (disabled if key lengths are not set or are set to 0)
# Key lengths for default/broadcast and individual/unicast keys:
# 5 = 40-bit WEP (also known as 64-bit WEP with 40 secret bits)
# 13 = 104-bit WEP (also known as 128-bit WEP with 104 secret bits)
#wep_key_len_broadcast=5
#wep_key_len_unicast=5
# Rekeying period in seconds. 0 = do not rekey (i.e., set keys only once)
#wep_rekey_period=300
 
# EAPOL-Key index workaround (set bit7) for WinXP Supplicant (needed only if
# only broadcast keys are used)
#eapol_key_index_workaround=0
# EAP reauthentication period in seconds (default: 3600 seconds; 0 = disable
# reauthentication).
#eap_reauth_period=3600
 
# Use PAE group address (01:80:c2:00:00:03) instead of individual target
# address when sending EAPOL frames with driver=wired. This is the most common
# mechanism used in wired authentication, but it also requires that the port
# is only used by one station.
#use_pae_group_addr=1
 
##### Integrated EAP server ###################################################
 
# Optionally, hostapd can be configured to use an integrated EAP server
# to process EAP authentication locally without need for an external RADIUS
# server. This functionality can be used both as a local authentication server
# for IEEE 802.1X/EAPOL and as a RADIUS server for other devices.
 
# Use integrated EAP server instead of external RADIUS authentication
# server. This is also needed if hostapd is configured to act as a RADIUS
# authentication server.
#eap_server=0
 
# Path for EAP server user database
#eap_user_file=/etc/hostapd/hostapd.eap_user
 
# CA certificate (PEM or DER file) for EAP-TLS/PEAP/TTLS
#ca_cert=/etc/hostapd/hostapd.ca.pem
 
# Server certificate (PEM or DER file) for EAP-TLS/PEAP/TTLS
#server_cert=/etc/hostapd/hostapd.server.pem
 
# Private key matching with the server certificate for EAP-TLS/PEAP/TTLS
# This may point to the same file as server_cert if both certificate and key
# are included in a single file. PKCS#12 (PFX) file (.p12/.pfx) can also be
# used by commenting out server_cert and specifying the PFX file as the
# private_key.
#private_key=/etc/hostapd/hostapd.server.prv
 
# Passphrase for private key
#private_key_passwd=secret passphrase
 
# Enable CRL verification.
# Note: hostapd does not yet support CRL downloading based on CDP. Thus, a
# valid CRL signed by the CA is required to be included in the ca_cert file.
# This can be done by using PEM format for CA certificate and CRL and
# concatenating these into one file. Whenever CRL changes, hostapd needs to be
# restarted to take the new CRL into use.
# 0 = do not verify CRLs (default)
# 1 = check the CRL of the user certificate
# 2 = check all CRLs in the certificate path
#check_crl=1
 
# Configuration data for EAP-SIM database/authentication gateway interface.
# This is a text string in implementation specific format. The example
# implementation in eap_sim_db.c uses this as the file name for the GSM
# authentication triplets.
#eap_sim_db=/etc/hostapd/hostapd.sim_db
 
 
##### IEEE 802.11f - Inter-Access Point Protocol (IAPP) #######################
 
# Interface to be used for IAPP broadcast packets
#iapp_interface=eth0
 
 
##### RADIUS client configuration #############################################
# for IEEE 802.1X with external Authentication Server, IEEE 802.11
# authentication with external ACL for MAC addresses, and accounting
 
# The own IP address of the access point (used as NAS-IP-Address)
#own_ip_addr=127.0.0.1
 
# Optional NAS-Identifier string for RADIUS messages. When used, this should be
# a unique to the NAS within the scope of the RADIUS server. For example, a
# fully qualified domain name can be used here.
#nas_identifier=ap.example.com
 
# RADIUS authentication server
#auth_server_addr=127.0.0.1
#auth_server_port=1812
#auth_server_shared_secret=secret
 
# RADIUS accounting server
#acct_server_addr=127.0.0.1
#acct_server_port=1813
#acct_server_shared_secret=secret
 
# Secondary RADIUS servers; to be used if primary one does not reply to
# RADIUS packets. These are optional and there can be more than one secondary
# server listed.
#auth_server_addr=127.0.0.2
#auth_server_port=1812
#auth_server_shared_secret=secret2
#
#acct_server_addr=127.0.0.2
#acct_server_port=1813
#acct_server_shared_secret=secret2
 
# Retry interval for trying to return to the primary RADIUS server (in
# seconds). RADIUS client code will automatically try to use the next server
# when the current server is not replying to requests. If this interval is set,
# primary server will be retried after configured amount of time even if the
# currently used secondary server is still working.
#radius_retry_primary_interval=600
 
 
# Interim accounting update interval
# If this is set (larger than 0) and acct_server is configured, hostapd will
# send interim accounting updates every N seconds. Note: if set, this overrides
# possible Acct-Interim-Interval attribute in Access-Accept message. Thus, this
# value should not be configured in hostapd.conf, if RADIUS server is used to
# control the interim interval.
# This value should not be less 600 (10 minutes) and must not be less than
# 60 (1 minute).
#radius_acct_interim_interval=600
 
 
##### RADIUS authentication server configuration ##############################
 
# hostapd can be used as a RADIUS authentication server for other hosts. This
# requires that the integrated EAP authenticator is also enabled and both
# authentication services are sharing the same configuration.
 
# File name of the RADIUS clients configuration for the RADIUS server. If this
# commented out, RADIUS server is disabled.
#radius_server_clients=/etc/hostapd/hostapd.radius_clients
 
# The UDP port number for the RADIUS authentication server
#radius_server_auth_port=1812
 
# Use IPv6 with RADIUS server (IPv4 will also be supported using IPv6 API)
#radius_server_ipv6=1
 
 
##### WPA/IEEE 802.11i configuration ##########################################
 
# Enable WPA. Setting this variable configures the AP to require WPA (either
# WPA-PSK or WPA-RADIUS/EAP based on other configuration). For WPA-PSK, either
# wpa_psk or wpa_passphrase must be set and wpa_key_mgmt must include WPA-PSK.
# For WPA-RADIUS/EAP, ieee8021x must be set (but without dynamic WEP keys),
# RADIUS authentication server must be configured, and WPA-EAP must be included
# in wpa_key_mgmt.
# This field is a bit field that can be used to enable WPA (IEEE 802.11i/D3.0)
# and/or WPA2 (full IEEE 802.11i/RSN):
# bit0 = WPA
# bit1 = IEEE 802.11i/RSN (WPA2) (dot11RSNAEnabled)
wpa=1
 
# WPA pre-shared keys for WPA-PSK. This can be either entered as a 256-bit
# secret in hex format (64 hex digits), wpa_psk, or as an ASCII passphrase
# (8..63 characters) that will be converted to PSK. This conversion uses SSID
# so the PSK changes when ASCII passphrase is used and the SSID is changed.
# wpa_psk (dot11RSNAConfigPSKValue)
# wpa_passphrase (dot11RSNAConfigPSKPassPhrase)
#wpa_psk=0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
wpa_passphrase=MySuperLongSecretPassphrase
 
# Optionally, WPA PSKs can be read from a separate text file (containing list
# of (PSK,MAC address) pairs. This allows more than one PSK to be configured.
# Use absolute path name to make sure that the files can be read on SIGHUP
# configuration reloads.
#wpa_psk_file=/etc/hostapd/hostapd.wpa_psk
 
# Set of accepted key management algorithms (WPA-PSK, WPA-EAP, or both). The
# entries are separated with a space.
# (dot11RSNAConfigAuthenticationSuitesTable)
#wpa_key_mgmt=WPA-PSK WPA-EAP
wpa_key_mgmt=WPA-PSK
 
# Set of accepted cipher suites (encryption algorithms) for pairwise keys
# (unicast packets). This is a space separated list of algorithms:
# CCMP = AES in Counter mode with CBC-MAC [RFC 3610, IEEE 802.11i/D7.0]
# TKIP = Temporal Key Integrity Protocol [IEEE 802.11i/D7.0]
# Group cipher suite (encryption algorithm for broadcast and multicast frames)
# is automatically selected based on this configuration. If only CCMP is
# allowed as the pairwise cipher, group cipher will also be CCMP. Otherwise,
# TKIP will be used as the group cipher.
# (dot11RSNAConfigPairwiseCiphersTable)
wpa_pairwise=TKIP CCMP
 
# Time interval for rekeying GTK (broadcast/multicast encryption keys) in
# seconds. (dot11RSNAConfigGroupRekeyTime)
#wpa_group_rekey=600
 
# Rekey GTK when any STA that possesses the current GTK is leaving the BSS.
# (dot11RSNAConfigGroupRekeyStrict)
#wpa_strict_rekey=1
 
# Time interval for rekeying GMK (master key used internally to generate GTKs
# (in seconds).
#wpa_gmk_rekey=86400
 
# Enable IEEE 802.11i/RSN/WPA2 pre-authentication. This is used to speed up
# roaming be pre-authenticating IEEE 802.1X/EAP part of the full RSN
# authentication and key handshake before actually associating with a new AP.
# (dot11RSNAPreauthenticationEnabled)
#rsn_preauth=1
#
# Space separated list of interfaces from which pre-authentication frames are
# accepted (e.g., 'eth0' or 'eth0 wlan0wds0'. This list should include all
# interface that are used for connections to other APs. This could include
# wired interfaces and WDS links. The normal wireless data interface towards
# associated stations (e.g., wlan0) should not be added, since
# pre-authentication is only used with APs other than the currently associated
# one.
#rsn_preauth_interfaces=eth0

Now we need to test that everything is working. Make sure that your access point is up (without WEP)

 /etc/init.d/net.ath0 start

We check that hostapd is working by running

 hostapd -dd /etc/hostapd/hostapd.conf

If everything is working you should see something like this:

Configuration file: /etc/hostapd/hostapd.conf
madwifi_set_iface_flags: dev_up=0
Using interface ath0 with hwaddr 00:01:02:03:04:05 and ssid 'SecureAP'
madwifi_set_ieee8021x: enabled=1
madwifi_configure_wpa: group key cipher=1
madwifi_configure_wpa: pairwise key ciphers=0xa
madwifi_configure_wpa: key management algorithms=0x2
madwifi_configure_wpa: rsn capabilities=0x0
madwifi_configure_wpa: enable WPA= 0x1
madwifi_set_iface_flags: dev_up=1
madwifi_set_privacy: enabled=1
WPA: group state machine entering state GTK_INIT
WPA: group state machine entering state SETKEYSDONE
madwifi_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=1
Flushing old station entries
madwifi_sta_deauth: addr=ff:ff:ff:ff:ff:ff reason_code=3
Deauthenticate all stations
l2_packet_receive - recvfrom: Network is down

When that is working, simply do

/etc/init.d/hostapd start
rc-update add hostapd default

Your client machines are now going to need wpa_supplicant to associate. See [2] for more information

[edit] Bridging the wired & wireless segments

Our setup will work great so far if you're plugging an Ethernet cable-modem into the wired NIC & 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 & another connecting wirelessly, we won't be able to stream iTunes between them, for instance - that requires them both to be on the same subnet.

If you're only using two interfaces so far, then flush out all the stuff from the simple NAT setup, if applicable:

# iptables -F
# iptables -t nat -F
#  echo 0 > /proc/sys/net/ipv4/ip_forward
# /etc/init.d/iptables save
# nano /etc/sysctl.conf
Add/Uncomment the following lines:
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 0

You'll need to get the bridging tools - the init.d scripts depend upon these:
emerge bridge-utils

And ensure that your kernel supports bridging:

CONFIG_BRIDGE=y

Device Drivers  --->
  Networking support  --->
    Networking options  --->
      <*> 802.1d Ethernet Bridging

NOTE: I found this under:

Networking  --->
  Networking options  --->
    <*> 802.1d Ethernet Bridging

Your /etc/conf.d/net will require a complete overhaul - probably best to back it up first! I've moved all the wireless options from /etc/conf.d/wireless, which I no longer use, as I prefer to have all the options for the bridge in one place.

bridge_br0=( "eth0" "eth1" )

config_eth0=( "null" )
config_eth1=( "null" )

# You NEED to configure the interface as well
config_br0=( "192.168.1.44/24" )
routes_br0=( "default via 192.168.1.1" )

depend_br0() {
   need net.eth0 net.eth1
}

modules_eth1=( "iwconfig" )
mode_eth1="Master"
essid_eth1="MyNet"
channel_eth1="1"
key_MyNet="ec12f20c3e40dceded396d7a49"

Finally, we need to put the bridge in the default runlevel - eth0 & eth1 will also need to remain there, because of the bridge's depend statement above. -- Comment: I took the interfaces that make up the bridge out of the default runlevel, and the bridge successfully brings them up before coming up itself (probably due to the presence of the depends statement).

# cd /etc/init.d/
# ln -s net.lo net.br0
# rc-update -a net.br0 default

The best way to test is to reboot - you should 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.

Last login: Sat Feb 26 13:35:38 on ttyp1
Welcome to Darwin!
515 ~ $ ifconfig en0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet6 fe80::20d:93ff:fe70:1b3e prefixlen 64 scopeid 0x4
        inet 192.168.1.71 netmask 0xffffff00 broadcast 192.168.1.255
        ether 00:0d:93:70:1b:3e
        media: autoselect (100baseTX <full-duplex>) status: active
        supported media: none autoselect 10baseT/UTP <half-duplex> 10baseT/UTP <
full-duplex> 10baseT/UTP <full-duplex,hw-loopback> 100baseTX <half-duplex> 100ba
seTX <full-duplex> 100baseTX <full-duplex,hw-loopback> 1000baseTX <full-duplex>
1000baseTX <full-duplex,hw-loopback> 1000baseTX <full-duplex,flow-control> 1000b
aseTX <full-duplex,flow-control,hw-loopback>
516 ~ $ ping 192.168.1.44
PING 192.168.1.44 (192.168.1.44): 56 data bytes
64 bytes from 192.168.1.44: icmp_seq=0 ttl=64 time=0.36 ms
64 bytes from 192.168.1.44: icmp_seq=1 ttl=64 time=0.25 ms
64 bytes from 192.168.1.44: icmp_seq=2 ttl=64 time=0.239 ms
^C
--- 192.168.1.44 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.239/0.283/0.36 ms
517 ~ $ ping 192.168.1.103
PING 192.168.1.103 (192.168.1.103): 56 data bytes
64 bytes from 192.168.1.103: icmp_seq=0 ttl=64 time=486.961 ms
64 bytes from 192.168.1.103: icmp_seq=1 ttl=64 time=201 ms
64 bytes from 192.168.1.103: icmp_seq=2 ttl=64 time=2.271 ms
^C
--- 192.168.1.103 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 2.271/230.077/486.961 ms
518 ~ $ 

If you now open iTunes on both machines & ensure that Sharing is enabled in Preferences, they should now each show up as a shared library on the other machine, indicating that Rendezvous is working across the bridge. You should now be able to stream music between the wired & wireless segments!

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

[edit] Known problems

[edit] 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:
arp -a
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:

CONFIG_BRIDGE_NETFILTER=y

Networking  --->
  Networking support  --->
    Networking options  --->
      Network packet filtering (replaces ipchains) --->
       [ ] Bridged IP/ARP packets filtering

Or we have to disable some "features" in /proc/sys/net/bridge:

 # cd /proc/sys/net/bridge
 # ls
 bridge-nf-call-arptables  bridge-nf-call-iptables
 bridge-nf-call-ip6tables  bridge-nf-filter-vlan-tagged
 # for f in bridge-nf-*; do echo 0 > $f; done

And don't forget to add some lines to /etc/sysctl.conf so everything is correct on boot:

# Disable bridge filtering
net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-filter-vlan-tagged = 0

[edit] 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:

CONFIG_BRIDGE_NF_EBTABLES=y

Networking  --->
  Networking support  --->
    Networking options  --->
      Network packet filtering (replaces ipchains) --->
        Bridge: Netfilter Configuration --->
         <M> Ethernet Bridge tables (ebtables) support --->
          <M> ebt: broute table support
          <M> ebt: filter table support
          <M> ebt: nat table support
          <M> ebt: snat target support

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:
emerge ebtables
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:

ebtables -t nat -A POSTROUTING -o eth1 -j snat --to-src <MAC address of eth1> 

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

#!/bin/bash

export WLAN=eth1
export WLAN_MAC=$(ifconfig ${WLAN} | grep HWaddr | cut -d ' ' -f 11)

ebtables -t nat -A POSTROUTING -o ${WLAN} -j snat --to-src ${WLAN_MAC}

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.

# Save the already enabled rules:
/etc/init.d/ebtables save

# Add the script to the default runlevel:
rc-update add ebtables default

Now everything should be working fine.