Hostapd

Hostapd (Host access point daemon) is a user space software access point capable of turning normal network interface cards into access points and authentication servers. The current version supports Linux (Host AP, madwifi, mac80211-based drivers) and FreeBSD (net80211).

Scope of this document
Hostapd can do a lot of things, but only its most basic aspects will be covered in this article.

Requirement
A WiFi card with AP mode support is needed:

WiFi Technology
A brief reminder of the technology involved.

Access Point

 * An AP is like a wireless switch;
 * An AP can only use one band at a time: 2.4GHz OR 5GHz, a so-called "dual-band AP" is just one AP at 2.4GHz and another at 5GHz;
 * An AP using the 2.4GHz band can be b, g, n and ax at the same time (if the hardware supports it);
 * An AP using the 5GHz band can be a, n, ac and ax at the same time (if the hardware supports it);
 * An AP can have multiple SSIDs, making it look like multiple APs, but all will share the same band AND channel.

What it can do

 * Create an AP;
 * Create multiple APs on the same card (if the card supports it, usually up to 8);
 * Create one AP on one card and another AP on a second card, all within a single instance of Hostapd;
 * Use 2.4GHz and 5GHz at the same time on the same card. This requires a card with two radios though, which is pretty rare (but hostapd supports it) - if the card creates two wlanX interfaces, you might be lucky;

What it cannot do

 * Create multiple APs on different channels on the same card. Multiple APs on the same card will share the same channel;
 * Create a dual-band AP, even with two cards. But it can create two APs with the same SSID;
 * Assign IPs to the devices connecting to the AP, a dhcp server is needed for that;
 * Assign an IP to the AP itself, it is not hostapd's job to do that;

IP, DHCP, and Routing
Hostapd only creates wireless Ethernet switches, it does not know about the IP protocol or routing.

IP of the AP
An AP's interface really is just an Ethernet interface:

DHCP
A DHCP server listening on the AP's interface will provide the AP's clients with IPs.

Routing
Nothing special about routing an AP, it behaves exactly like an Ethernet interface.

802.11b/g/n with WPA2-PSK and CCMP
A simple but secure AP with maximal compatibility for current hardware:

802.11a/n/ac with WPA2-PSK and CCMP
A simple but secure AP for recent hardware:

802.11b/g/n triple AP
Three APs on the same card, one with WPA2, one with WPA1, one without encryption.

Hostapd automatically creates new interfaces for the extra APs:

Proper use of the 5GHz band
Depending on where you live, using the 5GHz band for an AP has limitations:
 * some channels are forbidden
 * some channels are for indoor use only
 * some channels cannot be used without first listening to make sure they are not already used by something else (no-IR, a.k.a: no initiate radiation)
 * some channels require DFS to be used (Dynamic Frequency Selection, to prevent interferences with radars)
 * some channels require TPC to be used (Transmit Power Control, to limit interferences)

The problem is that each country has its own rules and those rules are complex and regularly changing.

The package maintains a regulatory database, for each country, of what channels can be used and with what limitations.

To use the database, you either need to emerge with the   USE flag, or make the database directly available to the kernel, as you would with a firmware (the files are: )

CRDA is on its way to being deprecated in favour of the firmware approach but is still maintained.

These limitations are somewhat recent and only implemented in 802.11n/ac/ax devices. Old devices which ignore these limitations may break the law.

Firmwares/drivers
Some firmwares will refuse to work as APs even though they can work as clients.

Some drivers do not implement the required checks (DFS, no-IR, etc) and will also refuse to create APs on most or even all channels.

Currently only Atheros drivers (ath9k, ath10k) are know to properly support AP mode in the 5GHz band. Most notably, the intel driver iwlwifi only has good AP mode support for the 2.4GHz band, AP mode in the 5GHz band is either disabled or crippled.

Invalid BSSID mask
When using virtual APs, this type of error may be encountered:

By default each virtual AP is automatically given a unique MAC address by hostapd, this is calculated by simply adding 1 to the previous MAC address used. If your base interface has a MAC address of 01:02:03:04:05:06, the first virtual AP will get 01:02:03:04:05:07, the second virtual AP will get 01:02:03:04:05:08, etc ...

But hostapd wants all those MAC addresses to match a mask (e.g., ff:ff:ff:ff:ff:fc). And it wants the interface's MAC address to be the first in this block.

Obviously, a lot of luck is required to have an interface's MAC address already matching these conditions.

There are 2 solutions to this problem:
 * 1) Change the interface's MAC address to something matching the rules. The simplest way is to replace the last digit with 0, because it will always be the first address of the block.
 * 2) Even simpler is to set the bssid field for the virtual APs in hostapd's configuration. Any MAC address will work because hostapd no longer enforces the mask rule when this field is set. This may depend on the hardware capabilities, if it doesn't work: go back to the first solution.

"PREV_AUTH_NOT_VALID" and/or "invalid MIC in msg 2/4 of 4-Way Handshake"
If you are unable to connect to the AP and wpa_supplicant returns to following error:

And/or if you get the following error from hostapd:

Make sure you did not use quotes to set the passphrase in hostapd.conf

The wpa_passphrase option takes everything atfer the '='. If there are quotes, they are assumed to be part of the passphrase

External resources

 * Similar page from the Arch Linux Wiki
 * Status of ACS support in Linux drivers, a good sign of proper 5GHz support