tobi/M7350
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

M7350v1_en_gpl

Browse Source
This commit is contained in:
T
2024-09-09 08:52:07 +00:00
commit f9cc65cfda
65988 changed files with 26357421 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
external/hostap/doc/Makefile
Vendored
+39
View File
@@ -0,0 +1,39 @@
all: docs
%.eps: %.fig
fig2dev -L eps $*.fig $*.eps
%.png: %.fig
fig2dev -L png -m 3 $*.fig | pngtopnm | pnmscale 0.4 | pnmtopng \
> $*.png
%.png: %.dot
dot $*.dot -Tpng -o $*.png
%.eps: %.dot
dot $*.dot -Tps -o $*.eps
_wpa_supplicant.png: wpa_supplicant.png
cp $< $@
docs-pics: wpa_supplicant.png wpa_supplicant.eps hostapd.png hostapd.eps p2p_sm.png p2p_sm.eps p2p_arch.png p2p_arch.eps p2p_arch2.png p2p_arch2.eps
docs: docs-pics
(cd ..; doxygen doc/doxygen.conf; cd doc)
$(MAKE) -C latex
cp latex/refman.pdf wpa_supplicant-devel.pdf
html: docs-pics _wpa_supplicant.png
(cd ..; doxygen doc/doxygen.conf; cd doc)
clean:
rm -f *~
rm -f wpa_supplicant.eps wpa_supplicant.png
rm -f _wpa_supplicant.png
rm -f hostapd.eps hostapd.png
rm -f p2p_sm.eps p2p_sm.png
rm -f p2p_arch.eps p2p_arch.png
rm -f p2p_arch2.eps p2p_arch2.png
rm -f doxygen.warnings
rm -rf html latex
rm -f wpa_supplicant-devel.pdf
external/hostap/doc/code_structure.doxygen
Vendored
+322
View File
@@ -0,0 +1,322 @@
/**
\page code_structure Structure of the source code
[ \ref _wpa_supplicant_core "wpa_supplicant core functionality" |
\ref generic_helper_func "Generic helper functions" |
\ref crypto_func "Cryptographic functions" |
\ref tls_func "TLS library" |
\ref configuration "Configuration" |
\ref ctrl_iface "Control interface" |
\ref wpa_code "WPA supplicant" |
\ref eap_peer "EAP peer" |
\ref eapol_supp "EAPOL supplicant" |
\ref win_port "Windows port" |
\ref test_programs "Test programs" ]
%wpa_supplicant implementation is divided into number of independent
modules. Core code includes functionality for controlling the network
selection, association, and configuration. Independent modules include
WPA code (key handshake, PMKSA caching, pre-authentication), EAPOL
state machine, and EAP state machine and methods. In addition, there
are number of separate files for generic helper functions.
Both WPA and EAPOL/EAP state machines can be used separately in other
programs than %wpa_supplicant. As an example, the included test
programs eapol_test and preauth_test are using these modules.
\ref driver_wrapper "Driver interface API" is defined in driver.h and
all hardware/driver dependent functionality is implemented in
driver_*.c.
\section _wpa_supplicant_core wpa_supplicant core functionality
wpa_supplicant.c
Program initialization, main control loop
main.c
main() for UNIX-like operating systems and MinGW (Windows); this
uses command line arguments to configure wpa_supplicant
events.c
Driver event processing; wpa_supplicant_event() and related functions
wpa_supplicant_i.h
Internal definitions for %wpa_supplicant core; should not be
included into independent modules
\section generic_helper_func Generic helper functions
%wpa_supplicant uses generic helper functions some of which are shared
with with hostapd. The following C files are currently used:
eloop.c and eloop.h
Event loop (select() loop with registerable timeouts, socket read
callbacks, and signal callbacks)
common.c and common.h
Common helper functions
defs.h
Definitions shared by multiple files
l2_packet.h, l2_packet_linux.c, and l2_packet_pcap.c
Layer 2 (link) access wrapper (includes native Linux implementation
and wrappers for libdnet/libpcap). A new l2_packet implementation
may need to be added when porting to new operating systems that are
not supported by libdnet/libpcap. Makefile can be used to select which
l2_packet implementation is included. l2_packet_linux.c uses Linux
packet sockets and l2_packet_pcap.c has a more portable version using
libpcap and libdnet.
pcsc_funcs.c and pcsc_funcs.h
Wrapper for PC/SC lite SIM and smart card readers
priv_netlink.h
Private version of netlink definitions from Linux kernel header files;
this could be replaced with C library header file once suitable
version becomes commonly available
version.h
Version number definitions
wireless_copy.h
Private version of Linux wireless extensions definitions from kernel
header files; this could be replaced with C library header file once
suitable version becomes commonly available
\section crypto_func Cryptographic functions
md5.c and md5.h
MD5 (replaced with a crypto library if TLS support is included)
HMAC-MD5 (keyed checksum for message authenticity validation)
rc4.c and rc4.h
RC4 (broadcast/default key encryption)
sha1.c and sha1.h
SHA-1 (replaced with a crypto library if TLS support is included)
HMAC-SHA-1 (keyed checksum for message authenticity validation)
PRF-SHA-1 (pseudorandom (key/nonce generation) function)
PBKDF2-SHA-1 (ASCII passphrase to shared secret)
T-PRF (for EAP-FAST)
TLS-PRF (RFC 2246)
sha256.c and sha256.h
SHA-256 (replaced with a crypto library if TLS support is included)
aes_wrap.c, aes_wrap.h, aes.c
AES (replaced with a crypto library if TLS support is included),
AES Key Wrap Algorithm with 128-bit KEK, RFC3394 (broadcast/default
key encryption),
One-Key CBC MAC (OMAC1) hash with AES-128,
AES-128 CTR mode encryption,
AES-128 EAX mode encryption/decryption,
AES-128 CBC
crypto.h
Definition of crypto library wrapper
crypto_openssl.c
Wrapper functions for libcrypto (OpenSSL)
crypto_internal.c
Wrapper functions for internal crypto implementation
crypto_gnutls.c
Wrapper functions for libgcrypt (used by GnuTLS)
ms_funcs.c and ms_funcs.h
Helper functions for MSCHAPV2 and LEAP
tls.h
Definition of TLS library wrapper
tls_none.c
Dummy implementation of TLS library wrapper for cases where TLS
functionality is not included.
tls_openssl.c
TLS library wrapper for openssl
tls_internal.c
TLS library for internal TLS implementation
tls_gnutls.c
TLS library wrapper for GnuTLS
\section tls_func TLS library
asn1.c and asn1.h
ASN.1 DER parsing
bignum.c and bignum.h
Big number math
rsa.c and rsa.h
RSA
x509v3.c and x509v3.h
X.509v3 certificate parsing and processing
tlsv1_client.c, tlsv1_client.h
TLSv1 client (RFC 2246)
tlsv1_client_i.h
Internal structures for TLSv1 client
tlsv1_client_read.c
TLSv1 client: read handshake messages
tlsv1_client_write.c
TLSv1 client: write handshake messages
tlsv1_common.c and tlsv1_common.h
Common TLSv1 routines and definitions
tlsv1_cred.c and tlsv1_cred.h
TLSv1 credentials
tlsv1_record.c and tlsv1_record.h
TLSv1 record protocol
\section configuration Configuration
config_ssid.h
Definition of per network configuration items
config.h
Definition of the %wpa_supplicant configuration
config.c
Configuration parser and common functions
config_file.c
Configuration backend for text files (e.g., wpa_supplicant.conf)
config_winreg.c
Configuration backend for Windows registry
\section ctrl_iface Control interface
%wpa_supplicant has a \ref ctrl_iface_page "control interface"
that can be used to get status
information and manage operations from external programs. An example
command line interface (wpa_cli) and GUI (wpa_gui) for this interface
are included in the %wpa_supplicant distribution.
ctrl_iface.c and ctrl_iface.h
%wpa_supplicant-side of the control interface
ctrl_iface_unix.c
UNIX domain sockets -based control interface backend
ctrl_iface_udp.c
UDP sockets -based control interface backend
ctrl_iface_named_pipe.c
Windows named pipes -based control interface backend
wpa_ctrl.c and wpa_ctrl.h
Library functions for external programs to provide access to the
%wpa_supplicant control interface
wpa_cli.c
Example program for using %wpa_supplicant control interface
\section wpa_code WPA supplicant
wpa.c and wpa.h
WPA state machine and 4-Way/Group Key Handshake processing
preauth.c and preauth.h
PMKSA caching and pre-authentication (RSN/WPA2)
wpa_i.h
Internal definitions for WPA code; not to be included to other modules.
\section eap_peer EAP peer
\ref eap_peer_module "EAP peer implementation" is a separate module that
can be used by other programs than just %wpa_supplicant.
eap.c and eap.h
EAP state machine and method interface
eap_defs.h
Common EAP definitions
eap_i.h
Internal definitions for EAP state machine and EAP methods; not to be
included in other modules
eap_sim_common.c and eap_sim_common.h
Common code for EAP-SIM and EAP-AKA
eap_tls_common.c and eap_tls_common.h
Common code for EAP-PEAP, EAP-TTLS, and EAP-FAST
eap_tlv.c and eap_tlv.h
EAP-TLV code for EAP-PEAP and EAP-FAST
eap_ttls.c and eap_ttls.h
EAP-TTLS
eap_pax.c, eap_pax_common.h, eap_pax_common.c
EAP-PAX
eap_psk.c, eap_psk_common.h, eap_psk_common.c
EAP-PSK (note: this is not needed for WPA-PSK)
eap_sake.c, eap_sake_common.h, eap_sake_common.c
EAP-SAKE
eap_gpsk.c, eap_gpsk_common.h, eap_gpsk_common.c
EAP-GPSK
eap_aka.c, eap_fast.c, eap_gtc.c, eap_leap.c, eap_md5.c, eap_mschapv2.c,
eap_otp.c, eap_peap.c, eap_sim.c, eap_tls.c
Other EAP method implementations
\section eapol_supp EAPOL supplicant
eapol_supp_sm.c and eapol_supp_sm.h
EAPOL supplicant state machine and IEEE 802.1X processing
\section win_port Windows port
ndis_events.c
Code for receiving NdisMIndicateStatus() events and delivering them to
%wpa_supplicant driver_ndis.c in more easier to use form
win_if_list.c
External program for listing current network interface
\section test_programs Test programs
radius_client.c and radius_client.h
RADIUS authentication client implementation for eapol_test
radius.c and radius.h
RADIUS message processing for eapol_test
eapol_test.c
Standalone EAP testing tool with integrated RADIUS authentication
client
preauth_test.c
Standalone RSN pre-authentication tool
wpa_passphrase.c
WPA ASCII passphrase to PSK conversion
*/
external/hostap/doc/ctrl_iface.doxygen
Vendored
+1054
View File
File diff suppressed because it is too large Load Diff
external/hostap/doc/dbus.doxygen
Vendored
+756
View File
@@ -0,0 +1,756 @@
/**
\page dbus %wpa_supplicant D-Bus API
This section documents the %wpa_supplicant D-Bus API. Every D-Bus
interface implemented by %wpa_supplicant is described here including
their methods, signals, and properties with arguments, returned
values, and possible errors.
Interfaces:
- \ref dbus_main
- \ref dbus_interface
- \ref dbus_wps
- \ref dbus_bss
- \ref dbus_network
\section dbus_main fi.w1.wpa_supplicant1
Interface implemented by the main %wpa_supplicant D-Bus object
registered in the bus with fi.w1.wpa_supplicant1 name.
\subsection dbus_main_methods Methods
<ul>
<li>
<h3>CreateInterface ( a{sv} : args ) --> o : interface</h3>
<p>Registers a wireless interface in %wpa_supplicant.</p>
<h4>Arguments</h4>
<dl>
<dt>a{sv} : args</dt>
<dd>
A dictionary with arguments used to add the interface to %wpa_supplicant. The dictionary may contain the following entries:
<table>
<tr><th>Key</th><th>Value type</th><th>Description</th><th>Required</th>
<tr><td>Ifname</td><td>s</td><td>Name of the network interface to control, e.g., wlan0</td><td>Yes</td>
<tr><td>Bridge_ifname</td><td>s</td><td>Name of the bridge interface to control, e.g., br0</td><td>No</td>
<tr><td>Driver</td><td>s</td><td>Driver name which the interface uses, e.g., nl80211</td><td>No</td>
</table>
</dd>
</dl>
<h4>Returns</h4>
<dl>
<dt>o : interface</dt>
<dd>A D-Bus path to object representing created interface</dd>
</dl>
<h4>Possible errors</h4>
<dl>
<dt>fi.w1.wpa_supplicant1.InterfaceExists</dt>
<dd>%wpa_supplicant already controls this interface.</dd>
<dt>fi.w1.wpa_supplicant1.UnknownError</dt>
<dd>Creating interface failed for an unknown reason.</dd>
<dt>fi.w1.wpa_supplicant1.InvalidArgs</dt>
<dd>Invalid entries were found in the passed argument.</dd>
</dl>
</li>
<li>
<h3>RemoveInterface ( o : interface ) --> nothing</h3>
<p>Deregisters a wireless interface from %wpa_supplicant.</p>
<h4>Arguments</h4>
<dl>
<dt>o : interface</dt>
<dd>A D-Bus path to an object representing an interface to remove returned by CreateInterface</dd>
</dl>
<h4>Possible errors</h4>
<dl>
<dt>fi.w1.wpa_supplicant1.InterfaceUnknown</dt>
<dd>Object pointed by the path doesn't exist or doesn't represent an interface.</dd>
<dt>fi.w1.wpa_supplicant1.UnknownError</dt>
<dd>Removing interface failed for an unknown reason.</dd>
</dl>
</li>
<li>
<h3>GetInterface ( s : ifname ) --> o : interface</h3>
<p>Returns a D-Bus path to an object related to an interface which %wpa_supplicant already controls.</p>
<h4>Arguments</h4>
<dl>
<dt>s : ifname</dt>
<dd>Name of the network interface, e.g., wlan0</dd>
</dl>
<h4>Returns</h4>
<dl>
<dt>o : interface</dt>
<dd>A D-Bus path to an object representing an interface</dd>
</dl>
<h4>Possible errors</h4>
<dl>
<dt>fi.w1.wpa_supplicant1.InterfaceUnknown</dt>
<dd>An interface with the passed name in not controlled by %wpa_supplicant.</dd>
<dt>fi.w1.wpa_supplicant1.UnknownError</dt>
<dd>Getting an interface object path failed for an unknown reason.</dd>
</dl>
</li>
</ul>
\subsection dbus_main_properties Properties
<ul>
<li>
<h3>DebugLevel - s - (read/write)</h3>
<p>Global %wpa_supplicant debugging level. Possible values are
"msgdump" (verbose debugging), "debug" (debugging),
"info" (informative), "warning" (warnings), and "error" (errors).</p>
</li>
<li>
<h3>DebugTimestamp - b - (read/write)</h3>
<p>Global %wpa_supplicant debugging parameter. Determines if timestamps are shown in debug logs.</p>
</li>
<li>
<h3>DebugShowKeys - b - (read/write)</h3>
<p>Global %wpa_supplicant debugging parameter. Determines if secrets are shown in debug logs.</p>
</li>
<li>
<h3>Interfaces - ao - (read)</h3>
<p>An array with paths to D-Bus objects representing controlled interfaces each.</p>
</li>
<li>
<h3>EapMethods - as - (read)</h3>
<p>An array with supported EAP methods names.</p>
</li>
</ul>
\subsection dbus_main_signals Signals
<ul>
<li>
<h3>InterfaceAdded ( o : interface, a{sv} : properties )</h3>
<p>A new interface was added to %wpa_supplicant.</p>
<h4>Arguments</h4>
<dl>
<dt>o : interface</dt>
<dd>A D-Bus path to an object representing the added interface</dd>
</dl>
<dl>
<dt>a{sv} : properties</dt>
<dd>A dictionary containing properties of added interface.</dd>
</dl>
</li>
<li>
<h3>InterfaceRemoved ( o : interface )</h3>
<p>An interface was removed from %wpa_supplicant.</p>
<h4>Arguments</h4>
<dl>
<dt>o : interface</dt>
<dd>A D-Bus path to an object representing the removed interface</dd>
</dl>
</li>
<li>
<h3>PropertiesChanged ( a{sv} : properties )</h3>
<p>Some properties have changed.</p>
<h4>Arguments</h4>
<dl>
<dt>a{sv} : properties</dt>
<dd>A dictionary with pairs of properties names which have changed and theirs new values. Possible dictionary keys are: "DebugParams"</dd>
</dl>
</li>
</ul>
\section dbus_interface fi.w1.wpa_supplicant1.Interface
Interface implemented by objects related to network interface added to
%wpa_supplicant, i.e., returned by
fi.w1.wpa_supplicant1.CreateInterface.
\subsection dbus_interface_methods Methods
<ul>
<li>
<h3>Scan ( a{sv} : args ) --> nothing</h3>
<p>Triggers a scan.</p>
<h4>Arguments</h4>
<dl>
<dt>a{sv} : args</dt>
<dd>
A dictionary with arguments describing scan type:
<table>
<tr><th>Key</th><th>Value type</th><th>Description</th><th>Required</th>
<tr><td>Type</td><td>s</td><td>Type of the scan. Possible values: "active", "passive"</td><td>Yes</td>
<tr><td>SSIDs</td><td>aay</td><td>Array of SSIDs to scan for (applies only if scan type is active)</td><td>No</td>
<tr><td>IEs</td><td>aay</td><td>Information elements to used in active scan (applies only if scan type is active)</td><td>No</td>
<tr><td>Channels</td><td>a(uu)</td><td>Array of frequencies to scan in form of (center, width) in MHz.</td><td>No</td>
</table>
</dd>
</dl>
<h4>Possible errors</h4>
<dl>
<dt>fi.w1.wpa_supplicant1.InvalidArgs</dt>
<dd>Invalid entries were found in the passed argument.</dd>
</dl>
</li>
<li>
<h3>Disconnect ( ) --> nothing</h3>
<p>Disassociates the interface from current network.</p>
<h4>Possible errors</h4>
<dl>
<dt>fi.w1.wpa_supplicant1.NotConnected</dt>
<dd>Interface is not connected to any network.</dd>
</dl>
</li>
<li>
<h3>AddNetwork ( a{sv} : args ) --> o : network</h3>
<p>Adds a new network to the interface.</p>
<h4>Arguments</h4>
<dl>
<dt>a{sv} : args</dt>
<dd>A dictionary with network configuration. Dictionary entries are equivalent to entries in the "network" block in %wpa_supplicant configuration file. Entry values should be appropriate type to the entry, e.g., an entry with key "frequency" should have value type int.</dd>
</dl>
<h4>Returns</h4>
<dl>
<dt>o : network</dt>
<dd>A D-Bus path to an object representing a configured network</dd>
</dl>
<h4>Possible errors</h4>
<dl>
<dt>fi.w1.wpa_supplicant1.InvalidArgs</dt>
<dd>Invalid entries were found in the passed argument.</dd>
<dt>fi.w1.wpa_supplicant1.UnknownError</dt>
<dd>Adding network failed for an unknown reason.</dd>
</dl>
</li>
<li>
<h3>RemoveNetwork ( o : network ) --> nothing</h3>
<p>Removes a configured network from the interface.</p>
<h4>Arguments</h4>
<dl>
<dt>o : network</dt>
<dd>A D-Bus path to an object representing a configured network returned by fi.w1.wpa_supplicant1.Interface.AddNetwork</dd>
</dl>
<h4>Possible errors</h4>
<dl>
<dt>fi.w1.wpa_supplicant1.NetworkUnknown</dt>
<dd>A passed path doesn't point to any network object.</dd>
<dt>fi.w1.wpa_supplicant1.InvalidArgs</dt>
<dd>A passed path doesn't point to any network object.</dd>
<dt>fi.w1.wpa_supplicant1.UnknownError</dt>
<dd>Removing network failed for an unknown reason.</dd>
</dl>
</li>
<li>
<h3>SelectNetwork ( o : network ) --> nothing</h3>
<p>Attempt association with a configured network.</p>
<h4>Arguments</h4>
<dl>
<dt>o : network</dt>
<dd>A D-Bus path to an object representing a configured network returned by fi.w1.wpa_supplicant1.Interface.AddNetwork</dd>
</dl>
<h4>Possible errors</h4>
<dl>
<dt>fi.w1.wpa_supplicant1.NetworkUnknown</dt>
<dd>A passed path doesn't point to any network object.</dd>
<dt>fi.w1.wpa_supplicant1.InvalidArgs</dt>
<dd>A passed path doesn't point to any network object.</dd>
</dl>
</li>
<li>
<h3>AddBlob ( s : name, ay : data ) --> nothing</h3>
<p>Adds a blob to the interface.</p>
<h4>Arguments</h4>
<dl>
<dt>s : name</dt>
<dd>A name of a blob</dd>
<dt>ay : data</dt>
<dd>A blob data</dd>
</dl>
<h4>Possible errors</h4>
<dl>
<dt>fi.w1.wpa_supplicant1.BlobExists</dt>
<dd>A blob with the specified name already exists.</dd>
</dl>
</li>
<li>
<h3>RemoveBlob ( s : name ) --> nothing</h3>
<p>Removes the blob from the interface.</p>
<h4>Arguments</h4>
<dl>
<dt>s : name</dt>
<dd>A name of the blob to remove</dd>
</dl>
<h4>Possible errors</h4>
<dl>
<dt>fi.w1.wpa_supplicant1.BlobUnknown</dt>
<dd>A blob with the specified name doesn't exist.</dd>
</dl>
</li>
<li>
<h3>GetBlob ( s : name ) --> ay : data</h3>
<p>Returns the blob data of a previously added blob.</p>
<h4>Arguments</h4>
<dl>
<dt>s : name</dt>
<dd>A name of the blob</dd>
</dl>
<h4>Returns</h4>
<dl>
<dt>ay : data</dt>
<dd>A blob data</dd>
</dl>
<h4>Possible errors</h4>
<dl>
<dt>fi.w1.wpa_supplicant1.BlobUnknown</dt>
<dd>A blob with the specified name doesn't exist.</dd>
</dl>
</li>
<li>
<h3>AutoScan ( s : arg ) --> nothing</h3>
<p>Set autoscan parameters for the interface.</p>
<h4>Arguments</h4>
<dl>
<dt>s : arg</dt>
<dd>Autoscan parameter line or empty to unset autoscan.</dd>
</dl>
<h4>Possible errors</h4>
<dl>
<dt>fi.w1.wpa_supplicant1.NoMemory</dt>
<dd>Needed memory was not possible to get allocated.</dd>
<dt>fi.w1.wpa_supplicant1.InvalidArgs</dt>
<dd>Invalid entries were found in the passed argument.</dd>
</dl>
</li>
</ul>
\subsection dbus_interface_properties Properties
<ul>
<li>
<h3>Capabilities - a{sv} - (read)</h3>
<p>Capabilities of the interface. Dictionary contains following entries:</p>
<table>
<tr><th>Key</th><th>Value type</th><th>Description</th>
<tr><td>Pairwise</td><td>as</td><td>Possible array elements: "ccmp", "tkip", "none"</td>
<tr><td>Group</td><td>as</td><td>Possible array elements: "ccmp", "tkip", "wep104", "wep40"</td>
<tr><td>KeyMgmt</td><td>as</td><td>Possible array elements: "wpa-psk", "wpa-ft-psk", "wpa-psk-sha256", "wpa-eap", "wpa-ft-eap", "wpa-eap-sha256", "ieee8021x", "wpa-none", "wps", "none"</td>
<tr><td>Protocol</td><td>as</td><td>Possible array elements: "rsn", "wpa"</td>
<tr><td>AuthAlg</td><td>as</td><td>Possible array elements: "open", "shared", "leap"</td>
<tr><td>Scan</td><td>as</td><td>Possible array elements: "active", "passive", "ssid"</td>
<tr><td>Modes</td><td>as</td><td>Possible array elements: "infrastructure", "ad-hoc", "ap"</td>
</table>
</li>
<li>
<h3>State - s - (read)</h3>
<p>A state of the interface. Possible values are: return "disconnected", "inactive", "scanning", "authenticating", "associating", "associated", "4way_handshake", "group_handshake", "completed","unknown".</p>
</li>
<li>
<h3>Scanning - b - (read)</h3>
<p>Determines if the interface is already scanning or not</p>
</li>
<li>
<h3>ApScan - u - (read/write)</h3>
<p>Identical to ap_scan entry in %wpa_supplicant configuration file. Possible values are 0, 1 or 2.</p>
</li>
<li>
<h3>BSSExpireAge - u - (read/write)</h3>
<p>Identical to bss_expiration_age entry in %wpa_supplicant configuration file.</p>
</li>
<li>
<h3>BSSExpireCount - u - (read/write)</h3>
<p>Identical to bss_expiration_scan_count entry in %wpa_supplicant configuration file.</p>
</li>
<li>
<h3>Country - s - (read/write)</h3>
<p>Identical to country entry in %wpa_supplicant configuration file.</p>
</li>
<li>
<h3>Ifname - s - (read)</h3>
<p>Name of network interface controlled by the interface, e.g., wlan0.</p>
</li>
<li>
<h3>BridgeIfname - s - (read)</h3>
<p>Name of bridge network interface controlled by the interface, e.g., br0.</p>
</li>
<li>
<h3>Driver - s - (read)</h3>
<p>Name of driver used by the interface, e.g., nl80211.</p>
</li>
<li>
<h3>CurrentBSS - o - (read)</h3>
<p>Path to D-Bus object representing BSS which %wpa_supplicant is associated with, or "/" if is not associated at all.</p>
</li>
<li>
<h3>CurrentNetwork - o - (read)</h3>
<p>Path to D-Bus object representing configured network which %wpa_supplicant uses at the moment, or "/" if doesn't use any.</p>
</li>
<li>
<h3>Blobs - as - (read)</h3>
<p>List of blobs names added to the Interface.</p>
</li>
<li>
<h3>BSSs - ao - (read)</h3>
<p>List of D-Bus objects paths representing BSSs known to the interface, i.e., scan results.</p>
</li>
<li>
<h3>Networks - ao - (read)</h3>
<p>List of D-Bus objects paths representing configured networks.</p>
</li>
<li>
<h3>FastReauth - b - (read/write)</h3>
<p>Identical to fast_reauth entry in %wpa_supplicant configuration file.</p>
</li>
<li>
<h3>ScanInterval - i - (read/write)</h3>
<p>Time (in seconds) between scans for a suitable AP. Must be >= 0.</p>
</li>
</ul>
\subsection dbus_interface_signals Signals
<ul>
<li>
<h3>ScanDone ( b : success )</h3>
<p>Scanning finished. </p>
<h4>Arguments</h4>
<dl>
<dt>s : success</dt>
<dd>Determines if scanning was successful. If so, results are available.</dd>
</dl>
</li>
<li>
<h3>BSSAdded ( o : BSS, a{sv} : properties )</h3>
<p>Interface became aware of a new BSS.</p>
<h4>Arguments</h4>
<dl>
<dt>o : BSS</dt>
<dd>A D-Bus path to an object representing the new BSS.</dd>
</dl>
<dl>
<dt>a{sv} : properties</dt>
<dd>A dictionary containing properties of added BSS.</dd>
</dl>
</li>
<li>
<h3>BSSRemoved ( o : BSS )</h3>
<p>BSS disappeared.</p>
<h4>Arguments</h4>
<dl>
<dt>o : BSS</dt>
<dd>A D-Bus path to an object representing the BSS.</dd>
</dl>
</li>
<li>
<h3>BlobAdded ( s : blobName )</h3>
<p>A new blob has been added to the interface.</p>
<h4>Arguments</h4>
<dl>
<dt>s : blobName</dt>
<dd>A name of the added blob.</dd>
</dl>
</li>
<li>
<h3>BlobRemoved ( s : blobName )</h3>
<p>A blob has been removed from the interface.</p>
<h4>Arguments</h4>
<dl>
<dt>s : blobName</dt>
<dd>A name of the removed blob.</dd>
</dl>
</li>
<li>
<h3>NetworkAdded ( o : network, a{sv} : properties )</h3>
<p>A new network has been added to the interface.</p>
<h4>Arguments</h4>
<dl>
<dt>o : network</dt>
<dd>A D-Bus path to an object representing the added network.</dd>
</dl>
<dl>
<dt>a{sv} : properties</dt>
<dd>A dictionary containing properties of added network.</dd>
</dl>
</li>
<li>
<h3>NetworkRemoved ( o : network )</h3>
<p>The network has been removed from the interface.</p>
<h4>Arguments</h4>
<dl>
<dt>o : network</dt>
<dd>A D-Bus path to an object representing the removed network.</dd>
</dl>
</li>
<li>
<h3>NetworkSelected ( o : network )</h3>
<p>The network has been selected.</p>
<h4>Arguments</h4>
<dl>
<dt>o : network</dt>
<dd>A D-Bus path to an object representing the selected network.</dd>
</dl>
</li>
<li>
<h3>PropertiesChanged ( a{sv} : properties )</h3>
<p>Some properties have changed.</p>
<h4>Arguments</h4>
<dl>
<dt>a{sv} : properties</dt>
<dd>A dictionary with pairs of properties names which have changed and theirs new values. Possible dictionary keys are: "ApScan", "Scanning", "State", "CurrentBSS", "CurrentNetwork"</dd>
</dl>
</li>
</ul>
\section dbus_wps fi.w1.wpa_supplicant1.Interface.WPS
Interface implemented by objects related to network interface added to
%wpa_supplicant, i.e., returned by fi.w1.wpa_supplicant1.CreateInterface.
\subsection dbus_wps_methods Methods
<ul>
<li>
<h3>Start ( a{sv} : args ) --> a{sv} : output</h3>
<p>Starts WPS configuration.</p>
<h4>Arguments</h4>
<dl>
<dt>a{sv} : args</dt>
<dd>
A dictionary with arguments used to start WPS configuration. The dictionary may contain the following entries:
<table>
<tr><th>Key</th><th>Value type</th><th>Description</th><th>Required</th>
<tr><td>Role</td><td>s</td><td>The device's role. Possible values are "enrollee" and "registrar".</td><td>Yes</td>
<tr><td>Type</td><td>s</td><td>WPS authentication type. Applies only for enrollee role. Possible values are "pin" and "pbc".</td><td>Yes, for enrollee role; otherwise no</td>
<tr><td>Pin</td><td>s</td><td>WPS Pin.</td><td>Yes, for registrar role; otherwise optional</td>
<tr><td>Bssid</td><td>ay</td><td></td><td>No</td>
</table>
</dd>
</dl>
<h4>Returns</h4>
<dl>
<dt>a{sv} : output</dt>
<dd>
<table>
<tr><th>Key</th><th>Value type</th><th>Description</th><th>Required</th>
<tr><td>Pin</td><td>s</td><td>Newly generated PIN, if not specified for enrollee role and pin authentication type.</td><td>No</td>
</table>
</dd>
</dl>
<h4>Possible errors</h4>
<dl>
<dt>fi.w1.wpa_supplicant1.UnknownError</dt>
<dd>Starting WPS configuration failed for an unknown reason.</dd>
<dt>fi.w1.wpa_supplicant1.InvalidArgs</dt>
<dd>Invalid entries were found in the passed argument.</dd>
</dl>
</li>
</ul>
\subsection dbus_wps_properties Properties
<ul>
<li>
<h3>ProcessCredentials - b - (read/write)</h3>
<p>Determines if the interface will process the credentials (credentials_processed configuration file parameter).</p>
</li>
</ul>
\subsection dbus_wps_signals Signals
<ul>
<li>
<h3>Event ( s : name, a{sv} : args )</h3>
<p>WPS event occurred.</p>
<h4>Arguments</h4>
<dl>
<dt>s : event</dt>
<dd>Event type. Possible values are: "success, "fail" and "m2d"</dd>
<dt>a{sv} : args</dt>
<dd>
Event arguments. Empty for success event, one entry ( "msg" : i ) for fail event and following entries for m2d event:
<table>
<tr><th>config_methods</th><th>Value type</th>
<tr><td>manufacturer</td><td>q</td>
<tr><td>model_name</td><td>ay</td>
<tr><td>model_number</td><td>ay</td>
<tr><td>serial_number</td><td>ay</td>
<tr><td>dev_name</td><td>ay</td>
<tr><td>primary_dev_type</td><td>ay</td>
<tr><td>config_error</td><td>q</td>
<tr><td>dev_password_id</td><td>q</td>
</table>
</dd>
</dl>
</li>
<li>
<h3>Credentials ( a{sv} : credentials )</h3>
<p>WPS credentials. Dictionary contains:</p>
<table>
<tr><th>Key</th><th>Value type</th><th>Description</th>
<tr><td>BSSID</td><td>ay</td><td></td>
<tr><td>SSID</td><td>s</td><td></td>
<tr><td>AuthType</td><td>as</td><td>Possible array elements: "open", "shared", "wpa-psk", "wpa-eap", "wpa2-eap", "wpa2-psk"</td>
<tr><td>EncrType</td><td>as</td><td>Possible array elements: "none", "wep", "tkip", "aes"</td>
<tr><td>Key</td><td>ay</td><td>Key data</td>
<tr><td>KeyIndex</td><td>u</td><td>Key index</td>
</table>
</li>
<li>
<h3>PropertiesChanged ( a{sv} : properties )</h3>
<p>Some properties have changed.</p>
<h4>Arguments</h4>
<dl>
<dt>a{sv} : properties</dt>
<dd>A dictionary with pairs of properties names which have changed and theirs new values. Possible dictionary keys are: "ProcessCredentials"</dd>
</dl>
</li>
</ul>
\section dbus_bss fi.w1.wpa_supplicant1.BSS
Interface implemented by objects representing a scanned BSSs, i.e.,
scan results.
\subsection dbus_bss_properties Properties
<ul>
<li>
<h3>BSSID - ay - (read)</h3>
<p>BSSID of the BSS.</p>
</li>
<li>
<h3>SSID - ay - (read)</h3>
<p>SSID of the BSS.</p>
</li>
<li>
<h3>WPA - a{sv} - (read)</h3>
<p>WPA information of the BSS. Empty dictionary indicates no WPA support. Dictionary entries are:</p>
<table>
<tr><td>KeyMgmt</td><td>as</td><td>Key management suite. Possible array elements: "wpa-psk", "wpa-eap", "wpa-none"</td>
<tr><td>Pairwise</td><td>as</td><td>Pairwise cipher suites. Possible array elements: "ccmp", "tkip"</td>
<tr><td>Group</td><td>s</td><td>Group cipher suite. Possible values are: "ccmp", "tkip", "wep104", "wep40"</td>
</table>
</li>
<li>
<h3>RSN - a{sv} - (read)</h3>
<p>RSN information of the BSS. Empty dictionary indicates no RSN support. Dictionary entries are:</p>
<table>
<tr><td>KeyMgmt</td><td>as</td><td>Key management suite. Possible array elements: "wpa-psk", "wpa-eap", "wpa-ft-psk", "wpa-ft-eap", "wpa-psk-sha256", "wpa-eap-sha256",</td>
<tr><td>Pairwise</td><td>as</td><td>Pairwise cipher suites. Possible array elements: "ccmp", "tkip"</td>
<tr><td>Group</td><td>s</td><td>Group cipher suite. Possible values are: "ccmp", "tkip", "wep104", "wep40"</td>
<tr><td>MgmtGroup</td><td>s</td><td>Mangement frames cipher suite. Possible values are: "aes128cmac"</td>
</table>
</li>
<li>
<h3>IEs - ay - (read)</h3>
<p>All IEs of the BSS as a chain of TLVs</p>
</li>
<li>
<h3>Privacy - b - (read)</h3>
<p>Indicates if BSS supports privacy.</p>
</li>
<li>
<h3>Mode - s - (read)</h3>
<p>Describes mode of the BSS. Possible values are: "ad-hoc" and "infrastructure".</p>
</li>
<li>
<h3>Frequency - q - (read)</h3>
<p>Frequency of the BSS in MHz.</p>
</li>
<li>
<h3>Rates - au - (read)</h3>
<p>Descending ordered array of rates supported by the BSS in bits per second.</p>
</li>
<li>
<h3>Signal - n - (read)</h3>
<p>Signal strength of the BSS.</p>
</li>
</ul>
\subsection dbus_bss_signals Signals
<ul>
<li>
<h3>PropertiesChanged ( a{sv} : properties )</h3>
<p>Some properties have changed.</p>
<h4>Arguments</h4>
<dl>
<dt>a{sv} : properties</dt>
<dd>A dictionary with pairs of properties names which have changed and theirs new values.</dd>
</dl>
</li>
</ul>
\section dbus_network fi.w1.wpa_supplicant1.Network
Interface implemented by objects representing configured networks,
i.e., returned by fi.w1.wpa_supplicant1.Interface.AddNetwork.
\subsection dbus_network_properties Properties
<ul>
<li>
<h3>Enabled - b - (read/write)</h3>
<p>Determines if the configured network is enabled or not.</p>
</li>
<li>
<h3>Properties - a{sv} - (read)</h3>
<p>Properties of the configured network. Dictionary contains entries from "network" block of %wpa_supplicant configuration file. All values are string type, e.g., frequency is "2437", not 2437.
</li>
</ul>
\subsection dbus_network_signals Signals
<ul>
<li>
<h3>PropertiesChanged ( a{sv} : properties )</h3>
<p>Some properties have changed.</p>
<h4>Arguments</h4>
<dl>
<dt>a{sv} : properties</dt>
<dd>A dictionary with pairs of properties names which have changed and theirs new values. Possible dictionary keys are: "Enabled"</dd>
</dl>
</li>
</ul>
*/
external/hostap/doc/directories.doxygen
Vendored
+90
View File
@@ -0,0 +1,90 @@
/**
\dir hostapd hostapd
hostapd-specific code for configuration, control interface, and AP
management.
\dir src/common Common functionality
This module includes IEEE 802.11, IEEE 802.1X, and WPA related
functionality that is shared between AP and station modes.
\dir src/crypto Cryptographical functionality and wrappers
This module defines crypto and tls interfaces to provide portability
layer for different crypto/TLS libraries. Wrappers for number of
libraries are also included here. In addition, internal implementation
of various crypto functions are provided as an alternative for an
external library and to extend some algorithms.
\dir src/drivers Driver wrappers
This directory includes the driver interface definition and all the
driver wrappers that can be used to interact with different drivers
without making rest of the software dependent on which particular
driver is used.
\dir src/eap_common Common EAP functionality for server and peer
\dir src/eap_peer EAP peer
\dir src/eap_server EAP server
\dir src/eapol_auth EAPOL authenticator
\dir src/eapol_supp EAPOL supplicant
\dir src/l2_packet Layer 2 packet interface
This module defines an interface for layer 2 (link layer) packet
sendinf and receiving. All the wrappers for supported mechanisms are
also included here. This is used to port packet access for new
operating systems without having to make rest of the source code
depend on which OS network stack is used.
\dir src/radius RADIUS
RADIUS module includes RADIUS message building and parsing
functionality and separate RADIUS client and server functions.
\dir src/rsn_supp IEEE 802.11 RSN and WPA supplicant
\dir src/tls Internal TLS server and client implementation
This module can be used as an alternative to using an external TLS
library.
\dir src/utils Utility functions
Independent set of helper functions that most other components
use. This includes portability wrappers and helpers for common tasks.
\dir src/wps Wi-Fi Protected Setup
This directory includes Wi-Fi Protected Setup functions for Registrar
(both internal in an AP and an External Registrar and
Enrollee. Minimal UPnP and HTTP functionality is also provided for the
functionality needed to implement Wi-Fi Protected Setup.
\dir wpa_supplicant %wpa_supplicant
%wpa_supplicant-specific code for configuration, control interface, and
client management.
*/
external/hostap/doc/doxygen.conf
Vendored
+1535
View File
File diff suppressed because it is too large Load Diff
external/hostap/doc/driver_wrapper.doxygen
Vendored
+180
View File
@@ -0,0 +1,180 @@
/**
\page driver_wrapper Driver wrapper implementation (driver.h, drivers.c)
All hardware and driver dependent functionality is in separate C files
that implement defined wrapper functions. Other parts
of the %wpa_supplicant are designed to be hardware, driver, and operating
system independent.
Driver wrappers need to implement whatever calls are used in the
target operating system/driver for controlling wireless LAN
devices. As an example, in case of Linux, these are mostly some glue
code and ioctl() calls and netlink message parsing for Linux Wireless
Extensions (WE). Since features required for WPA were added only recently to
Linux Wireless Extensions (in version 18), some driver specific code is used
in number of driver interface implementations. These driver dependent parts
can be replaced with generic code in driver_wext.c once the target driver
includes full support for WE-18. After that, all Linux drivers, at
least in theory, could use the same driver wrapper code.
A driver wrapper needs to implement some or all of the functions
defined in driver.h. These functions are registered by filling struct
wpa_driver_ops with function pointers. Hardware independent parts of
%wpa_supplicant will call these functions to control the driver/wlan
card. In addition, support for driver events is required. The event
callback function, wpa_supplicant_event(), and its parameters are
documented in driver.h. In addition, a pointer to the 'struct
wpa_driver_ops' needs to be registered in drivers.c file.
When porting to other operating systems, the driver wrapper should be
modified to use the native interface of the target OS. It is possible
that some extra requirements for the interface between the driver
wrapper and generic %wpa_supplicant code are discovered during porting
to a new operating system. These will be addressed on case by case
basis by modifying the interface and updating the other driver
wrappers for this. The goal is to avoid changing this interface
without very good reasons in order to limit the number of changes
needed to other wrappers and hardware independent parts of
%wpa_supplicant. When changes are required, recommended way is to
make them in backwards compatible way that allows existing driver
interface implementations to be compiled without any modification.
Generic Linux Wireless Extensions functions are implemented in
driver_wext.c. All Linux driver wrappers can use these when the kernel
driver supports the generic ioctl()s and wireless events. Driver
specific functions are implemented in separate C files, e.g.,
driver_hostap.c. These files need to define struct wpa_driver_ops
entry that will be used in wpa_supplicant.c when calling driver
functions. struct wpa_driver_ops entries are registered in drivers.c.
In general, it is likely to be useful to first take a look at couple
of driver interface examples before starting on implementing a new
one. driver_hostap.c and driver_wext.c include a complete
implementation for Linux drivers that use %wpa_supplicant-based control
of WPA IE and roaming. driver_ndis.c (with help from driver_ndis_.c)
is an example of a complete interface for Windows NDIS interface for
drivers that generate WPA IE themselves and decide when to roam. These
example implementations include full support for all security modes.
\section driver_req Driver requirements for WPA
WPA introduces new requirements for the device driver. At least some
of these need to be implemented in order to provide enough support for
%wpa_supplicant.
\subsection driver_tkip_ccmp TKIP/CCMP
WPA requires that the pairwise cipher suite (encryption algorithm for
unicast data packets) is TKIP or CCMP. These are new encryption
protocols and thus, the driver will need to be modified to support
them. Depending on the used wlan hardware, some parts of these may be
implemented by the hardware/firmware.
Specification for both TKIP and CCMP is available from IEEE (IEEE
802.11i amendment). Fully functional, hardware independent
implementation of both encryption protocols is also available in Host
AP driver (driver/modules/hostap_{tkip,ccmp}.c). In addition, Linux 2.6
kernel tree has generic implementations for WEP, TKIP, and CCMP that can
be used in Linux drivers.
The driver will also need to provide configuration mechanism to allow
user space programs to configure TKIP and CCMP. Linux Wireless Extensions
v18 added support for configuring these algorithms and
individual/non-default keys. If the target kernel does not include WE-18,
private ioctls can be used to provide similar functionality.
\subsection driver_roaming Roaming control and scanning support
%wpa_supplicant can optionally control AP selection based on the
information received from Beacon and/or Probe Response frames
(ap_scan=1 mode in configuration). This means that the driver should
support external control for scan process. In case of Linux, use of
new Wireless Extensions scan support (i.e., 'iwlist wlan0 scan') is
recommended. The current driver wrapper (driver_wext.c) uses this for
scan results.
Scan results must also include the WPA information element. Support for
this was added in WE-18. With older versions, a custom event can be used
to provide the full WPA IE (including element id and length) as a hex
string that is included in the scan results.
%wpa_supplicant needs to also be able to request the driver to
associate with a specific BSS. Current Host AP driver and matching
driver_hostap.c wrapper uses following sequence for this
request. Similar/identical mechanism should be usable also with other
drivers.
- set WPA IE for AssocReq with private ioctl
- set SSID with SIOCSIWESSID
- set channel/frequency with SIOCSIWFREQ
- set BSSID with SIOCSIWAP
(this last ioctl will trigger the driver to request association)
\subsection driver_wpa_ie WPA IE generation
%wpa_supplicant selects which cipher suites and key management suites
are used. Based on this information, it generates a WPA IE. This is
provided to the driver interface in the associate call. This does not
match with Windows NDIS drivers which generate the WPA IE
themselves.
%wpa_supplicant allows Windows NDIS-like behavior by providing the
selected cipher and key management suites in the associate call. If
the driver generates its own WPA IE and that differs from the one
generated by %wpa_supplicant, the driver has to inform %wpa_supplicant
about the used WPA IE (i.e., the one it used in (Re)Associate
Request). This notification is done using EVENT_ASSOCINFO event (see
driver.h). %wpa_supplicant is normally configured to use
ap_scan=2 mode with drivers that control WPA IE generation and roaming.
\subsection driver_events Driver events
%wpa_supplicant needs to receive event callbacks when certain events
occur (association, disassociation, Michael MIC failure, scan results
available, PMKSA caching candidate). These events and the callback
details are defined in driver.h (wpa_supplicant_event() function
and enum wpa_event_type).
On Linux, association and disassociation can use existing Wireless
Extensions event that is reporting new AP with SIOCGIWAP
event. Similarly, completion of a scan can be reported with SIOCGIWSCAN
event.
Michael MIC failure event was added in WE-18. Older versions of Wireless
Extensions will need to use a custom event. Host AP driver used a custom
event with following contents: MLME-MICHAELMICFAILURE.indication(keyid=#
broadcast/unicast addr=addr2). This is the recommended format until
the driver can be moved to use WE-18 mechanism.
\subsection driver_wext_summary Summary of Linux Wireless Extensions use
AP selection depends on ap_scan configuration:
ap_scan=1:
- %wpa_supplicant requests scan with SIOCSIWSCAN
- driver reports scan complete with wireless event SIOCGIWSCAN
- %wpa_supplicant reads scan results with SIOCGIWSCAN (multiple call if
a larget buffer is needed)
- %wpa_supplicant decides which AP to use based on scan results
- %wpa_supplicant configures driver to associate with the selected BSS
(SIOCSIWMODE, SIOCSIWGENIE, SIOCSIWAUTH, SIOCSIWFREQ,
SIOCSIWESSID, SIOCSIWAP)
ap_scan=2:
- %wpa_supplicant configures driver to associate with an SSID
(SIOCSIWMODE, SIOCSIWGENIE, SIOCSIWAUTH, SIOCSIWESSID)
After this, both modes use similar steps:
- optionally (or required for drivers that generate WPA/RSN IE for
(Re)AssocReq), driver reports association parameters (AssocReq IEs)
with wireless event IWEVASSOCREQIE (and optionally IWEVASSOCRESPIE)
- driver reports association with wireless event SIOCGIWAP
- %wpa_supplicant takes care of EAPOL frame handling (validating
information from associnfo and if needed, from scan results if WPA/RSN
IE from the Beacon frame is not reported through associnfo)
*/
external/hostap/doc/eap.doxygen
Vendored
+87
View File
@@ -0,0 +1,87 @@
/**
\page eap_peer_module EAP peer implementation
Extensible Authentication Protocol (EAP) is an authentication framework
defined in RFC 3748. %wpa_supplicant uses a separate code module for EAP
peer implementation. This module was designed to use only a minimal set
of direct function calls (mainly, to debug/event functions) in order for
it to be usable in other programs. The design of the EAP
implementation is based loosely on RFC 4137. The state machine is
defined in this RFC and so is the interface between the peer state
machine and methods. As such, this RFC provides useful information for
understanding the EAP peer implementation in %wpa_supplicant.
Some of the terminology used in EAP state machine is referring to
EAPOL (IEEE 802.1X), but there is no strict requirement on the lower
layer being IEEE 802.1X if EAP module is built for other programs than
%wpa_supplicant. These terms should be understood to refer to the
lower layer as defined in RFC 4137.
\section adding_eap_methods Adding EAP methods
Each EAP method is implemented as a separate module, usually as one C
file named eap_<name of the method>.c, e.g., eap_md5.c. All EAP
methods use the same interface between the peer state machine and
method specific functions. This allows new EAP methods to be added
without modifying the core EAP state machine implementation.
New EAP methods need to be registered by adding them into the build
(Makefile) and the EAP method registration list in the
eap_peer_register_methods() function of eap_methods.c. Each EAP
method should use a build-time configuration option, e.g., EAP_TLS, in
order to make it possible to select which of the methods are included
in the build.
EAP methods must implement the interface defined in eap_i.h. struct
eap_method defines the needed function pointers that each EAP method
must provide. In addition, the EAP type and name are registered using
this structure. This interface is based on section 4.4 of RFC 4137.
It is recommended that the EAP methods would use generic helper
functions, eap_msg_alloc() and eap_hdr_validate() when processing
messages. This allows code sharing and can avoid missing some of the
needed validation steps for received packets. In addition, these
functions make it easier to change between expanded and legacy EAP
header, if needed.
When adding an EAP method that uses a vendor specific EAP type
(Expanded Type as defined in RFC 3748, Chapter 5.7), the new method
must be registered by passing vendor id instead of EAP_VENDOR_IETF to
eap_peer_method_alloc(). These methods must not try to emulate
expanded types by registering a legacy EAP method for type 254. See
eap_vendor_test.c for an example of an EAP method implementation that
is implemented as an expanded type.
\section used_eap_library Using EAP implementation as a library
The Git repository has an eap_example directory that contains an
example showing how EAP peer and server code from %wpa_supplicant and
hostapd can be used as a library. The example program initializes both
an EAP server and an EAP peer entities and then runs through an
EAP-PEAP/MSCHAPv2 authentication.
eap_example_peer.c shows the initialization and glue code needed to
control the EAP peer implementation. eap_example_server.c does the
same for EAP server. eap_example.c is an example that ties in both the
EAP server and client parts to allow an EAP authentication to be
shown.
In this example, the EAP messages are passed between the server and
the peer are passed by direct function calls within the same process.
In practice, server and peer functionalities would likely reside in
separate devices and the EAP messages would be transmitted between the
devices based on an external protocol. For example, in IEEE 802.11
uses IEEE 802.1X EAPOL state machines to control the transmission of
EAP messages and WiMax supports optional PMK EAP authentication
mechanism that transmits EAP messages as defined in IEEE 802.16e.
The EAP library links in number of helper functions from src/utils and
src/crypto directories. Most of these are suitable as-is, but it may
be desirable to replace the debug output code in src/utils/wpa_debug.c
by dropping this file from the library and re-implementing the
functions there in a way that better fits in with the main
application.
*/
external/hostap/doc/eap_server.doxygen
Vendored
+56
View File
@@ -0,0 +1,56 @@
/**
\page eap_server_module EAP server implementation
Extensible Authentication Protocol (EAP) is an authentication framework
defined in RFC 3748. hostapd uses a separate code module for EAP server
implementation. This module was designed to use only a minimal set of
direct function calls (mainly, to debug/event functions) in order for
it to be usable in other programs. The design of the EAP
implementation is based loosely on RFC 4137. The state machine is
defined in this RFC and so is the interface between the server state
machine and methods. As such, this RFC provides useful information for
understanding the EAP server implementation in hostapd.
Some of the terminology used in EAP state machine is referring to
EAPOL (IEEE 802.1X), but there is no strict requirement on the lower
layer being IEEE 802.1X if EAP module is built for other programs than
%wpa_supplicant. These terms should be understood to refer to the
lower layer as defined in RFC 4137.
\section adding_eap_methods Adding EAP methods
Each EAP method is implemented as a separate module, usually as one C
file named eap_<name of the method>.c, e.g., eap_md5.c. All EAP
methods use the same interface between the server state machine and
method specific functions. This allows new EAP methods to be added
without modifying the core EAP state machine implementation.
New EAP methods need to be registered by adding them into the build
(Makefile) and the EAP method registration list in the
eap_server_register_methods() function of eap_methods.c. Each EAP
method should use a build-time configuration option, e.g., EAP_TLS, in
order to make it possible to select which of the methods are included
in the build.
EAP methods must implement the interface defined in eap_i.h. struct
eap_method defines the needed function pointers that each EAP method
must provide. In addition, the EAP type and name are registered using
this structure. This interface is based on section 4.4 of RFC 4137.
It is recommended that the EAP methods would use generic helper
functions, eap_msg_alloc() and eap_hdr_validate() when processing
messages. This allows code sharing and can avoid missing some of the
needed validation steps for received packets. In addition, these
functions make it easier to change between expanded and legacy EAP
header, if needed.
When adding an EAP method that uses a vendor specific EAP type
(Expanded Type as defined in RFC 3748, Chapter 5.7), the new method
must be registered by passing vendor id instead of EAP_VENDOR_IETF to
eap_server_method_alloc(). These methods must not try to emulate
expanded types by registering a legacy EAP method for type 254. See
eap_vendor_test.c for an example of an EAP method implementation that
is implemented as an expanded type.
*/
external/hostap/doc/hostapd.fig
Vendored
+264
View File
@@ -0,0 +1,264 @@
#FIG 3.2
Landscape
Center
Inches
Letter
100.00
Single
-2
1200 2
6 1875 4050 2925 4350
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
1875 4050 2925 4050 2925 4350 1875 4350 1875 4050
4 0 0 50 -1 0 12 0.0000 4 180 735 2025 4275 l2_packet\001
-6
6 4725 1200 5925 1500
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
4725 1200 5925 1200 5925 1500 4725 1500 4725 1200
4 0 0 50 -1 0 12 0.0000 4 135 1005 4800 1425 GUI frontend\001
-6
6 6000 2700 7200 3225
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
6000 2700 7200 2700 7200 3225 6000 3225 6000 2700
4 0 0 50 -1 0 12 0.0000 4 135 975 6075 2925 WPA/WPA2\001
4 0 0 50 -1 0 12 0.0000 4 135 1065 6075 3150 state machine\001
-6
6 6000 4950 7200 5475
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
6000 4950 7200 4950 7200 5475 6000 5475 6000 4950
4 0 0 50 -1 0 12 0.0000 4 135 360 6075 5175 EAP\001
4 0 0 50 -1 0 12 0.0000 4 135 1065 6075 5400 state machine\001
-6
6 4350 3900 5025 4425
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
4350 3900 5025 3900 5025 4425 4350 4425 4350 3900
4 0 0 50 -1 0 12 0.0000 4 105 420 4500 4125 event\001
4 0 0 50 -1 0 12 0.0000 4 180 315 4500 4350 loop\001
-6
6 4275 2550 5100 2850
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
4275 2550 5100 2550 5100 2850 4275 2850 4275 2550
4 0 0 50 -1 0 12 0.0000 4 135 450 4425 2775 ctrl i/f\001
-6
6 6000 3900 7200 4425
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
6000 3900 7200 3900 7200 4425 6000 4425 6000 3900
4 0 0 50 -1 0 12 0.0000 4 135 600 6075 4125 EAPOL\001
4 0 0 50 -1 0 12 0.0000 4 135 1065 6075 4350 state machine\001
-6
6 2775 3150 4050 3450
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
2775 3150 4050 3150 4050 3450 2775 3450 2775 3150
4 0 0 50 -1 0 12 0.0000 4 180 990 2925 3375 configuration\001
-6
6 3450 1200 4575 1500
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
3450 1200 4575 1200 4575 1500 3450 1500 3450 1200
4 0 0 50 -1 0 12 0.0000 4 180 870 3600 1425 hostapd_cli\001
-6
6 3525 7800 5775 8100
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
3525 7800 5775 7800 5775 8100 3525 8100 3525 7800
4 0 0 50 -1 0 12 0.0000 4 135 2145 3600 8025 kernel network device driver\001
-6
6 4275 6000 5100 6300
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
4275 6000 5100 6000 5100 6300 4275 6300 4275 6000
4 0 0 50 -1 0 12 0.0000 4 135 630 4350 6225 driver i/f\001
-6
6 8175 4725 9225 5025
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
8175 4725 9225 4725 9225 5025 8175 5025 8175 4725
4 0 0 50 -1 0 12 0.0000 4 135 735 8250 4950 EAP-TLS\001
-6
6 9300 4725 10350 5025
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
9300 4725 10350 4725 10350 5025 9300 5025 9300 4725
4 0 0 50 -1 0 12 0.0000 4 135 810 9375 4950 EAP-MD5\001
-6
6 8175 5100 9225 5400
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
8175 5100 9225 5100 9225 5400 8175 5400 8175 5100
4 0 0 50 -1 0 12 0.0000 4 135 885 8250 5325 EAP-PEAP\001
-6
6 9300 5100 10350 5400
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
9300 5100 10350 5100 10350 5400 9300 5400 9300 5100
4 0 0 50 -1 0 12 0.0000 4 135 840 9375 5325 EAP-TTLS\001
-6
6 8175 5475 9225 5775
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
8175 5475 9225 5475 9225 5775 8175 5775 8175 5475
4 0 0 50 -1 0 12 0.0000 4 135 780 8250 5700 EAP-GTC\001
-6
6 8175 5850 9225 6150
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
8175 5850 9225 5850 9225 6150 8175 6150 8175 5850
4 0 0 50 -1 0 12 0.0000 4 135 750 8250 6075 EAP-SIM\001
-6
6 8175 6225 9225 6525
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
8175 6225 9225 6225 9225 6525 8175 6525 8175 6225
4 0 0 50 -1 0 12 0.0000 4 135 765 8250 6450 EAP-PSK\001
-6
6 9300 5850 10350 6150
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
9300 5850 10350 5850 10350 6150 9300 6150 9300 5850
4 0 0 50 -1 0 12 0.0000 4 135 825 9375 6075 EAP-AKA\001
-6
6 9300 5475 10350 5775
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
9300 5475 10350 5475 10350 5775 9300 5775 9300 5475
4 0 0 50 -1 0 12 0.0000 4 135 795 9375 5700 EAP-PAX\001
-6
6 8175 6600 9675 6900
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
8175 6600 9675 6600 9675 6900 8175 6900 8175 6600
4 0 0 50 -1 0 12 0.0000 4 135 1365 8250 6825 EAP-MSCHAPv2\001
-6
6 8700 3450 9375 3750
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
8700 3450 9375 3450 9375 3750 8700 3750 8700 3450
4 0 0 50 -1 0 12 0.0000 4 150 480 8775 3675 crypto\001
-6
6 9600 3450 10275 3750
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
9600 3450 10275 3450 10275 3750 9600 3750 9600 3450
4 0 0 50 -1 0 12 0.0000 4 135 315 9750 3675 TLS\001
-6
6 6000 5775 7200 6300
6 6000 5775 7200 6300
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
6000 5775 7200 5775 7200 6300 6000 6300 6000 5775
4 0 0 50 -1 0 12 0.0000 4 135 690 6075 6000 RADIUS\001
-6
4 0 0 50 -1 0 12 0.0000 4 90 480 6075 6225 server\001
-6
6 8100 2250 8925 2775
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
8100 2250 8925 2250 8925 2775 8100 2775 8100 2250
4 0 0 50 -1 0 12 0.0000 4 135 690 8175 2475 RADIUS\001
4 0 0 50 -1 0 12 0.0000 4 135 420 8175 2700 client\001
-6
6 3150 5475 4425 5775
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
3150 5475 4425 5475 4425 5775 3150 5775 3150 5475
4 0 0 50 -1 0 12 0.0000 4 135 990 3300 5700 driver events\001
-6
6 1950 5550 2625 6075
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
1950 5550 2625 5550 2625 6075 1950 6075 1950 5550
4 0 0 50 -1 0 12 0.0000 4 135 540 2025 5775 Station\001
4 0 0 50 -1 0 12 0.0000 4 135 375 2025 6000 table\001
-6
6 1875 4725 2925 5250
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
1875 4725 2925 4725 2925 5250 1875 5250 1875 4725
4 0 0 50 -1 0 12 0.0000 4 135 960 1950 4950 IEEE 802.11\001
4 0 0 50 -1 0 12 0.0000 4 135 555 1950 5175 MLME\001
-6
2 1 1 1 0 7 50 -1 -1 3.000 0 0 -1 0 0 2
1275 4200 1875 4200
2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
4500 2550 3900 1500
2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
4800 2550 5400 1500
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
2925 4200 4350 4200
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
5025 3900 6000 3000
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
5025 4200 6000 4200
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
4650 6000 4650 4425
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
6600 4425 6600 4950
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
6600 3225 6600 3900
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
7200 5250 8100 5250
2 1 0 1 2 7 50 -1 -1 0.000 0 0 -1 0 0 2
9075 4425 9075 3750
2 1 0 1 2 7 50 -1 -1 0.000 0 0 -1 0 0 2
7200 3000 8700 3525
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
4650 3900 4650 2850
2 1 0 1 2 7 50 -1 -1 0.000 0 0 -1 0 0 2
7200 4125 8700 3675
2 1 0 1 2 7 50 -1 -1 0.000 0 0 -1 0 0 2
6000 4350 5025 6000
2 1 0 1 2 7 50 -1 -1 0.000 0 0 -1 0 0 2
6000 3150 4875 6000
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
1500 2100 10800 2100 10800 7500 1500 7500 1500 2100
2 1 0 1 2 7 50 -1 -1 0.000 0 0 -1 0 0 2
9900 4425 9900 3750
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 1
4350 3900
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
4350 3900 4050 3450
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
4350 4425 4050 5475
2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
2250 7200 4200 7800
2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
7200 7200 5100 7800
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
2775 6900 3675 6900 3675 7200 2775 7200 2775 6900
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
3750 6900 4650 6900 4650 7200 3750 7200 3750 6900
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 4
2250 6900 2250 6600 7200 6600 7200 6900
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
3225 6900 3225 6600
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
4200 6900 4200 6600
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
5175 6900 5175 6600
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
6150 6900 6150 6600
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
4650 6600 4650 6300
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
1800 6900 2700 6900 2700 7200 1800 7200 1800 6900
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
4725 6900 5625 6900 5625 7200 4725 7200 4725 6900
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
5700 6900 6600 6900 6600 7200 5700 7200 5700 6900
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
6675 6900 7800 6900 7800 7200 6675 7200 6675 6900
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
8100 6975 10425 6975 10425 4425 8100 4425 8100 6975
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
6600 5475 6600 5775
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
5025 4425 6000 5775
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 3
4800 3900 5925 2550 8100 2550
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
7200 3900 8475 2775
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
9450 2250 10425 2250 10425 2775 9450 2775 9450 2250
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
8925 2475 9450 2475
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
2325 5550 2325 5250
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
2925 4950 4350 4275
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 3
2850 4725 5775 2400 8100 2400
4 0 0 50 -1 0 12 0.0000 4 135 915 375 3975 EAPOL and\001
4 0 0 50 -1 0 12 0.0000 4 180 630 375 4200 pre-auth\001
4 0 0 50 -1 0 12 0.0000 4 180 810 375 4425 ethertypes\001
4 0 0 50 -1 0 12 0.0000 4 135 1050 375 4650 from/to kernel\001
4 0 0 50 -1 0 12 0.0000 4 135 1920 3675 1875 frontend control interface\001
4 0 0 50 -1 2 14 0.0000 4 195 720 1637 2371 hostapd\001
4 0 0 50 -1 0 12 0.0000 4 180 600 3825 7125 prism54\001
4 0 0 50 -1 0 12 0.0000 4 180 510 1875 7125 hostap\001
4 0 0 50 -1 0 12 0.0000 4 135 600 2850 7125 madwifi\001
4 0 0 50 -1 0 12 0.0000 4 135 270 4800 7125 bsd\001
4 0 0 50 -1 0 12 0.0000 4 105 300 6750 7125 test\001
4 0 0 50 -1 0 12 0.0000 4 135 420 5775 7125 wired\001
4 0 0 50 -1 0 12 0.0000 4 135 1050 8700 4650 EAP methods\001
4 0 0 50 -1 0 12 0.0000 4 135 690 9525 2475 RADIUS\001
4 0 0 50 -1 0 12 0.0000 4 180 825 9525 2700 accounting\001
external/hostap/doc/hostapd_ctrl_iface.doxygen
Vendored
+66
View File
@@ -0,0 +1,66 @@
/**
\page hostapd_ctrl_iface_page hostapd control interface
hostapd implements a control interface that can be used by
external programs to control the operations of the hostapd
daemon and to get status information and event notifications. There is
a small C library, in a form of a single C file, wpa_ctrl.c, that
provides helper functions to facilitate the use of the control
interface. External programs can link this file into them and then use
the library functions documented in wpa_ctrl.h to interact with
%wpa_supplicant. This library can also be used with C++. hostapd_cli.c
is an example program using this library.
There are multiple mechanisms for inter-process communication. For
example, Linux version of hostapd is using UNIX domain sockets for the
control interface. The use of the functions defined in wpa_ctrl.h can
be used to hide the details of the used IPC from external programs.
\section using_ctrl_iface Using the control interface
External programs, e.g., a GUI or a configuration utility, that need to
communicate with hostapd should link in wpa_ctrl.c. This
allows them to use helper functions to open connection to the control
interface with wpa_ctrl_open() and to send commands with
wpa_ctrl_request().
hostapd uses the control interface for two types of communication:
commands and unsolicited event messages. Commands are a pair of
messages, a request from the external program and a response from
hostapd. These can be executed using wpa_ctrl_request().
Unsolicited event messages are sent by hostapd to the control
interface connection without specific request from the external program
for receiving each message. However, the external program needs to
attach to the control interface with wpa_ctrl_attach() to receive these
unsolicited messages.
If the control interface connection is used both for commands and
unsolicited event messages, there is potential for receiving an
unsolicited message between the command request and response.
wpa_ctrl_request() caller will need to supply a callback, msg_cb,
for processing these messages. Often it is easier to open two
control interface connections by calling wpa_ctrl_open() twice and
then use one of the connections for commands and the other one for
unsolicited messages. This way command request/response pairs will
not be broken by unsolicited messages. wpa_cli is an example of how
to use only one connection for both purposes and wpa_gui demonstrates
how to use two separate connections.
Once the control interface connection is not needed anymore, it should
be closed by calling wpa_ctrl_close(). If the connection was used for
unsolicited event messages, it should be first detached by calling
wpa_ctrl_detach().
\section ctrl_iface_cmds Control interface commands
Following commands can be used with wpa_ctrl_request():
\subsection ctrl_iface_PING PING
This command can be used to test whether hostapd is replying
to the control interface commands. The expected reply is \c PONG if the
connection is open and hostapd is processing commands.
*/
external/hostap/doc/mainpage.doxygen
Vendored
+95
View File
@@ -0,0 +1,95 @@
/**
\mainpage Developers' documentation for wpa_supplicant and hostapd
The goal of this documentation and comments in the source code is to
give enough information for other developers to understand how
%wpa_supplicant and hostapd have been implemented, how they can be
modified, how new drivers can be supported, and how the source code
can be ported to other operating systems. If any information is
missing, feel free to contact Jouni Malinen <j@w1.fi> for more
information. Contributions as patch files are also very welcome at the
same address. Please note that this software is licensed under the
BSD license (the one with advertisement clause removed). All
contributions to %wpa_supplicant and hostapd are expected to use
compatible licensing terms.
The source code and read-only access to the combined %wpa_supplicant
and hostapd Git repository is available from the project home page at
http://w1.fi/wpa_supplicant/. This developers' documentation is also
available as a PDF file from
http://w1.fi/wpa_supplicant/wpa_supplicant-devel.pdf .
\section _wpa_supplicant wpa_supplicant
%wpa_supplicant is a WPA Supplicant for Linux, BSD and Windows with
support for WPA and WPA2 (IEEE 802.11i / RSN). Supplicant is the IEEE
802.1X/WPA component that is used in the client stations. It
implements key negotiation with a WPA Authenticator and it can optionally
control roaming and IEEE 802.11 authentication/association of the wlan
driver.
The design goal for %wpa_supplicant was to use hardware, driver, and
OS independent, portable C code for all WPA functionality. The source
code is divided into separate C files as shown on the \ref
code_structure "code structure page". All hardware/driver specific
functionality is in separate files that implement a \ref
driver_wrapper "well-defined driver API". Information about porting
to different target boards and operating systems is available on
the \ref porting "porting page".
EAPOL (IEEE 802.1X) state machines are implemented as a separate
module that interacts with \ref eap_peer_module "EAP peer implementation".
In addition to programs aimed at normal production use,
%wpa_supplicant source tree includes number of \ref testing_tools
"testing and development tools" that make it easier to test the
programs without having to setup a full test setup with wireless
cards. These tools can also be used to implement automatic test
suites.
%wpa_supplicant implements a
\ref ctrl_iface_page "control interface" that can be used by
external programs to control the operations of the %wpa_supplicant
daemon and to get status information and event notifications. There is
a small C library that provides helper functions to facilitate the use of the
control interface. This library can also be used with C++.
\image html _wpa_supplicant.png "wpa_supplicant modules"
\image latex _wpa_supplicant.eps "wpa_supplicant modules" width=15cm
\section _hostapd hostapd
hostapd includes IEEE 802.11 access point management (authentication /
association), IEEE 802.1X/WPA/WPA2 Authenticator, EAP server, and
RADIUS authentication server functionality. It can be build with
various configuration option, e.g., a standalone AP management
solution or a RADIUS authentication server with support for number of
EAP methods.
The design goal for hostapd was to use hardware, driver, and
OS independent, portable C code for all WPA functionality. The source
code is divided into separate C files as shown on the \ref
code_structure "code structure page". All hardware/driver specific
functionality is in separate files that implement a \ref
driver_wrapper "well-defined driver API". Information about porting
to different target boards and operating systems is available on
the \ref porting "porting page".
EAPOL (IEEE 802.1X) state machines are implemented as a separate
module that interacts with \ref eap_server_module "EAP server implementation".
Similarly, RADIUS authentication server is in its own separate module.
Both IEEE 802.1X and RADIUS authentication server can use EAP server
functionality.
hostapd implements a \ref hostapd_ctrl_iface_page "control interface"
that can be used by external programs to control the operations of the
hostapdt daemon and to get status information and event notifications.
There is a small C library that provides helper functions to facilitate
the use of the control interface. This library can also be used with
C++.
\image html hostapd.png "hostapd modules"
\image latex hostapd.eps "hostapd modules" width=15cm
*/
external/hostap/doc/p2p.doxygen
Vendored
+498
View File
@@ -0,0 +1,498 @@
/**
\page p2p Wi-Fi Direct - P2P module
Wi-Fi Direct functionality is implemented any many levels in the WLAN
stack from low-level driver operations to high-level GUI design. This
document covers the parts that can be user by %wpa_supplicant. However,
it should be noted that alternative designs are also possible, so some
of the functionality may reside in other components in the system.
The driver (or WLAN firmware/hardware) is expected to handle low-level
operations related to P2P Power Management and channel scheduling. In
addition, support for virtual network interface and data frame
processing is done inside the driver. Configuration for these
low-level operations is defined in the driver interface:
src/drivers/driver.h. This defines both the commands and events used to
interact with the driver.
P2P module implements higher layer functionality for management P2P
groups. It takes care of Device Discovery, Service Discovery, Group
Owner Negotiation, P2P Invitation. In addition, it maintains
information about neighboring P2P Devices. This module could be used
in designs that do not use %wpa_supplicant and it could also reside
inside the driver/firmware component. P2P module API is defined in
src/p2p/p2p.h.
Provisioning step of Group Formation is implemented using WPS
(src/wps/wps.h).
%wpa_supplicant includes code in interact with both the P2P module
(wpa_supplicant/p2p_supplicant.c) and WPS
(wpa_supplicant/wps_supplicant.c). The driver operations are passed
through these files, i.e., core P2P or WPS code does not interact
directly with the driver interface.
\section p2p_arch P2P architecture
P2P functionality affects many areas of the system architecture. This
section shows couple of examples on the location of main P2P
components. In the diagrams below, green arrows are used to show
communication paths from the P2P module to upper layer management
functionality and all the way to a GUI that user could use to manage
P2P connections. Blue arrows show the path taken for lower layer
operations. Glue code is used to bind the P2P module API to the rest
of the system to provide access both towards upper and lower layer
functionality.
\subsection p2p_arch_mac80211 P2P architecture with Linux/mac80211/ath9k
An architecture where the P2P module resides inside the
%wpa_supplicant process is used with Linux mac80211-based drivers,
e.g., ath9k. The following diagram shows the main components related
to P2P functionality in such an architecture.
\image html p2p_arch.png "P2P module within wpa_supplicant"
\image latex p2p_arch.eps "P2P module within wpa_supplicant" width=15cm
\subsection p2p_arch_umac P2P architecture with UMAC
The following diagram shows the main components related to P2P
functionality in an architecture where the P2P module resides inside
the kernel IEEE 802.11 stack (UMAC in the figure).
\image html p2p_arch2.png "P2P module in kernel
\image latex p2p_arch2.eps "P2P module in kernel" width=15cm
\section p2p_module P2P module
P2P module manages discovery and group formation with a single state
machine, i.e., only a single operation per device can be in progress
at any given time. The following diagram describes the P2P state
machine. For clarity, it does not include state transitions on
operation timeouts to the IDLE state. The states that are marked with
dotted ellipse are listed for clarity to describe the protocol
functionality for Device Discovery phase, but are not used in the
implementation (the SEARCH state is used to manage the initial Scan
and the alternating Listen and Search states within Find).
\image html p2p_sm.png "P2P module state machine"
\image latex p2p_sm.eps "P2P module state machine" width=15cm
\subsection p2p_module_api P2P module API
P2P module API is defined in src/p2p/p2p.h. The API consists of
functions for requesting operations and for providing event
notifications. Similar set of callback functions are configured with
struct p2p_config to provide callback functions that P2P module can
use to request operations and to provide event notifications. In
addition, there are number of generic helper functions that can be
used for P2P related operations.
These are the main functions for an upper layer management entity to
request P2P operations:
- p2p_find()
- p2p_stop_find()
- p2p_listen()
- p2p_connect()
- p2p_reject()
- p2p_prov_disc_req()
- p2p_sd_request()
- p2p_sd_cancel_request()
- p2p_sd_response()
- p2p_sd_service_update()
- p2p_invite()
These are the main callback functions for P2P module to provide event
notifications to the upper layer management entity:
- p2p_config::dev_found()
- p2p_config::go_neg_req_rx()
- p2p_config::go_neg_completed()
- p2p_config::sd_request()
- p2p_config::sd_response()
- p2p_config::prov_disc_req()
- p2p_config::prov_disc_resp()
- p2p_config::invitation_process()
- p2p_config::invitation_received()
- p2p_config::invitation_result()
The P2P module uses following functions to request lower layer driver
operations:
- p2p_config::p2p_scan()
- p2p_config::send_probe_resp()
- p2p_config::send_action()
- p2p_config::send_action_done()
- p2p_config::start_listen()
- p2p_config::stop_listen()
Events from lower layer driver operations are delivered to the P2P
module with following functions:
- p2p_probe_req_rx()
- p2p_rx_action()
- p2p_scan_res_handler()
- p2p_scan_res_handled()
- p2p_send_action_cb()
- p2p_listen_cb()
In addition to the per-device state, the P2P module maintains
per-group state for group owners. This is initialized with a call to
p2p_group_init() when a group is created and deinitialized with
p2p_group_deinit(). The upper layer GO management entity uses
following functions to interact with the P2P per-group state:
- p2p_group_notif_assoc()
- p2p_group_notif_disassoc()
- p2p_group_notif_formation_done()
- p2p_group_match_dev_type()
The P2P module will use following callback function to update P2P IE
for GO Beacon and Probe Response frames:
- p2p_group_config::ie_update()
\section p2p_driver P2P driver operations (low-level interface)
The following driver wrapper functions are needed for P2P in addition
to the standard station/AP mode operations when the P2P module resides
within %wpa_supplicant:
- wpa_driver_ops::if_add()
- wpa_driver_ops::if_remove()
- wpa_driver_ops::alloc_interface_addr()
- wpa_driver_ops::release_interface_addr()
- wpa_driver_ops::remain_on_channel()
- wpa_driver_ops::cancel_remain_on_channel()
- wpa_driver_ops::send_action()
- wpa_driver_ops::probe_req_report()
- wpa_driver_ops::disable_11b_rates()
The following driver wrapper events are needed for P2P in addition to
the standard station/AP mode events when the P2P module resides within
%wpa_supplicant:
- wpa_event_type::EVENT_RX_ACTION
- wpa_event_type::EVENT_REMAIN_ON_CHANNEL
- wpa_event_type::EVENT_CANCEL_REMAIN_ON_CHANNEL
- wpa_event_type::EVENT_RX_PROBE_REQ
The following driver wrapper functions are needed for P2P in addition
to the standard station/AP mode operations when the P2P module resides
in the driver or firmware:
- wpa_driver_ops::if_add()
- wpa_driver_ops::if_remove()
- wpa_driver_ops::alloc_interface_addr()
- wpa_driver_ops::release_interface_addr()
- wpa_driver_ops::disable_11b_rates()
- wpa_driver_ops::p2p_find()
- wpa_driver_ops::p2p_stop_find()
- wpa_driver_ops::p2p_listen()
- wpa_driver_ops::p2p_connect()
- wpa_driver_ops::p2p_reject()
- wpa_driver_ops::wps_success_cb()
- wpa_driver_ops::p2p_group_formation_failed()
- wpa_driver_ops::p2p_set_params()
The following driver wrapper events are needed for P2P in addition to
the standard station/AP mode events when the P2P module resides in the
driver or firmware:
- wpa_event_type::EVENT_P2P_DEV_FOUND
- wpa_event_type::EVENT_P2P_GO_NEG_REQ_RX
- wpa_event_type::EVENT_P2P_GO_NEG_COMPLETED
\section p2p_go_neg P2P device discovery and group formation
This section shows an example sequence of operations that can be used
to implement P2P device discovery and group formation. The function
calls are described based on the P2P module API. The exact design for
the glue code outside the P2P module depends on the architecture used
in the system.
An upper layer management entity starts P2P device discovery by
calling p2p_find(). The P2P module start the discovery by requesting a
full scan to be completed by calling p2p_config::p2p_scan(). Results
from the scan will be reported by calling p2p_scan_res_handler() and
after last result, the scan result processing is terminated with a
call to p2p_scan_res_handled(). The P2P peers that are found during
the full scan are reported with the p2p_config::dev_found() callback.
After the full scan, P2P module start alternating between Listen and
Search states until the device discovery operation times out or
terminated, e.g., with a call to p2p_stop_find().
When going into the Listen state, the P2P module requests the driver
to be configured to be awake on the listen channel with a call to
p2p_config::start_listen(). The glue code using the P2P module may
implement this, e.g., by using remain-on-channel low-level driver
functionality for off-channel operation. Once the driver is available
on the requested channel, notification of this is delivered by calling
p2p_listen_cb(). The Probe Request frames that are received during the
Listen period are delivered to the P2P module by calling
p2p_config::p2p_probe_req_rx() and P2P module request a response to
these to be sent by using p2p_config::send_probe_resp() callback
function. If a group owner negotiation from another P2P device is
received during the device discovery phase, that is indicated to the
upper layer code with the p2p_config::go_neg_req_tx() callback.
The Search state is implemented by using the normal scan interface,
i.e., the P2P module will call p2p_config::p2p_scan() just like in the
full scan phase described. Similarly, scan results from the search
operation will be delivered to the P2P module using the
p2p_scan_res_handler() and p2p_scan_res_handled() functions.
Once the upper layer management entity has found a peer with which it
wants to connect by forming a new group, it initiates group owner
negotiation by calling p2p_connect(). Before doing this, the upper
layer code is responsible for asking the user to provide the PIN to be
used during the provisioning step with the peer or the push button
press for PBC mode. The glue code will need to figure out the intended
interface address for the group before group owner negotiation can be
started.
Optional Provision Discovery mechanism can be used to request the peer
to display a PIN for the local device to enter (and vice versa). Upper
layer management entity can request the specific mechanism by calling
p2p_prov_disc_req(). The response to this will be reported with the
p2p_config::prov_disc_resp() callback. If the peer device started
Provision Discovery, an accepted request will be reported with the
p2p_config::prov_disc_req() callback. The P2P module will
automatically accept the Provision Discovery for display and keypad
methods, but it is up to the upper layer manegement entity to actually
generate the PIN and to configure it with following p2p_connect() call
to actually authorize the connection.
The P2P module will use p2p_config::send_action() callback to request
lower layer code to transmit an Action frame during group owner
negotiation. p2p_send_action_cb() is used to report the result of
transmission. If the peer is not reachable, the P2P module will try to
find it by alternating between Action frame send and Listen
states. The Listen state for this phase will be used similarly to the
Listen state during device discovery as described above.
Once the group owner negotiation has been completed, its results will
be reported with the p2p_config::go_neg_completed() callback. The
upper layer management code or the glue code using the P2P module API
is responsible for creating a new group interface and starting
provisioning step at this point by configuring WPS Registrar or
Enrollee functionality based on the reported group owner negotiation
results. The upper layer code is also responsible for timing out WPS
provisioning if it cannot be completed in 15 seconds.
Successful completion of the WPS provisioning is reported with a call
to p2p_wps_success_cb(). The P2P module will clear its group formation
state at this point and allows new group formation attempts to be
started. The upper layer management code is responsible for configuring
the GO to accept associations from devices and the client to connect to
the GO with the provisioned credentials. GO is also responsible for
calling p2p_group_notif_formation_done() as described below.
If the WPS provisioning step fails or times out, this is reported with
a call to p2p_group_formation_failed(). The P2P module will clear its
group formation state at this point and allows new group formation
attempts to be started. The upper layer management code is responsible
for removing the group interface for the failed group.
\section p2p_sd P2P service discovery
P2P protocol includes service discovery functionality that can be used
to discover which services are provided by the peers before forming a
group. This leverages the Generic Advertisement Service (GAS) protocol
from IEEE 802.11u and P2P vendor-specific contents inside the Native
GAS messages.
The P2P module takes care of GAS encapsulation, fragmentation, and
actual transmission and reception of the Action frames needed for
service discovery. The user of the P2P module is responsible for
providing P2P specific Service Request TLV(s) for queries and Service
Response TLV(s) for responses.
\subsection p2p_sd_query Quering services of peers
Service discovery is implemented by processing pending queries as a
part of the device discovery phase. p2p_sd_request() function is used
to schedule service discovery queries to a specific peer or to all
discovered peers. p2p_sd_cancel_request() can be used to cancel a
scheduled query. Queries that are specific to a single peer will be
removed automatically after the response has been received.
After the service discovery queries have been queued, device discovery
is started with a call to p2p_find(). The pending service discovery
queries are then sent whenever a peer is discovered during the find
operation. Responses to the queries will be reported with the
p2p_config::sd_response() callback.
\subsection p2p_sd_response Replying to service discovery queries from peers
The received service discovery requests will be indicated with the
p2p_config::sd_request() callback. The response to the query is sent
by calling p2p_sd_response().
\subsection p2p_sd_indicator Service update indicator
P2P service discovery provides a mechanism to notify peers about
changes in available services. This works by incrementing Service
Update Indicator value whenever there is a change in the
services. This value is included in all SD request and response
frames. The value received from the peers will be included in the
p2p_config::sd_request() and p2p_config::sd_response() callbacks. The
value to be sent to the peers is incremented with a call to
p2p_sd_service_update() whenever availibility of the local services
changes.
\section p2p_go P2P group owner
This section describes how P2P module can be used for managing
per-group information in a group owner. The function calls are
described based on the P2P module API. The exact design for the glue
code outside the P2P module depends on the architecture used in the
system.
When a P2P group interface is created in group owner role, per-group
data is initialized with p2p_group_init(). This call provides a
pointer to the per-device P2P module context and configures the
per-group operation. The configured p2p_group_config::ie_update()
callback is used to set the initial P2P IE for Beacon and Probe
Response frames in the group owner. The AP mode implementation may use
this information to add IEs into the frames.
Once the group formation has been completed (or if it is skipped in
case of manual group setup), p2p_group_notif_formation_done() is
called. This will allow the P2P module to update the P2P IE for
Beacon and Probe Response frames.
The SME/MLME code that managements IEEE 802.11 association processing
needs to inform P2P module whenever a P2P client associates or
disassociates with the group. This is done by calling
p2p_group_notif_assoc() and p2p_group_notif_disassoc(). The P2P module
manages a list of group members and updates the P2P Group Information
subelement in the P2P IE based on the information from the P2P
clients. The p2p_group_config::ie_update() callback is used whenever
the P2P IE in Probe Response frames needs to be changed.
The SME/MLME code that takes care of replying to Probe Request frames
can use p2p_group_match_dev_type() to check whether the Probe Request
frame request a reply only from groups that include a specific device
type in one of the clients or GO. A match will be reported if the
Probe Request does not request a specific device type, so this
function can be used to filter or received Probe Request frames and
only the ones that result in non-zero return value need to be replied.
When the P2P group interface for GO role is removed,
p2p_group_deinit() is used to deinitialize the per-group P2P module
state.
\section p2p_ctrl_iface P2P control interface
%wpa_supplicant \ref ctrl_iface_page "control interface" can be used
to manage P2P functionality from an external program (e.g., a GUI or a
system configuration manager). This interface can be used directly
through the control interface backend mechanism (e.g., local domain
sockets on Linux) or with help of wpa_cli (e.g., from a script).
The following P2P-related commands are available:
- \ref ctrl_iface_P2P_FIND P2P_FIND
- \ref ctrl_iface_P2P_STOP_FIND P2P_STOP_FIND
- \ref ctrl_iface_P2P_CONNECT P2P_CONNECT
- \ref ctrl_iface_P2P_LISTEN P2P_LISTEN
- \ref ctrl_iface_P2P_GROUP_REMOVE P2P_GROUP_REMOVE
- \ref ctrl_iface_P2P_GROUP_ADD P2P_GROUP_ADD
- \ref ctrl_iface_P2P_PROV_DISC P2P_PROV_DISC
- \ref ctrl_iface_P2P_SERV_DISC_REQ P2P_SERV_DISC_REQ
- \ref ctrl_iface_P2P_SERV_DISC_CANCEL_REQ P2P_SERV_DISC_CANCEL_REQ
- \ref ctrl_iface_P2P_SERV_DISC_RESP P2P_SERV_DISC_RESP
- \ref ctrl_iface_P2P_SERVICE_UPDATE P2P_SERVICE_UPDATE
- \ref ctrl_iface_P2P_SERV_DISC_EXTERNAL P2P_SERV_DISC_EXTERNAL
- \ref ctrl_iface_P2P_REJECT P2P_REJECT
- \ref ctrl_iface_P2P_INVITE P2P_INVITE
The following P2P-related events are used:
- \ref ctrl_iface_event_P2P_EVENT_DEVICE_FOUND P2P-DEVICE-FOUND
- \ref ctrl_iface_event_P2P_EVENT_GO_NEG_REQUEST P2P-GO-NEG-REQUEST
- \ref ctrl_iface_event_P2P_EVENT_GO_NEG_SUCCESS P2P-GO-NEG-SUCCESS
- \ref ctrl_iface_event_P2P_EVENT_GO_NEG_FAILURE P2P-GO-NEG-FAILURE
- \ref ctrl_iface_event_P2P_EVENT_GROUP_FORMATION_SUCCESS P2P-GROUP-FORMATION-SUCCESS
- \ref ctrl_iface_event_P2P_EVENT_GROUP_FORMATION_FAILURE P2P-GROUP-FORMATION-FAILURE
- \ref ctrl_iface_event_P2P_EVENT_GROUP_STARTED P2P-GROUP-STARTED
- \ref ctrl_iface_event_P2P_EVENT_GROUP_REMOVED P2P-GROUP-REMOVED
- \ref ctrl_iface_event_P2P_EVENT_PROV_DISC_SHOW_PIN P2P-PROV-DISC-SHOW-PIN
- \ref ctrl_iface_event_P2P_EVENT_PROV_DISC_ENTER_PIN P2P-PROV-DISC-ENTER-PIN
- \ref ctrl_iface_event_P2P_EVENT_SERV_DISC_REQ P2P-SERV-DISC-REQ
- \ref ctrl_iface_event_P2P_EVENT_SERV_DISC_RESP P2P-SERV-DISC-RESP
- \ref ctrl_iface_event_P2P_EVENT_INVITATION_RECEIVED P2P-INVITATION-RECEIVED
- \ref ctrl_iface_event_P2P_EVENT_INVITATION_RESULT P2P-INVITATION-RESULT
\subsection p2p_wpa_gui GUI example (wpa_gui)
wpa_gui has an example implementation of a GUI that could be used to
manage P2P operations. The P2P related functionality is contained
mostly in wpa_supplicant/wpa_gui-qt4/peers.cpp and it shows how the
control interface commands and events can be used.
\subsection p2p_wpa_cli wpa_cli example
wpa_cli can be used to control %wpa_supplicant in interactive
mode. The following sessions show examples of commands used for
device discovery and group formation. The lines starting with "> " are
commands from the user (followed by command result indication) and
lines starting with "<2>" are event messages from %wpa_supplicant.
P2P device "Wireless Client":
\verbatim
> p2p_find
OK
> <2>P2P-DEVICE-FOUND 02:40:61:c2:f3:b7 p2p_dev_addr=02:40:61:c2:f3:b7
pri_dev_type=1-0050F204-1 name='Wireless Client 2' config_methods=0x18c
dev_capab=0x1 group_capab=0x0
<2>P2P-GO-NEG-REQUEST 02:40:61:c2:f3:b7
<2>P2P-GO-NEG-REQUEST 02:40:61:c2:f3:b7
> p2p_connect 02:40:61:c2:f3:b7 pbc
OK
<2>P2P-GO-NEG-SUCCESS
<2>P2P-GROUP-FORMATION-SUCCESS
<2>P2P-GROUP-STARTED sta0-p2p-0 client DIRECT-vM
> interface
Available interfaces:
sta0-p2p-0
sta0
> p2p_group_remove sta0-p2p-0
<2>P2P-GROUP-REMOVED sta0-p2p-0 client
OK
> term
OK
\endverbatim
P2P device "Wireless Client2" (which ended up operating in GO role):
\verbatim
> p2p_find
OK
<2>P2P-DEVICE-FOUND 02:f0:bc:44:87:62 p2p_dev_addr=02:f0:bc:44:87:62
pri_dev_type=1-0050F204-1 name='Wireless Client' config_methods=0x18c
dev_capab=0x1 group_capab=0x0
> p2p_connect 02:f0:bc:44:87:62 pbc
OK
<2>P2P-GO-NEG-SUCCESS
<2>P2P-GROUP-FORMATION-SUCCESS
<2>P2P-GROUP-STARTED sta1-p2p-0 GO DIRECT-vM
> interface
Available interfaces:
sta1-p2p-0
sta1
> p2p_group_remove sta1-p2p-0
<2>P2P-GROUP-REMOVED sta1-p2p-0 GO
OK
> term
OK
\endverbatim
*/
external/hostap/doc/p2p_arch.dot
Vendored
+85
View File
@@ -0,0 +1,85 @@
digraph p2p_arch {
ranksep=.75;
size = "7.5,7.5";
edge [dir=none];
subgraph cluster_wpa_gui {
label = "wpa_gui";
status -> Qt;
scan -> Qt;
network -> Qt;
Qt -> peers;
Qt -> WPS;
Qt -> gui_ctrl;
gui_ctrl [label="ctrl i/f"];
}
subgraph cluster_wpa_supplicant {
label = "wpa_supplicant"
ctrl_iface [label="ctrl i/f"];
authenticator [label="Authenticator"];
supplicant [label="Supplicant"];
driver_iface [label="driver i/f"];
p2p_module [label="P2P\nmodule"];
wps_registrar [label="WPS\nRegistrar"];
wps_enrollee [label="WPS\nEnrollee"];
mgmt_entity [label="Management\nentity"];
ctrl_iface -> mgmt_entity;
p2p_module -> mgmt_entity;
wps_registrar -> mgmt_entity;
wps_enrollee -> mgmt_entity;
mgmt_entity -> authenticator;
mgmt_entity -> supplicant;
mgmt_entity -> driver_iface;
{ rank = same; mgmt_entity; p2p_module; }
}
subgraph cluster_wpa_cli {
label = "wpa_cli -a"
wpa_cli_action;
}
subgraph cluster_dnsmasq {
label = "dnsmasq"
dnsmasq;
}
subgraph cluster_dhclient {
label = "dhclient"
dhclient;
}
subgraph cluster_kernel {
label = "Linux kernel"
cfg80211 -> mac80211;
netdev -> mac80211;
mac80211 -> ath9k;
}
gui_ctrl -> ctrl_iface;
wpa_cli_action -> ctrl_iface;
driver_iface -> cfg80211;
wpa_cli_action -> dnsmasq;
wpa_cli_action -> dhclient;
dnsmasq -> netdev;
dhclient -> netdev;
edge [color=blue,dir=both];
p2p_module -> mgmt_entity -> driver_iface -> cfg80211 -> mac80211 -> ath9k;
edge [color=green,dir=both];
peers -> Qt -> gui_ctrl -> ctrl_iface -> mgmt_entity -> p2p_module;
}
external/hostap/doc/p2p_arch2.dot
Vendored
+85
View File
@@ -0,0 +1,85 @@
digraph p2p_arch2 {
ranksep=.75;
size = "7.5,7.5";
edge [dir=none];
subgraph cluster_wpa_gui {
label = "wpa_gui";
status -> Qt;
scan -> Qt;
network -> Qt;
Qt -> peers;
Qt -> WPS;
Qt -> gui_ctrl;
gui_ctrl [label="ctrl i/f"];
}
subgraph cluster_wpa_supplicant {
label = "wpa_supplicant"
ctrl_iface [label="ctrl i/f"];
authenticator [label="Authenticator"];
supplicant [label="Supplicant"];
driver_iface [label="driver i/f"];
wps_registrar [label="WPS\nRegistrar"];
wps_enrollee [label="WPS\nEnrollee"];
mgmt_entity [label="Management\nentity"];
ctrl_iface -> mgmt_entity;
wps_registrar -> mgmt_entity;
wps_enrollee -> mgmt_entity;
mgmt_entity -> authenticator;
mgmt_entity -> supplicant;
mgmt_entity -> driver_iface;
}
subgraph cluster_wpa_cli {
label = "wpa_cli -a"
wpa_cli_action;
}
subgraph cluster_dnsmasq {
label = "dnsmasq"
dnsmasq;
}
subgraph cluster_dhclient {
label = "dhclient"
dhclient;
}
subgraph cluster_kernel {
label = "Kernel"
ioctl -> umac;
netdev -> umac;
umac -> p2p_module;
p2p_module [label="P2P\nmodule"];
umac -> driver;
{ rank = same; umac; p2p_module; }
}
gui_ctrl -> ctrl_iface;
wpa_cli_action -> ctrl_iface;
driver_iface -> ioctl;
wpa_cli_action -> dnsmasq;
wpa_cli_action -> dhclient;
dnsmasq -> netdev;
dhclient -> netdev;
edge [color=blue,dir=both];
p2p_module -> umac -> driver;
edge [color=green,dir=both];
peers -> Qt -> gui_ctrl -> ctrl_iface -> mgmt_entity -> driver_iface -> ioctl -> umac -> p2p_module;
}
external/hostap/doc/p2p_sm.dot
Vendored
+62
View File
@@ -0,0 +1,62 @@
digraph p2p {
ranksep=.75;
size = "8.5,7.5";
start -> IDLE;
start [label="Init",shape=none];
/* Discovery: Scan followed by Find(SEARCH,LISTEN) */
subgraph cluster_0 {
label="Discovery";
color=lightgrey;
node [color=blue];
/* SCAN and LISTEN currently not used in the implementation */
SCAN [style=dotted];
LISTEN [style=dotted];
SCAN -> LISTEN;
LISTEN -> SEARCH -> LISTEN [style=dotted];
SEARCH -> SD_DURING_FIND [label="Peer SD capab\nand no info", weight=100];
SD_DURING_FIND -> SEARCH [label="RX SD Resp\nor timeout", weight=100];
SEARCH -> PROV_DISC_DURING_FIND [label="Prov Disc cmd\nand no Resp", weight=100];
PROV_DISC_DURING_FIND -> SEARCH [label="RX Prov Disc Resp\nor timeout", weight=100];
}
/* Group Formation */
subgraph cluster_1 {
label="Group Formation";
color=lightgrey;
node [color=green];
CONNECT -> CONNECT_LISTEN [style=dotted,weight=100];
CONNECT_LISTEN -> CONNECT [style=dotted,weight=100];
CONNECT -> WAIT_PEER_IDLE [label="RX GO Neg Resp\n(info unavail)"];
WAIT_PEER_IDLE -> WAIT_PEER_CONNECT [style=dotted,weight=100];
WAIT_PEER_CONNECT -> WAIT_PEER_IDLE [style=dotted,weight=100];
CONNECT -> GO_NEG [label="RX GO Neg Resp\n(success)", weight=10];
CONNECT_LISTEN -> GO_NEG [label="RX GO Neg Req or\nTX GO Neg Resp"];
WAIT_PEER_CONNECT -> GO_NEG [label="RX GO Neg Req"];
GO_NEG -> PROVISIONING [label="TX/RX GO Neg Conf"];
}
PROVISIONING -> IDLE [label="WPS\nsuccess"];
/* External triggers */
IDLE -> SCAN [label="Find cmd",weight=20];
IDLE -> CONNECT [label="Connect cmd",weight=20];
IDLE -> LISTEN_ONLY [label="Listen cmd"];
/* Timeouts */
/*
edge [color=red];
WAIT_PEER_IDLE -> IDLE [label="timeout", weight=0];
WAIT_PEER_CONNECT -> IDLE [label="timeout", weight=0];
CONNECT -> IDLE [label="timeout", weight=0];
CONNECT_LISTEN -> IDLE [label="timeout", weight=0];
GO_NEG -> IDLE [label="timeout", weight=0];
PROVISIONING -> IDLE [label="timeout", weight=0];
LISTEN_ONLY -> IDLE [label="timeout", weight=0];
SEARCH -> IDLE [label="timeout", weight=0];
*/
}
external/hostap/doc/porting.doxygen
Vendored
+208
View File
@@ -0,0 +1,208 @@
/**
\page porting Porting to different target boards and operating systems
%wpa_supplicant was designed to be easily portable to different
hardware (board, CPU) and software (OS, drivers) targets. It is
already used with number of operating systems and numerous wireless
card models and drivers. The main %wpa_supplicant repository includes
support for Linux, FreeBSD, and Windows. In addition, the code has been
ported to number of other operating systems like VxWorks, PalmOS,
Windows CE, and Windows Mobile. On the hardware
side, %wpa_supplicant is used on various systems: desktops, laptops,
PDAs, and embedded devices with CPUs including x86, PowerPC,
arm/xscale, and MIPS. Both big and little endian configurations are
supported.
\section ansi_c_extra Extra functions on top of ANSI C
%wpa_supplicant is mostly using ANSI C functions that are available on
most targets. However, couple of additional functions that are common
on modern UNIX systems are used. Number of these are listed with
prototypes in common.h (the \verbatim #ifdef CONFIG_ANSI_C_EXTRA \endverbatim
block). These functions may need to be implemented or at least defined
as macros to native functions in the target OS or C library.
Many of the common ANSI C functions are used through a wrapper
definitions in os.h to allow these to be replaced easily with a
platform specific version in case standard C libraries are not
available. In addition, os.h defines couple of common platform
specific functions that are implemented in os_unix.c for UNIX like
targets and in os_win32.c for Win32 API. If the target platform does
not support either of these examples, a new os_*.c file may need to be
added.
Unless OS_NO_C_LIB_DEFINES is defined, the standard ANSI C and POSIX
functions are used by defining the os_*() wrappers to use them
directly in order to avoid extra cost in size and speed. If the target
platform needs different versions of the functions, os.h can be
modified to define the suitable macros or alternatively,
OS_NO_C_LIB_DEFINES may be defined for the build and the wrapper
functions can then be implemented in a new os_*.c wrapper file.
common.h defines number of helper macros for handling integers of
different size and byte order. Suitable version of these definitions
may need to be added for the target platform.
\section configuration_backend Configuration backend
%wpa_supplicant implements a configuration interface that allows the
backend to be easily replaced in order to read configuration data from
a suitable source depending on the target platform. config.c
implements the generic code that can be shared with all configuration
backends. Each backend is implemented in its own config_*.c file.
The included config_file.c backend uses a text file for configuration
and config_winreg.c uses Windows registry. These files can be used as
an example for a new configuration backend if the target platform uses
different mechanism for configuration parameters. In addition,
config_none.c can be used as an empty starting point for building a
new configuration backend.
\section driver_iface_porting Driver interface
Unless the target OS and driver is already supported, most porting
projects have to implement a driver wrapper. This may be done by
adding a new driver interface module or modifying an existing module
(driver_*.c) if the new target is similar to one of them. \ref
driver_wrapper "Driver wrapper implementation" describes the details
of the driver interface and discusses the tasks involved in porting
this part of %wpa_supplicant.
\section l2_packet_porting l2_packet (link layer access)
%wpa_supplicant needs to have access to sending and receiving layer 2
(link layer) packets with two Ethertypes: EAP-over-LAN (EAPOL) 0x888e
and RSN pre-authentication 0x88c7. l2_packet.h defines the interfaces
used for this in the core %wpa_supplicant implementation.
If the target operating system supports a generic mechanism for link
layer access, that is likely the best mechanism for providing the
needed functionality for %wpa_supplicant. Linux packet socket is an
example of such a generic mechanism. If this is not available, a
separate interface may need to be implemented to the network stack or
driver. This is usually an intermediate or protocol driver that is
operating between the device driver and the OS network stack. If such
a mechanism is not feasible, the interface can also be implemented
directly in the device driver.
The main %wpa_supplicant repository includes l2_packet implementations
for Linux using packet sockets (l2_packet_linux.c), more portable
version using libpcap/libdnet libraries (l2_packet_pcap.c; this
supports WinPcap, too), and FreeBSD specific version of libpcap
interface (l2_packet_freebsd.c).
If the target operating system is supported by libpcap (receiving) and
libdnet (sending), l2_packet_pcap.c can likely be used with minimal or
no changes. If this is not a case or a proprietary interface for link
layer is required, a new l2_packet module may need to be
added. Alternatively, struct wpa_driver_ops::send_eapol() handler can
be used to override the l2_packet library if the link layer access is
integrated with the driver interface implementation.
\section eloop_porting Event loop
%wpa_supplicant uses a single process/thread model and an event loop
to provide callbacks on events (registered timeout, received packet,
signal). eloop.h defines the event loop interface. eloop.c is an
implementation of such an event loop using select() and sockets. This
is suitable for most UNIX/POSIX systems. When porting to other
operating systems, it may be necessary to replace that implementation
with OS specific mechanisms that provide similar functionality.
\section ctrl_iface_porting Control interface
%wpa_supplicant uses a \ref ctrl_iface_page "control interface"
to allow external processed
to get status information and to control the operations. Currently,
this is implemented with socket based communication; both UNIX domain
sockets and UDP sockets are supported. If the target OS does not
support sockets, this interface will likely need to be modified to use
another mechanism like message queues. The control interface is
optional component, so it is also possible to run %wpa_supplicant
without porting this part.
The %wpa_supplicant side of the control interface is implemented in
ctrl_iface.c. Matching client side is implemented as a control
interface library in wpa_ctrl.c.
\section entry_point Program entry point
%wpa_supplicant defines a set of functions that can be used to
initialize main supplicant processing. Each operating system has a
mechanism for starting new processing or threads. This is usually a
function with a specific set of arguments and calling convention. This
function is responsible on initializing %wpa_supplicant.
main.c includes an entry point for UNIX-like operating system, i.e.,
main() function that uses command line arguments for setting
parameters for %wpa_supplicant. When porting to other operating
systems, similar OS-specific entry point implementation is needed. It
can be implemented in a new file that is then linked with
%wpa_supplicant instead of main.o. main.c is also a good example on
how the initialization process should be done.
The supplicant initialization functions are defined in
wpa_supplicant_i.h. In most cases, the entry point function should
start by fetching configuration parameters. After this, a global
%wpa_supplicant context is initialized with a call to
wpa_supplicant_init(). After this, existing network interfaces can be
added with wpa_supplicant_add_iface(). wpa_supplicant_run() is then
used to start the main event loop. Once this returns at program
termination time, wpa_supplicant_deinit() is used to release global
context data.
wpa_supplicant_add_iface() and wpa_supplicant_remove_iface() can be
used dynamically to add and remove interfaces based on when
%wpa_supplicant processing is needed for them. This can be done, e.g.,
when hotplug network adapters are being inserted and ejected. It is
also possible to do this when a network interface is being
enabled/disabled if it is desirable that %wpa_supplicant processing
for the interface is fully enabled/disabled at the same time.
\section simple_build Simple build example
One way to start a porting project is to begin with a very simple
build of %wpa_supplicant with WPA-PSK support and once that is
building correctly, start adding features.
Following command can be used to build very simple version of
%wpa_supplicant:
\verbatim
cc -o wpa_supplicant config.c eloop.c common.c md5.c rc4.c sha1.c \
config_none.c l2_packet_none.c tls_none.c wpa.c preauth.c \
aes_wrap.c wpa_supplicant.c events.c main_none.c drivers.c
\endverbatim
The end result is not really very useful since it uses empty functions
for configuration parsing and layer 2 packet access and does not
include a driver interface. However, this is a good starting point
since the build is complete in the sense that all functions are
present and this is easy to configure to a build system by just
including the listed C files.
Once this version can be build successfully, the end result can be
made functional by adding a proper program entry point (main*.c),
driver interface (driver_*.c and matching CONFIG_DRIVER_* define for
registration in drivers.c), configuration parser/writer (config_*.c),
and layer 2 packet access implementation (l2_packet_*.c). After these
components have been added, the end result should be a working
WPA/WPA2-PSK enabled supplicant.
After the basic functionality has been verified to work, more features
can be added by linking in more files and defining C pre-processor
defines. Currently, the best source of information for what options
are available and which files needs to be included is in the Makefile
used for building the supplicant with make. Similar configuration will
be needed for build systems that either use different type of make
tool or a GUI-based project configuration.
*/
external/hostap/doc/testing_tools.doxygen
Vendored
+363
View File
@@ -0,0 +1,363 @@
/**
\page testing_tools Testing and development tools
[ \ref eapol_test "eapol_test" |
\ref preauth_test "preauth_test" |
\ref driver_test "driver_test" |
\ref unit_tests "Unit tests" |
\ref wpa_trace "Tracing code" ]
%wpa_supplicant source tree includes number of testing and development
tools that make it easier to test the programs without having to setup
a full test setup with wireless cards. In addition, these tools can be
used to implement automatic tests suites.
\section eapol_test eapol_test - EAP peer and RADIUS client testing
eapol_test is a program that links together the same EAP peer
implementation that %wpa_supplicant is using and the RADIUS
authentication client code from hostapd. In addition, it has minimal
glue code to combine these two components in similar ways to IEEE
802.1X/EAPOL Authenticator state machines. In other words, it
integrates IEEE 802.1X Authenticator (normally, an access point) and
IEEE 802.1X Supplicant (normally, a wireless client) together to
generate a single program that can be used to test EAP methods without
having to setup an access point and a wireless client.
The main uses for eapol_test are in interoperability testing of EAP
methods against RADIUS servers and in development testing for new EAP
methods. It can be easily used to automate EAP testing for
interoperability and regression since the program can be run from
shell scripts without require additional test components apart from a
RADIUS server. For example, the automated EAP tests described in
eap_testing.txt are implemented with eapol_test. Similarly, eapol_test
could be used to implement an automated regression test suite for a
RADIUS authentication server.
eapol_test uses the same build time configuration file, .config, as
%wpa_supplicant. This file is used to select which EAP methods are
included in eapol_test. This program is not built with the default
Makefile target, so a separate make command needs to be used to
compile the tool:
\verbatim
make eapol_test
\endverbatim
The resulting eapol_test binary has following command like options:
\verbatim
usage:
eapol_test [-nWS] -c<conf> [-a<AS IP>] [-p<AS port>] [-s<AS secret>] \
[-r<count>] [-t<timeout>] [-C<Connect-Info>] \
[-M<client MAC address>]
eapol_test scard
eapol_test sim <PIN> <num triplets> [debug]
options:
-c<conf> = configuration file
-a<AS IP> = IP address of the authentication server, default 127.0.0.1
-p<AS port> = UDP port of the authentication server, default 1812
-s<AS secret> = shared secret with the authentication server, default 'radius'
-r<count> = number of re-authentications
-W = wait for a control interface monitor before starting
-S = save configuration after authentiation
-n = no MPPE keys expected
-t<timeout> = sets timeout in seconds (default: 30 s)
-C<Connect-Info> = RADIUS Connect-Info (default: CONNECT 11Mbps 802.11b)
-M<client MAC address> = Set own MAC address (Calling-Station-Id,
default: 02:00:00:00:00:01)
\endverbatim
As an example,
\verbatim
eapol_test -ctest.conf -a127.0.0.1 -p1812 -ssecret -r1
\endverbatim
tries to complete EAP authentication based on the network
configuration from test.conf against the RADIUS server running on the
local host. A re-authentication is triggered to test fast
re-authentication. The configuration file uses the same format for
network blocks as %wpa_supplicant.
\section preauth_test preauth_test - WPA2 pre-authentication and EAP peer testing
preauth_test is similar to eapol_test in the sense that in combines
EAP peer implementation with something else, in this case, with WPA2
pre-authentication. This tool can be used to test pre-authentication
based on the code that %wpa_supplicant is using. As such, it tests
both the %wpa_supplicant implementation and the functionality of an
access point.
preauth_test is built with:
\verbatim
make preauth_test
\endverbatim
and it uses following command line arguments:
\verbatim
usage: preauth_test <conf> <target MAC address> <ifname>
\endverbatim
For example,
\verbatim
preauth_test test.conf 02:11:22:33:44:55 eth0
\endverbatim
would use network configuration from test.conf to try to complete
pre-authentication with AP using BSSID 02:11:22:33:44:55. The
pre-authentication packets would be sent using the eth0 interface.
\section driver_test driver_test - driver interface for testing wpa_supplicant
%wpa_supplicant was designed to support number of different ways to
communicate with a network device driver. This design uses \ref
driver_wrapper "driver interface API" and number of driver interface
implementations. One of these is driver_test.c, i.e., a test driver
interface that is actually not using any drivers. Instead, it provides
a mechanism for running %wpa_supplicant without having to have a
device driver or wireless LAN hardware for that matter.
driver_test can be used to talk directly with hostapd's driver_test
component to create a test setup where one or more clients and access
points can be tested within one test host and without having to have
multiple wireless cards. This makes it easier to test the core code in
%wpa_supplicant, and hostapd for that matter. Since driver_test uses
the same driver API than any other driver interface implementation,
the core code of %wpa_supplicant and hostapd can be tested with the
same coverage as one would get when using real wireless cards. The
only area that is not tested is the driver interface implementation
(driver_*.c).
Having the possibility to use simulated network components makes it
much easier to do development testing while adding new features and to
reproduce reported bugs. As such, it is often easiest to just do most
of the development and bug fixing without using real hardware. Once
the driver_test setup has been used to implement a new feature or fix
a bug, the end result can be verified with wireless LAN cards. In many
cases, this may even be unnecessary, depending on what area the
feature/bug is relating to. Of course, changes to driver interfaces
will still require use of real hardware.
Since multiple components can be run within a single host, testing of
complex network configuration, e.g., large number of clients
association with an access point, becomes quite easy. All the tests
can also be automated without having to resort to complex test setup
using remote access to multiple computers.
driver_test can be included in the %wpa_supplicant build in the same
way as any other driver interface, i.e., by adding the following line
into .config:
\verbatim
CONFIG_DRIVER_TEST=y
\endverbatim
When running %wpa_supplicant, the test interface is selected by using
\a -Dtest command line argument. The interface name (\a -i argument)
can be selected arbitrarily, i.e., it does not need to match with any
existing network interface. The interface name is used to generate a
MAC address, so when using multiple clients, each should use a
different interface, e.g., \a sta1, \a sta2, and so on.
%wpa_supplicant and hostapd are configured in the same way as they
would be for normal use. Following example shows a simple test setup
for WPA-PSK.
hostapd is configured with following psk-test.conf configuration file:
\verbatim
driver=test
interface=ap1
logger_stdout=-1
logger_stdout_level=0
debug=2
dump_file=/tmp/hostapd.dump
test_socket=/tmp/Test/ap1
ssid=jkm-test-psk
wpa=1
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
wpa_passphrase=12345678
\endverbatim
and started with following command:
\verbatim
hostapd psk-test.conf
\endverbatim
%wpa_supplicant uses following configuration file:
\verbatim
driver_param=test_socket=/tmp/Test/ap1
network={
ssid="jkm-test-psk"
key_mgmt=WPA-PSK
psk="12345678"
}
\endverbatim
%wpa_supplicant can then be started with following command:
\verbatim
wpa_supplicant -Dtest -cpsk-test.conf -ista1 -ddK
\endverbatim
If run without debug information, i.e., with
\verbatim
wpa_supplicant -Dtest -cpsk-test.conf -ista1
\endverbatim
%wpa_supplicant completes authentication and prints following events:
\verbatim
Trying to associate with 02:b8:a6:62:08:5a (SSID='jkm-test-psk' freq=0 MHz)
Associated with 02:b8:a6:62:08:5a
WPA: Key negotiation completed with 02:b8:a6:62:08:5a [PTK=TKIP GTK=TKIP]
CTRL-EVENT-CONNECTED - Connection to 02:b8:a6:62:08:5a completed (auth)
\endverbatim
If test setup is using multiple clients, it is possible to run
multiple %wpa_supplicant processes. Alternatively, the support for
multiple interfaces can be used with just one process to save some
resources on single-CPU systems. For example, following command runs
two clients:
\verbatim
./wpa_supplicant -Dtest -cpsk-test.conf -ista1 \
-N -Dtest -cpsk-test.conf -ista2
\endverbatim
This shows following event log:
\verbatim
Trying to associate with 02:b8:a6:62:08:5a (SSID='jkm-test-psk' freq=0 MHz)
Associated with 02:b8:a6:62:08:5a
WPA: Key negotiation completed with 02:b8:a6:62:08:5a [PTK=TKIP GTK=TKIP]
CTRL-EVENT-CONNECTED - Connection to 02:b8:a6:62:08:5a completed (auth)
Trying to associate with 02:b8:a6:62:08:5a (SSID='jkm-test-psk' freq=0 MHz)
Associated with 02:b8:a6:62:08:5a
WPA: Key negotiation completed with 02:b8:a6:62:08:5a [PTK=TKIP GTK=TKIP]
CTRL-EVENT-CONNECTED - Connection to 02:b8:a6:62:08:5a completed (auth)
\endverbatim
hostapd shows this with following events:
\verbatim
ap1: STA 02:b5:64:63:30:63 IEEE 802.11: associated
ap1: STA 02:b5:64:63:30:63 WPA: pairwise key handshake completed (WPA)
ap1: STA 02:b5:64:63:30:63 WPA: group key handshake completed (WPA)
ap1: STA 02:2a:c4:18:5b:f3 IEEE 802.11: associated
ap1: STA 02:2a:c4:18:5b:f3 WPA: pairwise key handshake completed (WPA)
ap1: STA 02:2a:c4:18:5b:f3 WPA: group key handshake completed (WPA)
\endverbatim
By default, driver_param is simulating a driver that uses the WPA/RSN
IE generated by %wpa_supplicant. Driver-generated IE and AssocInfo
events can be tested by adding \a use_associnfo=1 to the \a driver_param
line in the configuration file. For example:
\verbatim
driver_param=test_socket=/tmp/Test/ap1 use_associnfo=1
\endverbatim
\section unit_tests Unit tests
Number of the components (.c files) used in %wpa_supplicant define
their own unit tests for automated validation of the basic
functionality. Most of the tests for cryptographic algorithms are
using standard test vectors to validate functionality. These tests can
be useful especially when verifying port to a new CPU target.
The test programs are collected in the tests subdirectory. All
automated unit tests can be run with
\verbatim
make run-tests
\endverbatim
This make target builds and runs each test and terminates with zero
exit code if all tests were completed successfully.
\section wpa_trace Tracing code for developer debuggin
%wpa_supplicant and hostapd can be built with tracing code that will
track and analyze memory allocations and other resource registrations
and certain API uses. If incorrect use is detected, a backtrace of the
call location (and/or allocation location) is shown. This can also be
used to detect certain categories of memory leaks and report them
automatically when the program is terminated. The report will also
include information about forgotten eloop events.
The trace code can be enabled with CONFIG_WPA_TRACE=y build
option. More verbose backtrace information can be generated if libbfd
is available and the binaries are not stripped of symbol
information. This is enabled with CONFIG_WPA_TRACE_BFD=y.
For example, a memory leak (forgotten os_free() call) would show up
like this when the program is terminated:
\verbatim
MEMLEAK[0x82d200]: len 128
WPA_TRACE: memleak - START
[0]: ./wpa_supplicant(os_malloc+0x59) [0x41a5e9]
os_malloc() ../src/utils/os_unix.c:359
[1]: ./wpa_supplicant(os_zalloc+0x16) [0x41a676]
os_zalloc() ../src/utils/os_unix.c:418
[2]: ./wpa_supplicant(wpa_supplicant_init+0x38) [0x48b508]
wpa_supplicant_init() wpa_supplicant.c:2315
[3]: ./wpa_supplicant(main+0x2f3) [0x491073]
main() main.c:252
WPA_TRACE: memleak - END
MEMLEAK: total 128 bytes
\endverbatim
Another type of error that can be detected is freeing of memory area
that was registered for some use and is still be referenced:
\verbatim
WPA_TRACE: Freeing referenced memory - START
[2]: ./wpa_supplicant(os_free+0x5c) [0x41a53c]
os_free() ../src/utils/os_unix.c:411
[3]: ./wpa_supplicant(wpa_supplicant_remove_iface+0x30) [0x48b380]
wpa_supplicant_remove_iface() wpa_supplicant.c:2259
[4]: ./wpa_supplicant(wpa_supplicant_deinit+0x20) [0x48b3e0]
wpa_supplicant_deinit() wpa_supplicant.c:2430
[5]: ./wpa_supplicant(main+0x357) [0x4910d7]
main() main.c:276
WPA_TRACE: Freeing referenced memory - END
WPA_TRACE: Reference registration - START
[1]: ./wpa_supplicant [0x41c040]
eloop_trace_sock_add_ref() ../src/utils/eloop.c:94
[2]: ./wpa_supplicant(wpa_supplicant_ctrl_iface_deinit+0x17) [0x473247]
wpa_supplicant_ctrl_iface_deinit() ctrl_iface_unix.c:436
[3]: ./wpa_supplicant [0x48b21c]
wpa_supplicant_cleanup() wpa_supplicant.c:378
wpa_supplicant_deinit_iface() wpa_supplicant.c:2155
[4]: ./wpa_supplicant(wpa_supplicant_remove_iface+0x30) [0x48b380]
wpa_supplicant_remove_iface() wpa_supplicant.c:2259
[5]: ./wpa_supplicant(wpa_supplicant_deinit+0x20) [0x48b3e0]
wpa_supplicant_deinit() wpa_supplicant.c:2430
[6]: ./wpa_supplicant(main+0x357) [0x4910d7]
main() main.c:276
WPA_TRACE: Reference registration - END
Aborted
\endverbatim
This type of error results in showing backtraces for both the location
where the incorrect freeing happened and the location where the memory
area was marked referenced.
*/
external/hostap/doc/wpa_supplicant.fig
Vendored
+247
View File
@@ -0,0 +1,247 @@
#FIG 3.2
Landscape
Center
Inches
Letter
100.00
Single
-2
1200 2
6 1875 4050 2925 4350
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
1875 4050 2925 4050 2925 4350 1875 4350 1875 4050
4 0 0 50 -1 0 12 0.0000 4 180 735 2025 4275 l2_packet\001
-6
6 3450 1200 4275 1500
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
3450 1200 4275 1200 4275 1500 3450 1500 3450 1200
4 0 0 50 -1 0 12 0.0000 4 180 585 3600 1425 wpa_cli\001
-6
6 4725 1200 5925 1500
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
4725 1200 5925 1200 5925 1500 4725 1500 4725 1200
4 0 0 50 -1 0 12 0.0000 4 135 1005 4800 1425 GUI frontend\001
-6
6 6000 2700 7200 3225
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
6000 2700 7200 2700 7200 3225 6000 3225 6000 2700
4 0 0 50 -1 0 12 0.0000 4 135 975 6075 2925 WPA/WPA2\001
4 0 0 50 -1 0 12 0.0000 4 135 1065 6075 3150 state machine\001
-6
6 6000 4950 7200 5475
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
6000 4950 7200 4950 7200 5475 6000 5475 6000 4950
4 0 0 50 -1 0 12 0.0000 4 135 360 6075 5175 EAP\001
4 0 0 50 -1 0 12 0.0000 4 135 1065 6075 5400 state machine\001
-6
6 8700 3000 9375 3300
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
8700 3000 9375 3000 9375 3300 8700 3300 8700 3000
4 0 0 50 -1 0 12 0.0000 4 150 480 8775 3225 crypto\001
-6
6 4350 3900 5025 4425
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
4350 3900 5025 3900 5025 4425 4350 4425 4350 3900
4 0 0 50 -1 0 12 0.0000 4 105 420 4500 4125 event\001
4 0 0 50 -1 0 12 0.0000 4 180 315 4500 4350 loop\001
-6
6 4275 2550 5100 2850
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
4275 2550 5100 2550 5100 2850 4275 2850 4275 2550
4 0 0 50 -1 0 12 0.0000 4 135 450 4425 2775 ctrl i/f\001
-6
6 6000 3900 7200 4425
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
6000 3900 7200 3900 7200 4425 6000 4425 6000 3900
4 0 0 50 -1 0 12 0.0000 4 135 600 6075 4125 EAPOL\001
4 0 0 50 -1 0 12 0.0000 4 135 1065 6075 4350 state machine\001
-6
6 1800 6000 7800 8100
6 1800 6000 7800 7200
6 1800 6900 2700 7200
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
1800 6900 2700 6900 2700 7200 1800 7200 1800 6900
4 0 0 50 -1 0 12 0.0000 4 105 375 1875 7125 wext\001
-6
6 4725 6900 5625 7200
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
4725 6900 5625 6900 5625 7200 4725 7200 4725 6900
4 0 0 50 -1 0 12 0.0000 4 135 555 4800 7125 hermes\001
-6
6 6675 6900 7800 7200
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
6675 6900 7800 6900 7800 7200 6675 7200 6675 6900
4 0 0 50 -1 0 12 0.0000 4 180 930 6750 7125 ndiswrapper\001
-6
6 5700 6900 6600 7200
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
5700 6900 6600 6900 6600 7200 5700 7200 5700 6900
4 0 0 50 -1 0 12 0.0000 4 135 420 5775 7125 atmel\001
-6
6 4275 6000 5100 6300
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
4275 6000 5100 6000 5100 6300 4275 6300 4275 6000
4 0 0 50 -1 0 12 0.0000 4 135 630 4350 6225 driver i/f\001
-6
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
2775 6900 3675 6900 3675 7200 2775 7200 2775 6900
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
3750 6900 4650 6900 4650 7200 3750 7200 3750 6900
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 4
2250 6900 2250 6600 7200 6600 7200 6900
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
3225 6900 3225 6600
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
4200 6900 4200 6600
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
5175 6900 5175 6600
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
6150 6900 6150 6600
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
4650 6600 4650 6300
4 0 0 50 -1 0 12 0.0000 4 180 510 2850 7125 hostap\001
4 0 0 50 -1 0 12 0.0000 4 135 600 3825 7125 madwifi\001
-6
6 3525 7800 5775 8100
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
3525 7800 5775 7800 5775 8100 3525 8100 3525 7800
4 0 0 50 -1 0 12 0.0000 4 135 2145 3600 8025 kernel network device driver\001
-6
2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
2250 7200 4200 7800
2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
7200 7200 5100 7800
-6
6 9600 3000 10275 3300
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
9600 3000 10275 3000 10275 3300 9600 3300 9600 3000
4 0 0 50 -1 0 12 0.0000 4 135 315 9750 3225 TLS\001
-6
6 8100 4425 10425 7350
6 8175 4725 9225 5025
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
8175 4725 9225 4725 9225 5025 8175 5025 8175 4725
4 0 0 50 -1 0 12 0.0000 4 135 735 8250 4950 EAP-TLS\001
-6
6 9300 4725 10350 5025
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
9300 4725 10350 4725 10350 5025 9300 5025 9300 4725
4 0 0 50 -1 0 12 0.0000 4 135 810 9375 4950 EAP-MD5\001
-6
6 8175 5100 9225 5400
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
8175 5100 9225 5100 9225 5400 8175 5400 8175 5100
4 0 0 50 -1 0 12 0.0000 4 135 885 8250 5325 EAP-PEAP\001
-6
6 9300 5100 10350 5400
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
9300 5100 10350 5100 10350 5400 9300 5400 9300 5100
4 0 0 50 -1 0 12 0.0000 4 135 840 9375 5325 EAP-TTLS\001
-6
6 8175 5475 9225 5775
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
8175 5475 9225 5475 9225 5775 8175 5775 8175 5475
4 0 0 50 -1 0 12 0.0000 4 135 780 8250 5700 EAP-GTC\001
-6
6 9300 5475 10350 5775
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
9300 5475 10350 5475 10350 5775 9300 5775 9300 5475
4 0 0 50 -1 0 12 0.0000 4 135 765 9375 5700 EAP-OTP\001
-6
6 8175 5850 9225 6150
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
8175 5850 9225 5850 9225 6150 8175 6150 8175 5850
4 0 0 50 -1 0 12 0.0000 4 135 750 8250 6075 EAP-SIM\001
-6
6 9300 6225 10350 6525
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
9300 6225 10350 6225 10350 6525 9300 6525 9300 6225
4 0 0 50 -1 0 12 0.0000 4 135 465 9375 6450 LEAP\001
-6
6 8175 6225 9225 6525
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
8175 6225 9225 6225 9225 6525 8175 6525 8175 6225
4 0 0 50 -1 0 12 0.0000 4 135 765 8250 6450 EAP-PSK\001
-6
6 9300 5850 10350 6150
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
9300 5850 10350 5850 10350 6150 9300 6150 9300 5850
4 0 0 50 -1 0 12 0.0000 4 135 825 9375 6075 EAP-AKA\001
-6
6 8175 6975 9675 7275
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
8175 6975 9675 6975 9675 7275 8175 7275 8175 6975
4 0 0 50 -1 0 12 0.0000 4 135 1365 8250 7200 EAP-MSCHAPv2\001
-6
6 9300 6600 10350 6900
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
9300 6600 10350 6600 10350 6900 9300 6900 9300 6600
4 0 0 50 -1 0 12 0.0000 4 135 870 9375 6825 EAP-FAST\001
-6
6 8175 6600 9225 6900
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
8175 6600 9225 6600 9225 6900 8175 6900 8175 6600
4 0 0 50 -1 0 12 0.0000 4 135 795 8250 6825 EAP-PAX\001
-6
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
8100 7350 10425 7350 10425 4425 8100 4425 8100 7350
4 0 0 50 -1 0 12 0.0000 4 135 1050 8700 4650 EAP methods\001
-6
6 2775 5025 4050 5325
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
2775 5025 4050 5025 4050 5325 2775 5325 2775 5025
4 0 0 50 -1 0 12 0.0000 4 135 990 2925 5250 driver events\001
-6
6 2775 3150 4050 3450
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
2775 3150 4050 3150 4050 3450 2775 3450 2775 3150
4 0 0 50 -1 0 12 0.0000 4 180 990 2925 3375 configuration\001
-6
2 1 1 1 0 7 50 -1 -1 3.000 0 0 -1 0 0 2
1275 4200 1875 4200
2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
4500 2550 3900 1500
2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
4800 2550 5400 1500
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
2925 4200 4350 4200
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
5025 3900 6000 3000
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
5025 4200 6000 4200
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
4650 6000 4650 4425
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
6600 4425 6600 4950
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
6600 3225 6600 3900
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
7200 5250 8100 5250
2 1 0 1 2 7 50 -1 -1 0.000 0 0 -1 0 0 2
9075 4425 9075 3300
2 1 0 1 2 7 50 -1 -1 0.000 0 0 -1 0 0 2
7200 3000 8700 3150
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
4650 3900 4650 2850
2 1 0 1 2 7 50 -1 -1 0.000 0 0 -1 0 0 2
7200 4125 8700 3300
2 1 0 1 2 7 50 -1 -1 0.000 0 0 -1 0 0 2
6000 4350 5025 6000
2 1 0 1 2 7 50 -1 -1 0.000 0 0 -1 0 0 2
6000 3150 4875 6000
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
1500 2100 10800 2100 10800 7500 1500 7500 1500 2100
2 1 0 1 2 7 50 -1 -1 0.000 0 0 -1 0 0 2
9900 4425 9900 3300
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 1
4350 3900
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
4350 3900 4050 3450
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
4350 4425 4050 5025
4 0 0 50 -1 0 12 0.0000 4 135 915 375 3975 EAPOL and\001
4 0 0 50 -1 0 12 0.0000 4 180 630 375 4200 pre-auth\001
4 0 0 50 -1 0 12 0.0000 4 180 810 375 4425 ethertypes\001
4 0 0 50 -1 0 12 0.0000 4 135 1050 375 4650 from/to kernel\001
4 0 0 50 -1 0 12 0.0000 4 135 1920 3675 1875 frontend control interface\001
4 0 0 50 -1 2 14 0.0000 4 210 1440 1637 2371 wpa_supplicant\001