hostapd is a user space daemon for access point and authentication servers. It implements IEEE 802.11 access point management, IEEE 802.1X/WPA/WPA2/WPA3/EAP Authenticators, RADIUS client, EAP server, and RADIUS authentication server. The current version supports Linux (Host AP, madwifi, mac80211-based drivers) and FreeBSD (net80211).
hostapd is designed to be a "daemon" program that runs in the background and acts as the backend component controlling authentication. hostapd supports separate frontend programs and an example text-based frontend, hostapd_cli, is included with hostapd.
Following methods are also supported, but since they do not generate keying material, they cannot be used with WPA or IEEE 802.1X WEP keying.
More information about EAP methods and interoperability testing is available in eap_testing.txt.
Copyright (c) 2002-2019, Jouni Malinen <firstname.lastname@example.org> and contributors.
This software may be distributed, used, and modified under the terms of BSD license. See README for more details.
Please see README for the current documentation.
The original security mechanism of IEEE 802.11 standard was not designed to be strong and has proven to be insufficient for most networks that require some kind of security. Task group I (Security) of IEEE 802.11 working group has worked to address the flaws of the base standard and in practice completed its work in May 2004. The IEEE 802.11i amendment to the IEEE 802.11 standard was approved in June 2004 and published in July 2004.
Wi-Fi Alliance used a draft version of the IEEE 802.11i work (draft 3.0) to define a subset of the security enhancements that can be implemented with existing wlan hardware. This is called Wi-Fi Protected Access (WPA). This has now become a mandatory component of interoperability testing and certification done by Wi-Fi Alliance. Wi-Fi has information about WPA at its web site.
IEEE 802.11 standard defined wired equivalent privacy (WEP) algorithm for protecting wireless networks. WEP uses RC4 with 40-bit keys, 24-bit initialization vector (IV), and CRC32 to protect against packet forgery. All these choices have proven to be insufficient: key space is too small against current attacks, RC4 key scheduling is insufficient (beginning of the pseudorandom stream should be skipped), IV space is too small and IV reuse makes attacks easier, there is no replay protection, and non-keyed authentication does not protect against bit flipping packet data.
WPA is an intermediate solution for the security issues. It uses Temporal Key Integrity Protocol (TKIP) to replace WEP. TKIP is a compromise on strong security and possibility to use existing hardware. It still uses RC4 for the encryption like WEP, but with per-packet RC4 keys. In addition, it implements replay protection, keyed packet authentication mechanism (Michael MIC).
Keys can be managed using two different mechanisms. WPA can either use an external authentication server (e.g., RADIUS) and EAP just like IEEE 802.1X is using or pre-shared keys without need for additional servers. Wi-Fi calls these "WPA-Enterprise" and "WPA-Personal", respectively. Both mechanisms will generate a master session key for the Authenticator (AP) and Supplicant (client station).
WPA implements a new key handshake (4-Way Handshake and Group Key Handshake) for generating and exchanging data encryption keys between the Authenticator and Supplicant. This handshake is also used to verify that both Authenticator and Supplicant know the master session key. These handshakes are identical regardless of the selected key management mechanism (only the method for generating master session key changes).
The design for parts of IEEE 802.11i that were not included in WPA has finished (May 2004) and this amendment to IEEE 802.11 was approved in June 2004. Wi-Fi Alliance is using the final IEEE 802.11i as a new version of WPA called WPA2. This included, e.g., support for more robust encryption algorithm (CCMP: AES in Counter mode with CBC-MAC) to replace TKIP, optimizations for handoff (reduced number of messages in initial key handshake, pre-authentication, and PMKSA caching).
hostapd is configured using a text file that lists all the configuration parameters. See an example configuration file, hostapd.conf, for detailed information about the configuration format and supported fields.
Any comments, reports on success/failure, ideas for further improvement, feature requests, etc. are welcome at email@example.com. Please note, that I often receive more email than I have time to answer. Unfortunately, some messages may not get a reply, but I'll try to go through my mail whenever time permits.
Host AP mailing list can also be used for topics related to hostapd. Since this list has a broader audience, your likelihood of getting responses is higher. This list is recommended for general questions about hostapd and its development. In addition, I will send release notes to it whenever a new version is available.
The mailing list information and web archive is at http://lists.infradead.org/mailman/listinfo/hostap. Messages to firstname.lastname@example.org will be delivered to the subscribers. Please note, that due to large number of spam and virus messages sent to the list address, the list is configured to accept messages only from subscribed addresses.