WPA2

Topics in this section,

  • In this section, you are going to learn

  • How to run wpa_supplicant and hostapd in wpa mode

#

Version

Supplicant

wpa_supplicant 2.10

Hostapd

hostapd 2.10

== Scanning == STA -> AP: **Probe Request** AP -> STA: **Probe Response** == Authentication == STA -> AP: **Authentication Request** AP --> STA: ACK AP -> STA: **Authentication Response** STA --> AP: ACK == Association == STA -> AP: **Association Request** AP --> STA: ACK AP -> STA: **Association Response** STA --> AP: ACK == EAPOL 4 way handshake == AP -> STA: **M1** STA --> AP: ACK STA -> AP: **M2** AP --> STA: ACK AP -> STA: **M3** STA --> AP: ACK STA -> AP: **M4** AP --> STA: ACK == PING AP from STA == STA -> AP: **ARP Request** AP --> STA: ACK AP -> STA: **ARP Reply** STA --> AP: ACK STA -> AP: **ICMP Echo Request** AP --> STA: ACK AP -> STA: **ICMP Echo Reply** STA --> AP: ACK STA -> AP: **ICMP Echo Request** AP --> STA: ACK AP -> STA: **ICMP Echo Reply** STA --> AP: ACK STA -> AP: **ICMP Echo Request** AP --> STA: ACK AP -> STA: **ICMP Echo Reply** STA --> AP: ACK

  • Run AP mode operation with hostapd

AP : Download hostapd

Note

  • Make sure internet is available in laptop to download hostapd package

 
test:~$ sudo wget http://w1.fi/releases/hostapd-2.10.tar.gz

AP : Extract hostapd

 
test:~$ sudo tar -xvf hostapd-2.10.tar.gz

AP : Change directory to hostapd

 
test:~$ cd hostapd-2.10/hostapd/

AP : Check the current working directory using pwd command

Note

  • Make sure your current working directory is hostapd

 
test:~$ pwd
/home/test/hostapd-2.10/hostapd

AP : Copy the contents of defconfig file to .config file

Note

  • .config file is required for make to start compilation of hostapd

 
test:~$ sudo cp defconfig .config
See the full configuration of hostapd
# Example hostapd build time configuration
#
# This file lists the configuration options that are used when building the
# hostapd binary. All lines starting with # are ignored. Configuration option
# lines must be commented out complete, if they are not to be included, i.e.,
# just setting VARIABLE=n is not disabling that variable.
#
# This file is included in Makefile, so variables like CFLAGS and LIBS can also
# be modified from here. In most cass, these lines should use += in order not
# to override previous values of the variables.

# Driver interface for Host AP driver
CONFIG_DRIVER_HOSTAP=y

# Driver interface for wired authenticator
#CONFIG_DRIVER_WIRED=y

# Driver interface for drivers using the nl80211 kernel interface
CONFIG_DRIVER_NL80211=y

# QCA vendor extensions to nl80211
#CONFIG_DRIVER_NL80211_QCA=y

# driver_nl80211.c requires libnl. If you are compiling it yourself
# you may need to point hostapd to your version of libnl.
#
#CFLAGS += -I$<path to libnl include files>
#LIBS += -L$<path to libnl library files>

# Use libnl v2.0 (or 3.0) libraries.
#CONFIG_LIBNL20=y

# Use libnl 3.2 libraries (if this is selected, CONFIG_LIBNL20 is ignored)
CONFIG_LIBNL32=y


# Driver interface for FreeBSD net80211 layer (e.g., Atheros driver)
#CONFIG_DRIVER_BSD=y
#CFLAGS += -I/usr/local/include
#LIBS += -L/usr/local/lib
#LIBS_p += -L/usr/local/lib
#LIBS_c += -L/usr/local/lib

# Driver interface for no driver (e.g., RADIUS server only)
#CONFIG_DRIVER_NONE=y

# WPA2/IEEE 802.11i RSN pre-authentication
CONFIG_RSN_PREAUTH=y

# Support Operating Channel Validation
#CONFIG_OCV=y

# Integrated EAP server
CONFIG_EAP=y

# EAP Re-authentication Protocol (ERP) in integrated EAP server
CONFIG_ERP=y

# EAP-MD5 for the integrated EAP server
CONFIG_EAP_MD5=y

# EAP-TLS for the integrated EAP server
CONFIG_EAP_TLS=y

# EAP-MSCHAPv2 for the integrated EAP server
CONFIG_EAP_MSCHAPV2=y

# EAP-PEAP for the integrated EAP server
CONFIG_EAP_PEAP=y

# EAP-GTC for the integrated EAP server
CONFIG_EAP_GTC=y

# EAP-TTLS for the integrated EAP server
CONFIG_EAP_TTLS=y

# EAP-SIM for the integrated EAP server
#CONFIG_EAP_SIM=y

# EAP-AKA for the integrated EAP server
#CONFIG_EAP_AKA=y

# EAP-AKA' for the integrated EAP server
# This requires CONFIG_EAP_AKA to be enabled, too.
#CONFIG_EAP_AKA_PRIME=y

# EAP-PAX for the integrated EAP server
#CONFIG_EAP_PAX=y

# EAP-PSK for the integrated EAP server (this is _not_ needed for WPA-PSK)
#CONFIG_EAP_PSK=y

# EAP-pwd for the integrated EAP server (secure authentication with a password)
#CONFIG_EAP_PWD=y

# EAP-SAKE for the integrated EAP server
#CONFIG_EAP_SAKE=y

# EAP-GPSK for the integrated EAP server
#CONFIG_EAP_GPSK=y
# Include support for optional SHA256 cipher suite in EAP-GPSK
#CONFIG_EAP_GPSK_SHA256=y

# EAP-FAST for the integrated EAP server
#CONFIG_EAP_FAST=y

# EAP-TEAP for the integrated EAP server
# Note: The current EAP-TEAP implementation is experimental and should not be
# enabled for production use. The IETF RFC 7170 that defines EAP-TEAP has number
# of conflicting statements and missing details and the implementation has
# vendor specific workarounds for those and as such, may not interoperate with
# any other implementation. This should not be used for anything else than
# experimentation and interoperability testing until those issues has been
# resolved.
#CONFIG_EAP_TEAP=y

# Wi-Fi Protected Setup (WPS)
#CONFIG_WPS=y
# Enable UPnP support for external WPS Registrars
#CONFIG_WPS_UPNP=y
# Enable WPS support with NFC config method
#CONFIG_WPS_NFC=y

# EAP-IKEv2
#CONFIG_EAP_IKEV2=y

# Trusted Network Connect (EAP-TNC)
#CONFIG_EAP_TNC=y

# EAP-EKE for the integrated EAP server
#CONFIG_EAP_EKE=y

# PKCS#12 (PFX) support (used to read private key and certificate file from
# a file that usually has extension .p12 or .pfx)
CONFIG_PKCS12=y

# RADIUS authentication server. This provides access to the integrated EAP
# server from external hosts using RADIUS.
#CONFIG_RADIUS_SERVER=y

# Build IPv6 support for RADIUS operations
CONFIG_IPV6=y

# IEEE Std 802.11r-2008 (Fast BSS Transition)
#CONFIG_IEEE80211R=y

# Use the hostapd's IEEE 802.11 authentication (ACL), but without
# the IEEE 802.11 Management capability (e.g., FreeBSD/net80211)
#CONFIG_DRIVER_RADIUS_ACL=y

# Wireless Network Management (IEEE Std 802.11v-2011)
# Note: This is experimental and not complete implementation.
#CONFIG_WNM=y

# IEEE 802.11ac (Very High Throughput) support
#CONFIG_IEEE80211AC=y

# IEEE 802.11ax HE support
# Note: This is experimental and work in progress. The definitions are still
# subject to change and this should not be expected to interoperate with the
# final IEEE 802.11ax version.
#CONFIG_IEEE80211AX=y

# Remove debugging code that is printing out debug messages to stdout.
# This can be used to reduce the size of the hostapd considerably if debugging
# code is not needed.
#CONFIG_NO_STDOUT_DEBUG=y

# Add support for writing debug log to a file: -f /tmp/hostapd.log
# Disabled by default.
#CONFIG_DEBUG_FILE=y

# Send debug messages to syslog instead of stdout
#CONFIG_DEBUG_SYSLOG=y

# Add support for sending all debug messages (regardless of debug verbosity)
# to the Linux kernel tracing facility. This helps debug the entire stack by
# making it easy to record everything happening from the driver up into the
# same file, e.g., using trace-cmd.
#CONFIG_DEBUG_LINUX_TRACING=y

# Remove support for RADIUS accounting
#CONFIG_NO_ACCOUNTING=y

# Remove support for RADIUS
#CONFIG_NO_RADIUS=y

# Remove support for VLANs
#CONFIG_NO_VLAN=y

# Enable support for fully dynamic VLANs. This enables hostapd to
# automatically create bridge and VLAN interfaces if necessary.
#CONFIG_FULL_DYNAMIC_VLAN=y

# Use netlink-based kernel API for VLAN operations instead of ioctl()
# Note: This requires libnl 3.1 or newer.
#CONFIG_VLAN_NETLINK=y

# Remove support for dumping internal state through control interface commands
# This can be used to reduce binary size at the cost of disabling a debugging
# option.
#CONFIG_NO_DUMP_STATE=y

# Enable tracing code for developer debugging
# This tracks use of memory allocations and other registrations and reports
# incorrect use with a backtrace of call (or allocation) location.
#CONFIG_WPA_TRACE=y
# For BSD, comment out these.
#LIBS += -lexecinfo
#LIBS_p += -lexecinfo
#LIBS_c += -lexecinfo

# Use libbfd to get more details for developer debugging
# This enables use of libbfd to get more detailed symbols for the backtraces
# generated by CONFIG_WPA_TRACE=y.
#CONFIG_WPA_TRACE_BFD=y
# For BSD, comment out these.
#LIBS += -lbfd -liberty -lz
#LIBS_p += -lbfd -liberty -lz
#LIBS_c += -lbfd -liberty -lz

# hostapd depends on strong random number generation being available from the
# operating system. os_get_random() function is used to fetch random data when
# needed, e.g., for key generation. On Linux and BSD systems, this works by
# reading /dev/urandom. It should be noted that the OS entropy pool needs to be
# properly initialized before hostapd is started. This is important especially
# on embedded devices that do not have a hardware random number generator and
# may by default start up with minimal entropy available for random number
# generation.
#
# As a safety net, hostapd is by default trying to internally collect
# additional entropy for generating random data to mix in with the data
# fetched from the OS. This by itself is not considered to be very strong, but
# it may help in cases where the system pool is not initialized properly.
# However, it is very strongly recommended that the system pool is initialized
# with enough entropy either by using hardware assisted random number
# generator or by storing state over device reboots.
#
# hostapd can be configured to maintain its own entropy store over restarts to
# enhance random number generation. This is not perfect, but it is much more
# secure than using the same sequence of random numbers after every reboot.
# This can be enabled with -e<entropy file> command line option. The specified
# file needs to be readable and writable by hostapd.
#
# If the os_get_random() is known to provide strong random data (e.g., on
# Linux/BSD, the board in question is known to have reliable source of random
# data from /dev/urandom), the internal hostapd random pool can be disabled.
# This will save some in binary size and CPU use. However, this should only be
# considered for builds that are known to be used on devices that meet the
# requirements described above.
#CONFIG_NO_RANDOM_POOL=y

# Should we attempt to use the getrandom(2) call that provides more reliable
# yet secure randomness source than /dev/random on Linux 3.17 and newer.
# Requires glibc 2.25 to build, falls back to /dev/random if unavailable.
#CONFIG_GETRANDOM=y

# Should we use poll instead of select? Select is used by default.
#CONFIG_ELOOP_POLL=y

# Should we use epoll instead of select? Select is used by default.
#CONFIG_ELOOP_EPOLL=y

# Should we use kqueue instead of select? Select is used by default.
#CONFIG_ELOOP_KQUEUE=y

# Select TLS implementation
# openssl = OpenSSL (default)
# gnutls = GnuTLS
# internal = Internal TLSv1 implementation (experimental)
# linux = Linux kernel AF_ALG and internal TLSv1 implementation (experimental)
# none = Empty template
#CONFIG_TLS=openssl

# TLS-based EAP methods require at least TLS v1.0. Newer version of TLS (v1.1)
# can be enabled to get a stronger construction of messages when block ciphers
# are used.
#CONFIG_TLSV11=y

# TLS-based EAP methods require at least TLS v1.0. Newer version of TLS (v1.2)
# can be enabled to enable use of stronger crypto algorithms.
#CONFIG_TLSV12=y

# Select which ciphers to use by default with OpenSSL if the user does not
# specify them.
#CONFIG_TLS_DEFAULT_CIPHERS="DEFAULT:!EXP:!LOW"

# If CONFIG_TLS=internal is used, additional library and include paths are
# needed for LibTomMath. Alternatively, an integrated, minimal version of
# LibTomMath can be used. See beginning of libtommath.c for details on benefits
# and drawbacks of this option.
#CONFIG_INTERNAL_LIBTOMMATH=y
#ifndef CONFIG_INTERNAL_LIBTOMMATH
#LTM_PATH=/usr/src/libtommath-0.39
#CFLAGS += -I$(LTM_PATH)
#LIBS += -L$(LTM_PATH)
#LIBS_p += -L$(LTM_PATH)
#endif
# At the cost of about 4 kB of additional binary size, the internal LibTomMath
# can be configured to include faster routines for exptmod, sqr, and div to
# speed up DH and RSA calculation considerably
#CONFIG_INTERNAL_LIBTOMMATH_FAST=y

# Interworking (IEEE 802.11u)
# This can be used to enable functionality to improve interworking with
# external networks.
#CONFIG_INTERWORKING=y

# Hotspot 2.0
#CONFIG_HS20=y

# Enable SQLite database support in hlr_auc_gw, EAP-SIM DB, and eap_user_file
#CONFIG_SQLITE=y

# Enable Fast Session Transfer (FST)
#CONFIG_FST=y

# Enable CLI commands for FST testing
#CONFIG_FST_TEST=y

# Testing options
# This can be used to enable some testing options (see also the example
# configuration file) that are really useful only for testing clients that
# connect to this hostapd. These options allow, for example, to drop a
# certain percentage of probe requests or auth/(re)assoc frames.
#
#CONFIG_TESTING_OPTIONS=y

# Automatic Channel Selection
# This will allow hostapd to pick the channel automatically when channel is set
# to "acs_survey" or "0". Eventually, other ACS algorithms can be added in
# similar way.
#
# Automatic selection is currently only done through initialization, later on
# we hope to do background checks to keep us moving to more ideal channels as
# time goes by. ACS is currently only supported through the nl80211 driver and
# your driver must have survey dump capability that is filled by the driver
# during scanning.
#
# You can customize the ACS survey algorithm with the hostapd.conf variable
# acs_num_scans.
#
# Supported ACS drivers:
# * ath9k
# * ath5k
# * ath10k
#
# For more details refer to:
# https://wireless.wiki.kernel.org/en/users/documentation/acs
#
#CONFIG_ACS=y

# Multiband Operation support
# These extensions facilitate efficient use of multiple frequency bands
# available to the AP and the devices that may associate with it.
#CONFIG_MBO=y

# Client Taxonomy
# Has the AP retain the Probe Request and (Re)Association Request frames from
# a client, from which a signature can be produced which can identify the model
# of client device like "Nexus 6P" or "iPhone 5s".
#CONFIG_TAXONOMY=y

# Fast Initial Link Setup (FILS) (IEEE 802.11ai)
#CONFIG_FILS=y
# FILS shared key authentication with PFS
#CONFIG_FILS_SK_PFS=y

# Include internal line edit mode in hostapd_cli. This can be used to provide
# limited command line editing and history support.
#CONFIG_WPA_CLI_EDIT=y

# Opportunistic Wireless Encryption (OWE)
# Experimental implementation of draft-harkins-owe-07.txt
#CONFIG_OWE=y

# Airtime policy support
#CONFIG_AIRTIME_POLICY=y

# Override default value for the wpa_disable_eapol_key_retries configuration
# parameter. See that parameter in hostapd.conf for more details.
#CFLAGS += -DDEFAULT_WPA_DISABLE_EAPOL_KEY_RETRIES=1

# Wired equivalent privacy (WEP)
# WEP is an obsolete cryptographic data confidentiality algorithm that is not
# considered secure. It should not be used for anything anymore. The
# functionality needed to use WEP is available in the current hostapd
# release under this optional build parameter. This functionality is subject to
# be completely removed in a future release.
#CONFIG_WEP=y

# Remove all TKIP functionality
# TKIP is an old cryptographic data confidentiality algorithm that is not
# considered secure. It should not be used anymore. For now, the default hostapd
# build includes this to allow mixed mode WPA+WPA2 networks to be enabled, but
# that functionality is subject to be removed in the future.
#CONFIG_NO_TKIP=y

# Pre-Association Security Negotiation (PASN)
# Experimental implementation based on IEEE P802.11z/D2.6 and the protocol
# design is still subject to change. As such, this should not yet be enabled in
# production use.
# This requires CONFIG_IEEE80211W=y to be enabled, too.
#CONFIG_PASN=y

# Device Provisioning Protocol (DPP) (also known as Wi-Fi Easy Connect)
CONFIG_DPP=y
# DPP version 2 support
CONFIG_DPP2=y
# DPP version 3 support (experimental and still changing; do not enable for
# production use)
#CONFIG_DPP3=y

AP : Complile hostapd

Note

  • Compile hostapd by running make command

 
test:~$ sudo make

AP : Check for the binaries created

Note

  • Make sure hostapd and hostapd_cli are present

 
test:~$ ls
hostapd
hostapd_cli

AP : Create run_hostapd.conf

 
test:~$ sudo vim ./run_hostapd.conf

ctrl_interface=/run/hostapd
interface=wlp0s20f3
driver=nl80211
ssid=test_wpa2_ng
hw_mode=g
ieee80211n=1
channel=6
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=12345678
wpa_key_mgmt=WPA-PSK
rsn_pairwise=CCMP
group_cipher=CCMP

AP : Run hostapd

 
test:~$ sudo ./hostapd ./run_hostapd.conf
wlan0: interface state UNINITIALIZED->ENABLED
wlan0: AP-ENABLED

AP : Check ps status and confirm hostapd process is running

 
test:~$ ps -N | grep -i hostapd
36261 pts/3    00:00:00 hostapd

STA : Download wpa_supplicant

Note

  • Make sure internet is available in laptop to download supplicant package

 
test:~$ sudo wget https://w1.fi/releases/wpa_supplicant-2.10.tar.gz

STA : Extract wpa_supplicant

 
test:~$ sudo tar -xvf wpa_supplicant-2.10.tar.gz

STA : Change directory to wpa_supplicant

 
test:~$ cd wpa_supplicant-2.10/wpa_supplicant/

STA : Check the current working directory using pwd command

Note

  • Make sure your current working directory is wpa_supplicant

 
test:~$ pwd
/home/test/wpa_supplicant-2.10/wpa_supplicant

STA : Copy the contents of defconfig file to .config file

Note

  • .config file is required for make to start compilation of supplicant

 
test:~$ sudo cp defconfig .config
See the full configuration of wpa_supplicant
# Example wpa_supplicant build time configuration
#
# This file lists the configuration options that are used when building the
# wpa_supplicant binary. All lines starting with # are ignored. Configuration
# option lines must be commented out complete, if they are not to be included,
# i.e., just setting VARIABLE=n is not disabling that variable.
#
# This file is included in Makefile, so variables like CFLAGS and LIBS can also
# be modified from here. In most cases, these lines should use += in order not
# to override previous values of the variables.


# Uncomment following two lines and fix the paths if you have installed OpenSSL
# or GnuTLS in non-default location
#CFLAGS += -I/usr/local/openssl/include
#LIBS += -L/usr/local/openssl/lib

# Some Red Hat versions seem to include kerberos header files from OpenSSL, but
# the kerberos files are not in the default include path. Following line can be
# used to fix build issues on such systems (krb5.h not found).
#CFLAGS += -I/usr/include/kerberos

# Driver interface for generic Linux wireless extensions
# Note: WEXT is deprecated in the current Linux kernel version and no new
# functionality is added to it. nl80211-based interface is the new
# replacement for WEXT and its use allows wpa_supplicant to properly control
# the driver to improve existing functionality like roaming and to support new
# functionality.
CONFIG_DRIVER_WEXT=y

# Driver interface for Linux drivers using the nl80211 kernel interface
CONFIG_DRIVER_NL80211=y

# QCA vendor extensions to nl80211
#CONFIG_DRIVER_NL80211_QCA=y

# driver_nl80211.c requires libnl. If you are compiling it yourself
# you may need to point hostapd to your version of libnl.
#
#CFLAGS += -I$<path to libnl include files>
#LIBS += -L$<path to libnl library files>

# Use libnl v2.0 (or 3.0) libraries.
#CONFIG_LIBNL20=y

# Use libnl 3.2 libraries (if this is selected, CONFIG_LIBNL20 is ignored)
CONFIG_LIBNL32=y


# Driver interface for FreeBSD net80211 layer (e.g., Atheros driver)
#CONFIG_DRIVER_BSD=y
#CFLAGS += -I/usr/local/include
#LIBS += -L/usr/local/lib
#LIBS_p += -L/usr/local/lib
#LIBS_c += -L/usr/local/lib

# Driver interface for Windows NDIS
#CONFIG_DRIVER_NDIS=y
#CFLAGS += -I/usr/include/w32api/ddk
#LIBS += -L/usr/local/lib
# For native build using mingw
#CONFIG_NATIVE_WINDOWS=y
# Additional directories for cross-compilation on Linux host for mingw target
#CFLAGS += -I/opt/mingw/mingw32/include/ddk
#LIBS += -L/opt/mingw/mingw32/lib
#CC=mingw32-gcc
# By default, driver_ndis uses WinPcap for low-level operations. This can be
# replaced with the following option which replaces WinPcap calls with NDISUIO.
# However, this requires that WZC is disabled (net stop wzcsvc) before starting
# wpa_supplicant.
# CONFIG_USE_NDISUIO=y

# Driver interface for wired Ethernet drivers
CONFIG_DRIVER_WIRED=y

# Driver interface for MACsec capable Qualcomm Atheros drivers
#CONFIG_DRIVER_MACSEC_QCA=y

# Driver interface for Linux MACsec drivers
CONFIG_DRIVER_MACSEC_LINUX=y

# Driver interface for the Broadcom RoboSwitch family
#CONFIG_DRIVER_ROBOSWITCH=y

# Driver interface for no driver (e.g., WPS ER only)
#CONFIG_DRIVER_NONE=y

# Solaris libraries
#LIBS += -lsocket -ldlpi -lnsl
#LIBS_c += -lsocket

# Enable IEEE 802.1X Supplicant (automatically included if any EAP method or
# MACsec is included)
CONFIG_IEEE8021X_EAPOL=y

# EAP-MD5
CONFIG_EAP_MD5=y

# EAP-MSCHAPv2
CONFIG_EAP_MSCHAPV2=y

# EAP-TLS
CONFIG_EAP_TLS=y

# EAL-PEAP
CONFIG_EAP_PEAP=y

# EAP-TTLS
CONFIG_EAP_TTLS=y

# EAP-FAST
CONFIG_EAP_FAST=y

# EAP-TEAP
# Note: The current EAP-TEAP implementation is experimental and should not be
# enabled for production use. The IETF RFC 7170 that defines EAP-TEAP has number
# of conflicting statements and missing details and the implementation has
# vendor specific workarounds for those and as such, may not interoperate with
# any other implementation. This should not be used for anything else than
# experimentation and interoperability testing until those issues has been
# resolved.
#CONFIG_EAP_TEAP=y

# EAP-GTC
CONFIG_EAP_GTC=y

# EAP-OTP
CONFIG_EAP_OTP=y

# EAP-SIM (enable CONFIG_PCSC, if EAP-SIM is used)
#CONFIG_EAP_SIM=y

# Enable SIM simulator (Milenage) for EAP-SIM
#CONFIG_SIM_SIMULATOR=y

# EAP-PSK (experimental; this is _not_ needed for WPA-PSK)
#CONFIG_EAP_PSK=y

# EAP-pwd (secure authentication using only a password)
CONFIG_EAP_PWD=y

# EAP-PAX
CONFIG_EAP_PAX=y

# LEAP
CONFIG_EAP_LEAP=y

# EAP-AKA (enable CONFIG_PCSC, if EAP-AKA is used)
#CONFIG_EAP_AKA=y

# EAP-AKA' (enable CONFIG_PCSC, if EAP-AKA' is used).
# This requires CONFIG_EAP_AKA to be enabled, too.
#CONFIG_EAP_AKA_PRIME=y

# Enable USIM simulator (Milenage) for EAP-AKA
#CONFIG_USIM_SIMULATOR=y

# EAP-SAKE
CONFIG_EAP_SAKE=y

# EAP-GPSK
CONFIG_EAP_GPSK=y
# Include support for optional SHA256 cipher suite in EAP-GPSK
CONFIG_EAP_GPSK_SHA256=y

# EAP-TNC and related Trusted Network Connect support (experimental)
CONFIG_EAP_TNC=y

# Wi-Fi Protected Setup (WPS)
CONFIG_WPS=y
# Enable WPS external registrar functionality
#CONFIG_WPS_ER=y
# Disable credentials for an open network by default when acting as a WPS
# registrar.
#CONFIG_WPS_REG_DISABLE_OPEN=y
# Enable WPS support with NFC config method
#CONFIG_WPS_NFC=y

# EAP-IKEv2
CONFIG_EAP_IKEV2=y

# EAP-EKE
#CONFIG_EAP_EKE=y

# MACsec
CONFIG_MACSEC=y

# PKCS#12 (PFX) support (used to read private key and certificate file from
# a file that usually has extension .p12 or .pfx)
CONFIG_PKCS12=y

# Smartcard support (i.e., private key on a smartcard), e.g., with openssl
# engine.
CONFIG_SMARTCARD=y

# PC/SC interface for smartcards (USIM, GSM SIM)
# Enable this if EAP-SIM or EAP-AKA is included
#CONFIG_PCSC=y

# Support HT overrides (disable HT/HT40, mask MCS rates, etc.)
#CONFIG_HT_OVERRIDES=y

# Support VHT overrides (disable VHT, mask MCS rates, etc.)
#CONFIG_VHT_OVERRIDES=y

# Development testing
#CONFIG_EAPOL_TEST=y

# Select control interface backend for external programs, e.g, wpa_cli:
# unix = UNIX domain sockets (default for Linux/*BSD)
# udp = UDP sockets using localhost (127.0.0.1)
# udp6 = UDP IPv6 sockets using localhost (::1)
# named_pipe = Windows Named Pipe (default for Windows)
# udp-remote = UDP sockets with remote access (only for tests systems/purpose)
# udp6-remote = UDP IPv6 sockets with remote access (only for tests purpose)
# y = use default (backwards compatibility)
# If this option is commented out, control interface is not included in the
# build.
CONFIG_CTRL_IFACE=y

# Include support for GNU Readline and History Libraries in wpa_cli.
# When building a wpa_cli binary for distribution, please note that these
# libraries are licensed under GPL and as such, BSD license may not apply for
# the resulting binary.
#CONFIG_READLINE=y

# Include internal line edit mode in wpa_cli. This can be used as a replacement
# for GNU Readline to provide limited command line editing and history support.
#CONFIG_WPA_CLI_EDIT=y

# Remove debugging code that is printing out debug message to stdout.
# This can be used to reduce the size of the wpa_supplicant considerably
# if debugging code is not needed. The size reduction can be around 35%
# (e.g., 90 kB).
#CONFIG_NO_STDOUT_DEBUG=y

# Remove WPA support, e.g., for wired-only IEEE 802.1X supplicant, to save
# 35-50 kB in code size.
#CONFIG_NO_WPA=y

# Remove IEEE 802.11i/WPA-Personal ASCII passphrase support
# This option can be used to reduce code size by removing support for
# converting ASCII passphrases into PSK. If this functionality is removed, the
# PSK can only be configured as the 64-octet hexstring (e.g., from
# wpa_passphrase). This saves about 0.5 kB in code size.
#CONFIG_NO_WPA_PASSPHRASE=y

# Simultaneous Authentication of Equals (SAE), WPA3-Personal
CONFIG_SAE=y

# Disable scan result processing (ap_scan=1) to save code size by about 1 kB.
# This can be used if ap_scan=1 mode is never enabled.
#CONFIG_NO_SCAN_PROCESSING=y

# Select configuration backend:
# file = text file (e.g., wpa_supplicant.conf; note: the configuration file
#	path is given on command line, not here; this option is just used to
#	select the backend that allows configuration files to be used)
# winreg = Windows registry (see win_example.reg for an example)
CONFIG_BACKEND=file

# Remove configuration write functionality (i.e., to allow the configuration
# file to be updated based on runtime configuration changes). The runtime
# configuration can still be changed, the changes are just not going to be
# persistent over restarts. This option can be used to reduce code size by
# about 3.5 kB.
#CONFIG_NO_CONFIG_WRITE=y

# Remove support for configuration blobs to reduce code size by about 1.5 kB.
#CONFIG_NO_CONFIG_BLOBS=y

# Select program entry point implementation:
# main = UNIX/POSIX like main() function (default)
# main_winsvc = Windows service (read parameters from registry)
# main_none = Very basic example (development use only)
#CONFIG_MAIN=main

# Select wrapper for operating system and C library specific functions
# unix = UNIX/POSIX like systems (default)
# win32 = Windows systems
# none = Empty template
#CONFIG_OS=unix

# Select event loop implementation
# eloop = select() loop (default)
# eloop_win = Windows events and WaitForMultipleObject() loop
#CONFIG_ELOOP=eloop

# Should we use poll instead of select? Select is used by default.
#CONFIG_ELOOP_POLL=y

# Should we use epoll instead of select? Select is used by default.
#CONFIG_ELOOP_EPOLL=y

# Should we use kqueue instead of select? Select is used by default.
#CONFIG_ELOOP_KQUEUE=y

# Select layer 2 packet implementation
# linux = Linux packet socket (default)
# pcap = libpcap/libdnet/WinPcap
# freebsd = FreeBSD libpcap
# winpcap = WinPcap with receive thread
# ndis = Windows NDISUIO (note: requires CONFIG_USE_NDISUIO=y)
# none = Empty template
#CONFIG_L2_PACKET=linux

# Disable Linux packet socket workaround applicable for station interface
# in a bridge for EAPOL frames. This should be uncommented only if the kernel
# is known to not have the regression issue in packet socket behavior with
# bridge interfaces (commit 'bridge: respect RFC2863 operational state')').
#CONFIG_NO_LINUX_PACKET_SOCKET_WAR=y

# Support Operating Channel Validation
#CONFIG_OCV=y

# Select TLS implementation
# openssl = OpenSSL (default)
# gnutls = GnuTLS
# internal = Internal TLSv1 implementation (experimental)
# linux = Linux kernel AF_ALG and internal TLSv1 implementation (experimental)
# none = Empty template
#CONFIG_TLS=openssl

# TLS-based EAP methods require at least TLS v1.0. Newer version of TLS (v1.1)
# can be enabled to get a stronger construction of messages when block ciphers
# are used. It should be noted that some existing TLS v1.0 -based
# implementation may not be compatible with TLS v1.1 message (ClientHello is
# sent prior to negotiating which version will be used)
#CONFIG_TLSV11=y

# TLS-based EAP methods require at least TLS v1.0. Newer version of TLS (v1.2)
# can be enabled to enable use of stronger crypto algorithms. It should be
# noted that some existing TLS v1.0 -based implementation may not be compatible
# with TLS v1.2 message (ClientHello is sent prior to negotiating which version
# will be used)
#CONFIG_TLSV12=y

# Select which ciphers to use by default with OpenSSL if the user does not
# specify them.
#CONFIG_TLS_DEFAULT_CIPHERS="DEFAULT:!EXP:!LOW"

# If CONFIG_TLS=internal is used, additional library and include paths are
# needed for LibTomMath. Alternatively, an integrated, minimal version of
# LibTomMath can be used. See beginning of libtommath.c for details on benefits
# and drawbacks of this option.
#CONFIG_INTERNAL_LIBTOMMATH=y
#ifndef CONFIG_INTERNAL_LIBTOMMATH
#LTM_PATH=/usr/src/libtommath-0.39
#CFLAGS += -I$(LTM_PATH)
#LIBS += -L$(LTM_PATH)
#LIBS_p += -L$(LTM_PATH)
#endif
# At the cost of about 4 kB of additional binary size, the internal LibTomMath
# can be configured to include faster routines for exptmod, sqr, and div to
# speed up DH and RSA calculation considerably
#CONFIG_INTERNAL_LIBTOMMATH_FAST=y

# Include NDIS event processing through WMI into wpa_supplicant/wpasvc.
# This is only for Windows builds and requires WMI-related header files and
# WbemUuid.Lib from Platform SDK even when building with MinGW.
#CONFIG_NDIS_EVENTS_INTEGRATED=y
#PLATFORMSDKLIB="/opt/Program Files/Microsoft Platform SDK/Lib"

# Add support for new DBus control interface
# (fi.w1.wpa_supplicant1)
CONFIG_CTRL_IFACE_DBUS_NEW=y

# Add introspection support for new DBus control interface
CONFIG_CTRL_IFACE_DBUS_INTRO=y

# Add support for loading EAP methods dynamically as shared libraries.
# When this option is enabled, each EAP method can be either included
# statically (CONFIG_EAP_<method>=y) or dynamically (CONFIG_EAP_<method>=dyn).
# Dynamic EAP methods are build as shared objects (eap_*.so) and they need to
# be loaded in the beginning of the wpa_supplicant configuration file
# (see load_dynamic_eap parameter in the example file) before being used in
# the network blocks.
#
# Note that some shared parts of EAP methods are included in the main program
# and in order to be able to use dynamic EAP methods using these parts, the
# main program must have been build with the EAP method enabled (=y or =dyn).
# This means that EAP-TLS/PEAP/TTLS/FAST cannot be added as dynamic libraries
# unless at least one of them was included in the main build to force inclusion
# of the shared code. Similarly, at least one of EAP-SIM/AKA must be included
# in the main build to be able to load these methods dynamically.
#
# Please also note that using dynamic libraries will increase the total binary
# size. Thus, it may not be the best option for targets that have limited
# amount of memory/flash.
#CONFIG_DYNAMIC_EAP_METHODS=y

# IEEE Std 802.11r-2008 (Fast BSS Transition) for station mode
CONFIG_IEEE80211R=y

# Add support for writing debug log to a file (/tmp/wpa_supplicant-log-#.txt)
CONFIG_DEBUG_FILE=y

# Send debug messages to syslog instead of stdout
CONFIG_DEBUG_SYSLOG=y
# Set syslog facility for debug messages
#CONFIG_DEBUG_SYSLOG_FACILITY=LOG_DAEMON

# Add support for sending all debug messages (regardless of debug verbosity)
# to the Linux kernel tracing facility. This helps debug the entire stack by
# making it easy to record everything happening from the driver up into the
# same file, e.g., using trace-cmd.
#CONFIG_DEBUG_LINUX_TRACING=y

# Add support for writing debug log to Android logcat instead of standard
# output
#CONFIG_ANDROID_LOG=y

# Enable privilege separation (see README 'Privilege separation' for details)
#CONFIG_PRIVSEP=y

# Enable mitigation against certain attacks against TKIP by delaying Michael
# MIC error reports by a random amount of time between 0 and 60 seconds
#CONFIG_DELAYED_MIC_ERROR_REPORT=y

# Enable tracing code for developer debugging
# This tracks use of memory allocations and other registrations and reports
# incorrect use with a backtrace of call (or allocation) location.
#CONFIG_WPA_TRACE=y
# For BSD, uncomment these.
#LIBS += -lexecinfo
#LIBS_p += -lexecinfo
#LIBS_c += -lexecinfo

# Use libbfd to get more details for developer debugging
# This enables use of libbfd to get more detailed symbols for the backtraces
# generated by CONFIG_WPA_TRACE=y.
#CONFIG_WPA_TRACE_BFD=y
# For BSD, uncomment these.
#LIBS += -lbfd -liberty -lz
#LIBS_p += -lbfd -liberty -lz
#LIBS_c += -lbfd -liberty -lz

# wpa_supplicant depends on strong random number generation being available
# from the operating system. os_get_random() function is used to fetch random
# data when needed, e.g., for key generation. On Linux and BSD systems, this
# works by reading /dev/urandom. It should be noted that the OS entropy pool
# needs to be properly initialized before wpa_supplicant is started. This is
# important especially on embedded devices that do not have a hardware random
# number generator and may by default start up with minimal entropy available
# for random number generation.
#
# As a safety net, wpa_supplicant is by default trying to internally collect
# additional entropy for generating random data to mix in with the data fetched
# from the OS. This by itself is not considered to be very strong, but it may
# help in cases where the system pool is not initialized properly. However, it
# is very strongly recommended that the system pool is initialized with enough
# entropy either by using hardware assisted random number generator or by
# storing state over device reboots.
#
# wpa_supplicant can be configured to maintain its own entropy store over
# restarts to enhance random number generation. This is not perfect, but it is
# much more secure than using the same sequence of random numbers after every
# reboot. This can be enabled with -e<entropy file> command line option. The
# specified file needs to be readable and writable by wpa_supplicant.
#
# If the os_get_random() is known to provide strong random data (e.g., on
# Linux/BSD, the board in question is known to have reliable source of random
# data from /dev/urandom), the internal wpa_supplicant random pool can be
# disabled. This will save some in binary size and CPU use. However, this
# should only be considered for builds that are known to be used on devices
# that meet the requirements described above.
#CONFIG_NO_RANDOM_POOL=y

# Should we attempt to use the getrandom(2) call that provides more reliable
# yet secure randomness source than /dev/random on Linux 3.17 and newer.
# Requires glibc 2.25 to build, falls back to /dev/random if unavailable.
#CONFIG_GETRANDOM=y

# IEEE 802.11ac (Very High Throughput) support (mainly for AP mode)
CONFIG_IEEE80211AC=y

# Wireless Network Management (IEEE Std 802.11v-2011)
# Note: This is experimental and not complete implementation.
#CONFIG_WNM=y

# Interworking (IEEE 802.11u)
# This can be used to enable functionality to improve interworking with
# external networks (GAS/ANQP to learn more about the networks and network
# selection based on available credentials).
CONFIG_INTERWORKING=y

# Hotspot 2.0
CONFIG_HS20=y

# Enable interface matching in wpa_supplicant
#CONFIG_MATCH_IFACE=y

# Disable roaming in wpa_supplicant
#CONFIG_NO_ROAMING=y

# AP mode operations with wpa_supplicant
# This can be used for controlling AP mode operations with wpa_supplicant. It
# should be noted that this is mainly aimed at simple cases like
# WPA2-Personal while more complex configurations like WPA2-Enterprise with an
# external RADIUS server can be supported with hostapd.
CONFIG_AP=y

# P2P (Wi-Fi Direct)
# This can be used to enable P2P support in wpa_supplicant. See README-P2P for
# more information on P2P operations.
CONFIG_P2P=y

# Enable TDLS support
CONFIG_TDLS=y

# Wi-Fi Display
# This can be used to enable Wi-Fi Display extensions for P2P using an external
# program to control the additional information exchanges in the messages.
CONFIG_WIFI_DISPLAY=y

# Autoscan
# This can be used to enable automatic scan support in wpa_supplicant.
# See wpa_supplicant.conf for more information on autoscan usage.
#
# Enabling directly a module will enable autoscan support.
# For exponential module:
#CONFIG_AUTOSCAN_EXPONENTIAL=y
# For periodic module:
#CONFIG_AUTOSCAN_PERIODIC=y

# Password (and passphrase, etc.) backend for external storage
# These optional mechanisms can be used to add support for storing passwords
# and other secrets in external (to wpa_supplicant) location. This allows, for
# example, operating system specific key storage to be used
#
# External password backend for testing purposes (developer use)
#CONFIG_EXT_PASSWORD_TEST=y
# File-based backend to read passwords from an external file.
#CONFIG_EXT_PASSWORD_FILE=y

# Enable Fast Session Transfer (FST)
#CONFIG_FST=y

# Enable CLI commands for FST testing
#CONFIG_FST_TEST=y

# OS X builds. This is only for building eapol_test.
#CONFIG_OSX=y

# Automatic Channel Selection
# This will allow wpa_supplicant to pick the channel automatically when channel
# is set to "0".
#
# TODO: Extend parser to be able to parse "channel=acs_survey" as an alternative
# to "channel=0". This would enable us to eventually add other ACS algorithms in
# similar way.
#
# Automatic selection is currently only done through initialization, later on
# we hope to do background checks to keep us moving to more ideal channels as
# time goes by. ACS is currently only supported through the nl80211 driver and
# your driver must have survey dump capability that is filled by the driver
# during scanning.
#
# TODO: In analogy to hostapd be able to customize the ACS survey algorithm with
# a newly to create wpa_supplicant.conf variable acs_num_scans.
#
# Supported ACS drivers:
# * ath9k
# * ath5k
# * ath10k
#
# For more details refer to:
# http://wireless.kernel.org/en/users/Documentation/acs
#CONFIG_ACS=y

# Support Multi Band Operation
#CONFIG_MBO=y

# Fast Initial Link Setup (FILS) (IEEE 802.11ai)
#CONFIG_FILS=y
# FILS shared key authentication with PFS
#CONFIG_FILS_SK_PFS=y

# Support RSN on IBSS networks
# This is needed to be able to use mode=1 network profile with proto=RSN and
# key_mgmt=WPA-PSK (i.e., full key management instead of WPA-None).
CONFIG_IBSS_RSN=y

# External PMKSA cache control
# This can be used to enable control interface commands that allow the current
# PMKSA cache entries to be fetched and new entries to be added.
#CONFIG_PMKSA_CACHE_EXTERNAL=y

# Mesh Networking (IEEE 802.11s)
#CONFIG_MESH=y

# Background scanning modules
# These can be used to request wpa_supplicant to perform background scanning
# operations for roaming within an ESS (same SSID). See the bgscan parameter in
# the wpa_supplicant.conf file for more details.
# Periodic background scans based on signal strength
CONFIG_BGSCAN_SIMPLE=y
# Learn channels used by the network and try to avoid bgscans on other
# channels (experimental)
#CONFIG_BGSCAN_LEARN=y

# Opportunistic Wireless Encryption (OWE)
# Experimental implementation of draft-harkins-owe-07.txt
#CONFIG_OWE=y

# Device Provisioning Protocol (DPP) (also known as Wi-Fi Easy Connect)
CONFIG_DPP=y
# DPP version 2 support
CONFIG_DPP2=y
# DPP version 3 support (experimental and still changing; do not enable for
# production use)
#CONFIG_DPP3=y

# Wired equivalent privacy (WEP)
# WEP is an obsolete cryptographic data confidentiality algorithm that is not
# considered secure. It should not be used for anything anymore. The
# functionality needed to use WEP is available in the current wpa_supplicant
# release under this optional build parameter. This functionality is subject to
# be completely removed in a future release.
#CONFIG_WEP=y

# Remove all TKIP functionality
# TKIP is an old cryptographic data confidentiality algorithm that is not
# considered secure. It should not be used anymore for anything else than a
# backwards compatibility option as a group cipher when connecting to APs that
# use WPA+WPA2 mixed mode. For now, the default wpa_supplicant build includes
# support for this by default, but that functionality is subject to be removed
# in the future.
#CONFIG_NO_TKIP=y

# Pre-Association Security Negotiation (PASN)
# Experimental implementation based on IEEE P802.11z/D2.6 and the protocol
# design is still subject to change. As such, this should not yet be enabled in
# production use.
#CONFIG_PASN=y

STA : Compile wpa_supplicant

Note

  • Compile supplicant by running make command

 
test:~$ sudo make

STA : Check for the binaries created

Note

  • Make sure wpa_supplicant and wpa_cli are present

 
test:~$ ls
wpa_supplicant
wpa_cli

STA : Create run_supplicant.conf

 
test:~$ sudo vim ./run_supplicant.conf

ctrl_interface=/run/wpa_supplicant
update_config=1
network={
ssid="test_wpa2_ng"
proto=WPA2
key_mgmt=WPA-PSK
psk="12345678"
}

STA : Run wpa_supplicant

 
test:~$ sudo ./wpa_supplicant -Dnl80211 -i wlp2s0 -c ./run_supplicant.conf
Successfully initialized wpa_supplicant

STA : Check ps status and confirm wpa_supplicant process is running

 
test:~$ ps -N | grep -i wpa
36164 pts/2    00:00:00 wpa_supplicant

STA : Check connection status using wpa_cli

Note

  • wpa_state=COMPLETED indicates successful connection. Check output of status

 
test:~$ sudo ./wpa_cli -i wlan1
> status

  • Download file to check wireshark output

Packet capture in WPA2 mode

  • In this section — You will learn how to decrypt WPA2-encrypted frames in an 802.11ng network (a mixed mode supporting both 802.11n and 802.11g devices).

  • 802.11ng uses HT (High Throughput) capabilities from 802.11n while maintaining backward compatibility with 802.11g.

  • Decryption enables you to view upper-layer protocols such as ARP, ICMP, TCP, and UDP, which are otherwise hidden under AES-CCMP encryption.

  • Wireshark requires both the WPA2 passphrase and the 4-Way Handshake frames to derive the necessary session keys for decrypting the data.

Decrypting WPA2-Encrypted Frames in Wireshark

  1. Open the Capture File

    • Launch Wireshark and open your .pcap or .pcapng file containing the captured 802.11 frames.

    • Ensure your capture includes the 4-Way Handshake frames between STA and AP — these are essential for deriving the PTK (Pairwise Transient Key)

    • Without these, Wireshark cannot derive the encryption key for decryption.

  2. Enable Decryption

    • Go to Edit → Preferences → Protocols → IEEE 802.11.

    • Check “Enable decryption”.

    • Click “Edit” under Decryption Keys.

    Decryption1 in Wireshark

  3. Add the WPA2 Passphrase

    • In the Decryption Keys dialog: * Click “+” to add a new key. * Choose Key type: wpa2-pwd * Enter your passphrase and SSID in this format: wpa2-pwd:yourpassword:yourSSID

    Decryption2 in Wireshark

  4. Apply the Key and Refresh

    • Click OK to save the key.

    • Wireshark will automatically decrypt frames that match the key.

    • You should now see decrypted data frames, including ARP, ICMP, and IP payloads, in plain text.

    • Decrypted frames show “Protected flag: False” in the IEEE 802.11 header section.

  • In this section, you will verify connectivity and frame exchange using the Wireshark capture.

Beacon Packet Analysis

  1. Check if AP is Beaconing

    • The Beacon Frame is periodically broadcast by the AP (every ~100 ms) to announce the presence of a network.

    • In WPA2 mode, the Beacon contains the RSN (Robust Security Network) Information Element (Tag Number: 48)

    • This indicates that the AP requires encryption and authentication for client associations.

  2. Verify the Beacon Interval (100 ms).

    • Indicates how frequently the AP transmits Beacon frames (typically 100 TU ≈ 102.4 ms).

    • Consistent Beacon intervals confirm stable AP operation.

    Beacon interval (100ms) in Wireshark

  3. Check the Subtype field in the Beacon frame.

    • The Subtype identifies the frame as a Beacon (Subtype = 8).

    • Correct Subtype ensures Wireshark is recognizing the management frame correctly.

    Subtype check in Wireshark

  4. Verify that the Data Rate includes 1 Mbps (mandatory for 802.11ng).

    • 802.11ng requires at least 1 Mbps support for legacy devices.

    • If 1 Mbps is missing, some STAs may fail to connect.

    Beacon frame data rate check in Wireshark

  5. Check if the Receiver Address (RA) is Broadcast address.

    • Beacon frames are sent to the broadcast address FF:FF:FF:FF:FF:FF so that all nearby STAs can receive them.

    • This confirms that the beacon is not targeted to a specific STA but intended for all devices in range.

    • No ACK is sent for Beacon frames because they are broadcast.

    Receiver address in Beacon frame

  6. Capability Information

    • Capability Info = 0x0411

    • Bit-level breakdown: - ESS: 1 → Transmitter is an AP - Privacy: 1 → Encryption enabled (WPA2 active) - Short Slot Time: 1 → 9 µs slot duration for higher efficiency - QoS: 0 → QoS not indicated in this frame

    • Confirms the AP supports WPA2 with short slot time enabled for 802.11g/n mixed mode.

    Capability Information field in 802.11ng

  7. Verify Supported Rates.

    • Tag: Supported Rates = 1(B), 2(B), 5.5(B), 11(B), 6, 9, 12, 18 Mbps

    • Indicates both 802.11b (DSSS) and 802.11g (OFDM) rate support.

    • Ensures AP compatibility with both 802.11b and 802.11ng clients.

    Supported rates in Beacon frame

  8. Check the DS Parameter Set (Channel Information)

    • The DS Parameter Set indicates the channel number (e.g., Channel 6 at 2437 MHz).

    • Ensures that both AP and STA operate on the same frequency band.

    DS Parameter Set in Beacon frame

  9. Check the SSID Tag

    • The SSID field must match the configured network name(e.g., “test_wpa2_ng”).

    • Ensures the AP is broadcasting the correct SSID and the STA can identify it.

    SSID Parameter in Beacon frame

  10. TIM (Traffic Indication Map)

  • Tag: TIM → DTIM 1 of 2 bitmap

  • Indicates how often the AP includes Delivery Traffic Indication Messages (DTIM) for power-saving clients.

  • DTIM 1/2 → Every second beacon carries broadcast/multicast delivery indication.

TIM field in Beacon frame

  1. Check the ERP Information Element.

  • The ERP (Extended Rate PHY) element is unique to 802.11ng and provides compatibility with 802.11b.

  • It contains:

    • Non-ERP Present (bit 0) → indicates if 802.11b devices are detected.

    • Use Protection (bit 1) → enables protection (RTS/CTS) if mixed devices exist.

    • Barker Preamble Mode (bit 2) → ensures compatibility with older stations.

  • Helps the AP coordinate transmissions in mixed b/g/n networks.

ERP Information element in Beacon frame

  1. Check Extended Supported Rates.

  • Tag: Extended Supported Rates → 24, 36, 48, 54 Mbps

  • Confirms support for higher OFDM data rates.

  • Completes the 802.11ng data rate range.

Extended supported rates in 802.11ng Beacon

  1. Inspect the RSN (Robust Security Network) Information Element

  • Tag: RSN Information (Tag Number: 48), Length: 20

  • Defines WPA2 security configuration:

    • RSN Version: 1

    • Group Cipher Suite: 00:0f:ac → AES (CCMP)

    • Pairwise Cipher Suite Count: 1 → AES (CCM)

    • Auth Key Management (AKM) Suite Count: 1 → PSK (Pre-Shared Key)

    • RSN Capabilities: 0x000c → Pre-Auth Disabled, No MFP, 1 Replay Counter per key

  • Confirms AP uses WPA2-PSK with AES-CCMP encryption (the most secure WPA2 mode).

RSN Information Element in Beacon

  1. Check Supported Operating Classes

  • Indicates regulatory and operating class information for frequency bands.

  • Useful for determining region and supported channels.

Supported Operating Classes field

  1. HT Capabilities (802.11n)

  • Tag: HT Capabilities (802.11n D1.10)

  • Defines 802.11n features such as: - Supported MCS Set: Modulation and Coding Schemes - Channel Width: 20 MHz or 40 MHz - Short GI: Enables reduced guard interval for faster data - Spatial Streams: Multiple antennas for MIMO operation

  • Confirms High Throughput (HT) support in the AP.

HT Capabilities IE

  1. HT Information Element

  • Tag: HT Information (802.11n D1.10)

  • Provides operation parameters for HT mode: - Primary Channel: 6 - Secondary Channel Offset: None (20 MHz only) - HT Protection: Enabled for mixed mode operation - Operating Mode: Mixed 802.11b/g/n coexistence

  • Helps STAs adjust their transmission behavior for compatibility.

HT Information element in 802.11ng Beacon

  1. Check Extended Capabilities

  • Tag: Extended Capabilities (8 bytes)

  • May include optional features such as: - BSS Transition Management - 20/40 MHz Coexistence - QoS Map, WNM, or TDLS support

  • Enhances roaming and management functions in modern networks.

Extended Capabilities field

  1. Vendor Specific (WMM/WME Parameter Element)

  • Tag: Vendor Specific – Microsoft Corp.: WMM/WME Parameter Element

  • Defines QoS parameters for prioritized traffic: - AC_BE (Best Effort) - AC_VI (Video) - AC_VO (Voice)

  • Confirms WMM (Wi-Fi Multimedia) is enabled, supporting QoS for real-time applications.

Vendor Specific WMM/WME element

Probe Request Packet Analysis

  1. Check if STA is sending Probe Request packet

    • A Probe Request frame is sent by the STA to actively discover available networks.

    • It advertises the STA’s supported data rates, security capabilities, and other features.

    • APs that match the SSID (or accept broadcast requests) respond with Probe Response frames.

  2. Check the Frame Subtype to confirm it is a Probe Request.

    • In Wireshark, the Frame Control field indicates the subtype.

    • Probe Request frames should have subtype 0x0004.

    Probe Request subtype in Wireshark

  3. Verify the Source Address in the Probe Request.

    • Source Address should match the STA’s MAC address.

    • This ensures the frame is indeed coming from the correct STA.

    Probe Request source address

  4. Verify the Receiver Address in the Probe Request.

    • Receiver Address should be the broadcast address (FF:FF:FF:FF:FF:FF).

    • This allows all APs on the channel to receive the request.

    • No ACK is expected for broadcast Probe Requests.

    Probe Request receiver address

  5. Check the SSID field in the Probe Request.

    • For general network discovery, SSID should be set to Wildcard SSID(empty).

    • A specific SSID can limit scanning to only that AP.

    Probe Request SSID field

  6. Verify Supported Rates and Extended Supported Rates.

    • Supported Rates: 6, 9, 12, 18, 24, 36, 48, 54 Mbps

    • Extended Supported Rates: (if present) may include legacy 1, 2, 5.5, 11 Mbps for 802.11b/g compatibility.

    • These rates confirm dual-band backward compatibility.

    Supported Rates in Probe Request

  7. Check HT Capabilities (802.11n) field.

    • Indicates STA supports High Throughput (HT) features.

    • Tag Number: 45 (HT Capabilities)

    • Tag Length: 26

    • Fields: - HT Capabilities Info: 0x19ef → enables Short GI, Greenfield, STBC, etc. - A-MPDU Parameters: 0x13 → A-MPDU length limit and spacing. - Rx Supported MCS Set: Indicates supported MCS indexes (MCS 0–7 typically). - HT Extended Capabilities: 0x0000 - Tx Beamforming Capabilities: 0x00000000 (no explicit beamforming). - Antenna Selection (ASEL): 0x00

    • Confirms STA supports 802.11n High Throughput mode.

    HT Capabilities in Probe Request

  8. Inspect the Extended Capabilities tag.

    • Contains optional flags for QoS, coexistence, and advanced features.

    • Tag Number: 127

    • Tag Length: 11 octets

    • Example Values: - 0x04, 0x00, 0x00, 0x00, 0x01, 0x00, 0x40, 0x0040, 0x00, 0x20

    • Indicates: - Support for QoS Management - 20/40 MHz Coexistence - Interworking and extended security options

    Extended Capabilities field

  9. VHT Capabilities (802.11ac)

    • Optional, but some 802.11ng devices include VHT info for backward compatibility.

    • Tag Number: 191 (VHT Capabilities)

    • Tag Length: 12

    • Example: - VHT Capabilities Info: 0x03d071b2 - VHT Supported MCS Set: Indicates support for higher data rates (e.g., 256-QAM).

    • Shows device readiness for 802.11ac compatibility (Very High Throughput).

    VHT Capabilities in Probe Request

Probe Response Packet Analysis

  1. Check if AP is sending Probe Response packet

    • The AP responds to a STA’s Probe Request with its SSID, channel, and supported capabilities.

    • In 802.11ng mode, this includes HT (High Throughput) and QoS (WMM) support.

  2. Check the Frame Subtype to confirm it is a Probe Response.

    • Subtype identifies the frame as a Probe Response (Subtype = 5).

    • Ensures Wireshark is correctly capturing AP responses.

    Probe Response subtype in Wireshark

  3. Verify the Source Address in the Probe Response.

    • Source Address should be the MAC of the AP.

    • Confirms the frame is coming from the correct AP.

    Source address in Probe Response

  4. Verify the Receiver Address in the Probe Response.

    • Receiver Address should be the MAC of the requesting STA.

    • Confirms the response is unicast and directed to the correct STA.

    • Probe Responses are unicast to the requesting STA, so an ACK is expected from the STA.

    Receiver address in Probe Response

  5. Check the SSID field in the Probe Response.

    • SSID must match the AP configuration.

    • Confirms the AP is broadcasting the expected network name.

    SSID in Probe Response

  6. Check Capability Information field for ESS=1 in the Probe Response.

    • ESS bit indicates the AP is part of an infrastructure BSS.

    • Must be set to 1 for proper STA-AP communication.

    ESS bit in Capability Information in Probe Response

  7. Check Capability Information field for Privacy=1 in the Probe Response.

    • Privacy bit (bit 4) = 1 indicates WPA2 is enabled on this AP.

    • Confirms that security is configured at the AP level.

    Privacy bit in Capability Information in Probe Response

  8. Check Capability Information field for Short Slot Time = 1 and QoS field in the Probe Response.

    • Short Slot Time = 1 → Enabled for 802.11ng high-rate operation.

    • QoS = 0 → QoS support not signaled in Capability Info but provided via WMM tag.

    Short slot time in Capability Information in Probe Response

  9. Verify Supported Rates in the Probe Response.

    • Supported Rates: 1, 2, 5.5, 11, 6, 9, 12, 18 Mbps.

    • Indicates 802.11b/g compatibility.

    Supported Rates in Probe Response

  10. Verify DS Parameter Set (channel assignment) in the Probe Response.

  • DS Parameter indicates the AP’s operating channel.

  • Confirms the STA knows which channel to use to associate with the AP.

DS Parameter Set (channel) in Probe Response

  1. Check ERP Information (New in 802.11ng)

    • The ERP Information element is unique to 802.11ng and ensures backward compatibility with 802.11b/g.

    • It includes:

      • Non-ERP Present bit – Indicates if older 802.11b devices are in the network.

      • Use Protection bit – Enables CTS-to-Self or RTS/CTS when 802.11b stations are active.

      • Barker Preamble bit – Shows whether the AP supports short preamble.

    ERP Information in Probe Response

  2. Check Extended Supported Rates

    • Extended Rates: 24, 36, 48, 54 Mbps.

    • Confirms full-rate support up to 54 Mbps (OFDM-based 802.11ng operation).

    Extended Supported Rates in Probe Response

  3. Check the RSN (Robust Security Network) Information Element.

    • Defines WPA2 encryption and authentication settings.

    • Tag Number: 48

    • RSN Version: 1

    • Group Cipher Suite: AES (CCMP)

    • Pairwise Cipher Suite: AES (CCMP)

    • Auth Key Management: PSK (Pre-Shared Key)

    • RSN Capabilities: 0x000c → optional management frame protection supported.

    • Confirms AP operates in WPA2-PSK (AES) mode.

    RSN Information Element (WPA2)

  4. HT Capabilities (802.11n)

    • Tag Number: 45

    • Tag Length: 26

    • HT Capabilities Info: 0x000c → 20 MHz channel width, short GI support.

    • A-MPDU Parameters: 0x17 → max A-MPDU length and spacing.

    • Rx Supported MCS Set: MCS 0–7 (single spatial stream).

    • TxBF Capabilities: 0x00000000 (no explicit beamforming).

    • Confirms 802.11n High Throughput support.

    HT Capabilities in Probe Response

  5. HT Information (802.11n)

    • Primary Channel: 6

    • Secondary Channel Offset: 0 (20 MHz channel width).

    • HT Protection: None → no legacy devices detected.

    • Confirms AP’s operational HT parameters.

    HT Information field

  6. Check Extended Capabilities

    • Advertises advanced features supported by the AP.

    • Common capabilities: QoS, BSS transition, Spectrum Management, etc.

    • Not directly part of WPA2 but indicates enhanced 802.11ng functionality.

    Extended Capabilities field

  7. WMM (Wi-Fi Multimedia) Parameter Element

    • Tag Number: 221 (Vendor Specific)

    • OUI: 00:50:f2 (Microsoft Corp.)

    • Type: WMM/WME (0x02) → QoS enabled.

    • Version: 1

    • WME QoS Info: 0x01 → indicates WMM active.

    • Access Categories: BE, BK, VI, VO each with their own AIFSN, CWmin/max, and TXOP values.

    • Confirms QoS prioritization for multimedia traffic (802.11e).

    WMM Parameter Element in Probe Response

Acknowledgement after Probe Response Packet Analysis

  • After the AP sends a Probe Response, the STA must acknowledge it with an Acknowledgement frame.

  • This ACK confirms successful reception of the Probe Response.

  • The ACK is a Control frame (not Management or Data).

  • It is transmitted immediately after a SIFS (Short Interframe Space) interval.

  1. Check the Acknowledgement - Frame Subtype

    • When the AP sends a unicast Probe Response, the STA sends an ACK frame

    • ACK frames have Subtype = 13 in 802.11.

    ACK frame subtype in Wireshark

  2. Check the Acknowledgement - Receiver Address

    • Receiver Address of the ACK is the AP’s MAC address (i.e., the source of the Probe Response).

    • Confirms that the ACK is directed to the correct transmitting AP.

    ACK receiver address in Wireshark

Authentication Request Packet Analysis (WPA2 - 802.11ng)

  1. Check if STA is sending Authentication Request packet

    • The Station (STA) initiates the authentication process after receiving a Probe Response from the Access Point (AP).

    • Even in WPA2-802.11n mode, this uses Open System Authentication (Algorithm = 0) — no challenge/response occurs.

    • Encryption is not yet applied at this stage; it begins later in the 4-Way Handshake.

    • The purpose is to confirm that both STA and AP are ready to proceed with association.

    • Because this is a unicast management frame, the AP immediately sends an ACK to confirm reception.

  2. Check the Frame Subtype

    • The Subtype identifies the frame as an Authentication frame (Subtype = 11).

    • Confirms that this packet is part of the authentication management exchange.

    Authentication Request frame subtype

  3. Verify the Source Address in the Authentication Request packet.

    • The Source Address should be the STA’s MAC address.

    • Confirms the authentication initiation is coming from the STA.

    Authentication Request source address

  4. Verify the Receiver Address in the Authentication Request packet.

    • The Receiver Address should be the AP’s MAC address.

    • This confirms the STA is directly targeting the AP for authentication.

    Authentication Request receiver address

  5. Check the Authentication Algorithm field in the Authentication Request packet.

    • Authentication Algorithm = 0 (Open System).

    • Even with WPA2/WPA3 security, this field remains Open System, since encryption happens later using CCMP and PTK keys.

    • WPA2 and WPA3 differ only in key exchange, not this authentication step.

    Authentication Algorithm in Authentication Request

  6. Check the Authentication Sequence Number in the Authentication Request packet.

    • Sequence Number = 1 indicates this is the Authentication Request (first message).

    • The AP will respond with sequence number 2 (Authentication Response).

    • Ensures the correct ordering of authentication messages.

    Authentication sequence number in Wireshark

  7. Verify the Status Code in the Authentication Request packet.

    • The Status Code field in the Authentication Request is usually 0 or not used.

    • It is meaningful mainly in responses, but Wireshark may still display it as 0 (Successful) by default.

    • This ensures that the STA is initiating authentication without reporting an error.

    Authentication status code

Acknowledgement after Authentication Request Packet Analysis

  • After the STA sends an Authentication Request, the AP must acknowledge it with an ACK frame.

  • This ACK confirms successful reception of the Authentication Request before the AP sends the Authentication Response.

  • The ACK is a Control frame (not Management or Data).

  • It is transmitted immediately after a SIFS (Short Interframe Space) interval.

  1. Check the ACK Frame Subtype.

    • Since the Authentication Request is unicast, the AP responds with an ACK frame.

    • The ACK has Subtype = 13 in 802.11.

    • Confirms that the AP successfully received the Authentication Request.

    ACK frame subtype for Authentication Request

  2. Verify the ACK Receiver Address.

    • The ACK frame’s Receiver Address should match the STA’s MAC address (the source of the Authentication Request).

    • Confirms the AP has acknowledged the STA correctly.

    ACK receiver address for Authentication Request

Authentication Response Packet Analysis (WPA2 Mode)

  1. Check if AP is sending Authentication Response

    • After receiving the Authentication Request from the STA, the Access Point (AP) sends an Authentication Response.

    • Even though the PHY layer is 802.11n (HT mode), the authentication process is still performed using the Open System (Algorithm = 0) mechanism.

    • The actual WPA2 (RSN) key negotiation occurs later during the 4-Way Handshake after the association.

    • This frame ensures that the STA is permitted to associate with the AP and that both parties are synchronized at the MAC layer.

  2. Check the Frame Subtype

    • The Subtype field = 11 indicates it is an Authentication frame.

    • Ensures that the AP has correctly responded to the STA’s authentication attempt.

    Authentication Response frame subtype

  3. Verify Source Address

    • The Source Address should be the AP’s MAC address.

    • Confirms the Authentication Response is sent by the Access Point.

    Source address of Authentication Response

  4. Check the Receiver Address

    • The Receiver Address should be the STA’s MAC address (the device being authenticated).

    • Confirms that the AP is addressing the correct station.

    Receiver address of Authentication Response

  5. Check the BSSID Field

    • The BSSID must match the AP’s MAC address.

    • Confirms that this frame belongs to the correct Basic Service Set (BSS).

    • Useful when multiple APs operate on the same channel.

    BSSID in Authentication Response

  6. Check the Authentication Algorithm Number

    • Authentication Algorithm = 0 (Open System) — still used in 802.11n WPA2 mode.

    • WPA2 does not modify this step; encryption begins only after association.

    • Open System allows STA–AP connection before the secure key exchange phase.

    Authentication Algorithm field

  7. Check the Authentication Sequence Number

    • This indicates which step of the authentication process the frame represents.

    • For the second frame, Sequence Number = 2, confirming it’s the AP’s response to the STA.

    • The exchange completes here in WPA2 (2-step Open System Authentication).

    Authentication Sequence Number field

  8. Check the Status Code

    • The Status Code field indicates the success or failure of the authentication step.

    • For this challenge response, the Status Code = 0 (Successful), as the AP is providing the challenge.

    • Non-zero codes indicate an error or failure.

    Authentication Response Status Code

Acknowledgement after Authentication Response Packet Analysis

  • Once the AP sends the Authentication Response, the STA acknowledges it using an ACK frame.

  • This ensures reliable delivery of the Authentication Response before moving on to the Association stage.

  1. Check the ACK Frame Subtype.

    • The ACK frame has Subtype = 13, identifying it as an acknowledgment.

    • Confirms the STA received the Authentication Response correctly.

    ACK subtype after Authentication Response

  2. Verify the ACK Receiver Address.

    • The Receiver Address should be the AP’s MAC address (source of the Authentication Response).

    • Confirms that the STA is acknowledging the correct transmitter.

    Receiver address of ACK after Authentication Response

Association Request Packet Analysis

  1. Check if STA is sending Association Request

    • After the Open System Authentication exchange, the STA sends an Association Request frame to the AP.

    • This frame advertises STA capabilities such as 802.11n HT support, QoS, and WPA2 RSN parameters.

    • It is a Management frame with Subtype = 0.

    • Privacy bit = 1 indicates that the STA supports encryption (WPA2).

    • Being a unicast frame, it will be acknowledged by the AP.

  2. Check the Frame Subtype

    • Subtype = 0 identifies the frame as an Association Request.

    • Ensures Wireshark captures the correct management frame.

    Association Request Subtype

  3. Verify Source Address

    • Source Address = STA MAC address.

    • Confirms the frame is sent by the correct STA.

    Source address in Association Request

  4. Check the Receiver Address

    • Receiver Address = AP MAC address.

    • Ensures the frame is targeted to the correct AP.

    Receiver address in Association Request

  5. Verify BSSID

    • BSSID = AP MAC address.

    • Confirms the frame is part of the correct Basic Service Set.

    BSSID in Association Request

  6. Check the Capability Information – Privacy bit

    • Privacy bit = 1 indicates WPA2 encryption is enabled.

    • This confirms that the STA supports encrypted data exchange after association

    Privacy bit in Capability Information

  7. Verify Capability Information – Short Preamble bit

    • Short Preamble bit indicates whether STA supports short preamble.

    • Helps verify compatibility with AP preamble configuration.

    Short Preamble bit in Capability Information

  8. Check the Listen Interval

    • Listen Interval defines how often the STA wakes to check for buffered frames at the AP.

    • Ensures power-saving and proper timing for STA-AP communication.

    Listen Interval in Association Request

  9. Verify SSID Field

    • SSID must match the AP’s network name.

    • Confirms that the STA is associating with the correct BSS.

    SSID in Association Request

  10. Check the Supported Rates and Extended Supported Rates

  • Supported Rates: 1, 2, 5.5, 11, 6, 9, 12, 18 Mbps

  • Indicates backward compatibility with both 802.11b/g PHY rates.

  • Extended Supported Rates: 24, 36, 48, 54 Mbps

  • Enables higher data throughput compatible with OFDM operation.

Supported Rates in Association Request

  1. RSN Information Element (WPA2 Security)

    • Tag Number = 48, identifies this as the RSN IE.

    • Defines the WPA2 (802.11i) security configuration: - Version: 1 - Group Cipher Suite: AES (CCMP) - Pairwise Cipher Suite: AES (CCMP) - Authentication Key Management (AKM): PSK - RSN Capabilities: 0x0000 (No PMF or pre-authentication advertised)

    • Confirms WPA2-PSK operation with AES encryption.

    RSN Information Element (WPA2) in 802.11n Association Request

  2. HT Capabilities (802.11n High Throughput)

    • Tag Number = 45, identifies HT Capabilities IE.

    • Key parameters: - HT Capabilities Info = 0x19ef → Supports short GI (Guard Interval), 20/40 MHz operation. - A-MPDU Parameters = 0x13 → Enables frame aggregation for higher efficiency. - MCS Set: Lists supported Modulation and Coding Schemes for MIMO. - Transmit Beamforming (TxBF): 0x00000000 → Not supported.

    • Confirms STA supports 802.11n high throughput features.

    HT Capabilities field in 802.11n Association Request

  3. Extended Capabilities

    • Tag Number = 127, length = 11 bytes.

    • Contains bits indicating advanced STA features: - Octet 1 (0x04): Indicates coexistence or additional channel support. - Octet 5 (0x01): May indicate support for interworking or QoS enhancements. - Octet 7 (0x40): Supports extended channel switching or WNM (Wireless Network Management). - Octet 11 (0x20): Potential support for 20/40 MHz operation notification.

    • Confirms STA supports extended management and coexistence features in 802.11n.

    Extended Capabilities in 802.11n Association Request

  4. Supported Operating Classes

    • Tag Number = 59, length = 21.

    • Current Operating Class: 81 → 2.407 GHz, Channels 1–13 (25 MHz spacing).

    • Alternate Classes: 81–129, covering both 2.4 GHz and 5 GHz bands.

    • Defines which frequency bands and channel widths the STA can operate in.

    Supported Operating Classes in 802.11n Association Request

  5. Vendor-Specific: WMM/WME Information Element

    • Tag Number = 221, OUI = 00:50:f2 (Microsoft).

    • Identifies WMM (Wi-Fi Multimedia) support: - Type = 2, Subtype = 0, Version = 1. - QoS Info = 0x00, indicating WMM capability but no U-APSD negotiation.

    • Confirms Quality of Service (QoS) support for prioritized traffic in 802.11n.

    WMM/WME Information Element in 802.11n Association Request

Acknowledgement after Association Request Packet Analysis

  • Since the Association Request is a unicast frame from the STA to the AP,the AP responds with an ACK frame to confirm successful reception.

  • The ACK is a Control frame (Subtype = 13) and ensures reliable MAC-layer delivery.

  • This ACK is sent immediately after a SIFS interval.

  1. Check the ACK Frame Subtype.

    • Subtype = 13 identifies the frame as an ACK.

    • Confirms the AP received the Association Request correctly.

    ACK subtype after Association Request

  2. Verify the ACK Receiver Address.

    • The Receiver Address of the ACK should be the STA’s MAC address (source of the Association Request).

    • Confirms that the AP is acknowledging the correct station.

    Receiver address of ACK after Association Request

Association Response Packet Analysis

  1. Check if AP is sending Association Response

    • The AP sends an Association Response frame after receiving a valid Association Request from the STA.

    • Confirms successful connection setup before starting the WPA2 4-Way Handshake.

    • Frame Type = Management (Type 0) Subtype = Association Response (1)

    • Sent unicast from AP → STA, and acknowledged by the STA.

  2. Check the Frame Subtype

    • Subtype = 1 identifies the frame as an Association Response.

    • Confirms that the AP has acknowledged the STA’s request to join the BSS.

    Association Response Subtype

  3. Verify Source Address

    • Source Address = AP MAC address.

    • Confirms the frame is transmitted from the AP.

    Source address in Association Response

  4. Check the Receiver Address

    • Receiver Address = STA MAC address.

    • Ensures the response is directed to the correct STA.

    Receiver address in Association Response

  5. Verify BSSID

    • BSSID = AP MAC address (same as Source).

    • Confirms that the response is part of the same BSS.

    BSSID in Association Response

  6. Check the Capability Information – Privacy bit

    • Privacy bit = 1 → indicates WPA2 encryption is enabled.

    • Confirms that subsequent data frames will use WPA2 protection.

    Privacy bit in Association Response

  7. Verify Capability Information – Short Preamble bit

    • Short Preamble bit indicates AP supports short preamble operation.

    • Confirms compatibility with STA’s preamble capabilities.

    Short Preamble bit in Association Response

  8. Check the Status Code

    • Status Code = 0 indicates Successful Association.

    • Other values indicate rejection (e.g., unsupported authentication or cipher).

    • Confirms that the STA is now allowed to proceed with WPA2 4-way handshake.

    Status code in Association Response

  9. Verify Association ID (AID)

    • AID uniquely identifies the STA within the BSS.

    • Typically a small integer (e.g., 1, 2, 3) assigned by the AP.

    • Confirms successful registration of the STA in the AP’s association table.

    • Used for managing buffered frames and identifying the STA in power-save mode.

    Association ID in Association Response

  10. Check the Supported Rates ,Extended Supported Rates

  • Lists data rates supported for backward compatibility (802.11b/g).

  • Supported Rates: 1, 2, 5.5, 11, 6, 9, 12, 18 Mbps

  • Extended Supported Rates: 24, 36, 48, 54 Mbps

  • Confirms coexistence with legacy devices.

Supported Rates in Association Response

  1. HT Capabilities (802.11n)

  • Tag Number: 45, length: 26 bytes

  • Introduced in 802.11n for high throughput operation (HT).

  • Key fields:

    • HT Capabilities Info (0x000C):

      Indicates 20/40 MHz support, short GI (guard interval), MIMO capability.

    • A-MPDU Parameters (0x17):

      Aggregated MPDU support; max AMPDU length exponent = 2, min spacing = 8 µs.

    • MCS Set:

      Lists supported Modulation and Coding Schemes (up to MCS7 per spatial stream).

  • Confirms that STA and AP support HT (High Throughput) mode, enabling up to 300 Mbps PHY rates.

HT Capabilities in Association Response

  1. HT Information (802.11n)

  • Tag Number: 61, length: 22 bytes

  • Describes HT channel usage and MCS set for operation.

  • Key fields: - Primary Channel: 6 - HT Info Subset 1: Channel width (20/40 MHz) and secondary channel offset. - HT Info Subset 2: RIFS, dual CTS protection, etc. - HT Info Subset 3: MCS set for control responses.

  • Confirms that 802.11n-specific PHY parameters are negotiated.

HT Information Element in Association Response

  1. Verify Extended Capabilities

  • Tag Number: 127, Length = 8 octets

  • Includes optional higher-layer capabilities like coexistence management, QoS support, and operating class awareness.

  • Example: Octet 1 = 0x04 indicates BSS Transition capability.

Extended Capabilities in Association Response

  1. WMM/WME Parameter Element (QoS)

  • Tag Number: 221 (Vendor Specific, Microsoft OUI 00:50:f2)

  • Type: WME (0x02), Subtype: Parameter Element (1), Version: 1

  • Defines QoS parameters for four Access Categories (ACs): - AC_BE (Best Effort): AIFSN=3, CWmin=15, CWmax=1023, TXOP=0 - AC_BK (Background): AIFSN=7, CWmin=15, CWmax=1023, TXOP=0 - AC_VI (Video): AIFSN=2, CWmin=7, CWmax=15, TXOP=94 - AC_VO (Voice): AIFSN=2, CWmin=3, CWmax=7, TXOP=47

  • WME QoS Info = 0x01 → indicates QoS support enabled on AP.

  • Confirms that 802.11n QoS and traffic prioritization are supported.

WMM/WME QoS Parameters in Association Response

Acknowledgement after Association Response Packet Analysis

  • The Association Response is a unicast frame, so the STA replies with an ACK.

  • This ensures the AP knows the STA successfully received its association confirmation.

  • The ACK is a Control frame (Subtype = 13) and follows a SIFS interval (~10 µs).

  1. Check the ACK Frame Subtype.

    • Subtype = 13 identifies the frame as an ACK.

    • Indicates successful MAC-layer acknowledgment from STA to AP.

    ACK subtype after Association Response

  2. Verify the ACK Receiver Address.

    • Receiver Address = AP MAC address (sender of the Association Response).

    • Confirms ACK is directed to the correct device.

    Receiver address of ACK after Association Response

Message 1 of 4 – EAPOL Key from AP to STA

  1. Check if AP is sending Message 1 of 4 – EAPOL Key

    • After successful authentication and association, the 4-Way Handshake begins.

    • This exchange derives the encryption keys (PTK, GTK) between the Access Point (AP) and Station (STA).

    • Message 1 is sent by the AP to the STA, containing the ANonce.

    • STA uses this ANonce + SNonce + PMK to compute the PTK.

    • Keys involved: - PMK (Pairwise Master Key): Derived from PSK or 802.1X. - PTK (Pairwise Transient Key): Derived using PMK + ANonce + SNonce + MACs. - GTK (Group Temporal Key): For broadcast/multicast traffic.

    • 802.11n adds QoS (Quality of Service) and HT (High Throughput) features to improve performance.

  2. Check the Frame Subtype

    • Type = 2 → Data frame

    • Subtype = 0 → Standard Data

    • Flags = 0x02 → Indicates Protected Frame, meaning payload is encrypted under WPA2.

    Message 1 Subtype

  3. Verify Source Address

    • Source Address = AP MAC address.

    • Confirms the frame is transmitted from the AP.

    Source address in Message 1

  4. Check the Receiver Address

    • Receiver Address = STA MAC address.

    • Ensures the response is directed to the correct STA.

    Receiver address in Message 1

  5. Verify BSSID

    • BSSID = AP MAC address (same as Source).

    • Confirms that the response is part of the same BSS.

    BSSID in Message 1

  6. QoS Control Field

    • QoS Control = 0x0007

    • Important bits: - TID (Traffic Identifier): 7 → Voice Access Category (highest priority). - EOSP (End of Service Period): 0 (no service period end). - Ack Policy: Normal ACK.

    • Indicates the frame belongs to a voice-priority traffic queue.

    QoS Control Field

  7. Check the EAPOL Version and Type

    • Version = 802.1X-2004 (2)

    • Type = Key (3) → Indicates that this is an EAPOL-Key frame used for key management.

    EAPOL version and type in Message 1

  8. Verify the Key Descriptor Type

    • Value = 2 → EAPOL RSN Key (WPA2).

    • Confirms that WPA2 key exchange is being performed.

    Key Descriptor Type in Message 1

  9. Check the Key Information Field

    • Key Descriptor Version: 2 → Uses AES Cipher, HMAC-SHA1 MIC.

    • Key Type: Pairwise → The key is for one STA, not for broadcast.

    • Install: Not set → STA should not install PTK yet.

    • Key ACK: Set → AP expects acknowledgment from STA.

    • Key MIC: Not set → No MIC because PTK not yet derived.

    • Secure = Not set

    Key Information field in Message 1

  10. Verify the Replay Counter

  • Value = 1 → Used to prevent replay attacks. Must increase with each new handshake message.

Replay counter in Message 1

  1. Check the ANonce (Authenticator Nonce)

  • Random 32-byte number generated by the AP.

  • Used by STA to derive the Pairwise Transient Key (PTK).

  • Ensures key uniqueness per session.

ANonce in Message 1

  1. Verify the Key Data Length

  • Value = 0 → No additional data present.

  • Confirms this is the first message containing only ANonce.

Key Data Length in Message 1

Acknowledgement after Message 1 Packet Analysis

  • The STA immediately sends an ACK frame after receiving Message 1.

  • Confirms correct reception of ANonce by STA.

  • ACK frames are control frames with no payload.

  • Ensures reliable delivery before next message is sent.

  1. Check the ACK Frame Subtype.

    • Subtype = 13 identifies the frame as an ACK.

    • Indicates successful MAC-layer acknowledgment from STA to AP.

    ACK subtype after Message 1

  2. Verify the ACK Receiver Address.

    • Receiver Address = AP MAC address (sender of the Association Response).

    • Confirms ACK is directed to the correct device.

    Receiver address of ACK after Message 1

Message 2 of 4 – EAPOL Key from STA to AP

  1. Check if STA is sending Message 2 of 4 – EAPOL Key

    • STA responds to Message 1 with Message 2 of the WPA2 4-Way Handshake.

    • It provides SNonce and MIC for the AP to verify PTK derivation.

    • Ensures STA participates in key derivation and confirms shared key material.

    • Keys involved: - PTK (Pairwise Transient Key): Derived using PMK + ANonce + SNonce + MACs. - MIC: Proves integrity and authenticity of STA’s response. - Key Data (WPA2 IE): STA indicates supported ciphers & AKM.

  2. Check the Frame Subtype

    • Type = 2 → Data frame

    • Subtype = 0 → Standard Data

    • Flags = 0x02 → Indicates Protected Frame, meaning payload is encrypted under WPA2.

    Message 2 Subtype

  3. Verify Source Address

    • Source Address = STA MAC address.

    • Confirms the frame is transmitted from the STA.

    Source address in Message 2

  4. Check the Receiver Address

    • Receiver Address = AP MAC address.

    • Ensures the response is directed to the correct AP.

    Receiver address in Message 2

  5. Verify BSSID

    • BSSID = AP MAC address.

    • Confirms that the response is part of the same BSS.

    BSSID in Message 2

  6. QoS Control Field

    • QoS Control = 0x0007

    • TID = 7 → Highest priority (Voice/Network Control).

    • Ack Policy = Normal ACK.

    • TXOP Duration = 0 → No TXOP requested.

    QoS Control Field

  7. Check the EAPOL Version and Type

    • Version = 802.1X-2001 (1)

    • Type = Key (3) * Indicates that this is an EAPOL-Key frame used for key management.

    EAPOL version and type in Message 2

  8. Verify the Key Descriptor Type

    • Value: 2 → RSN Key (WPA2)

    • Confirms WPA2 key exchange is active.

    Key Descriptor Type in Message 2

  9. Check the Key Information Field

    • Key Descriptor Version: 2 → Uses AES Cipher, HMAC-SHA1 MIC

    • Key Type: Pairwise → The key is for one STA, not for broadcast.

    • Install: Not set → STA should not install PTK yet.

    • Key ACK: Not Set → since STA does not expect acknowledgment

    • Key MIC: set → STA includes MIC for message integrity check.

    • Secure = Not set

    Key Information field in Message 2

  10. Verify the Replay Counter

  • Value = 1 * Matches Message 1 counter. * Ensures synchronization between AP and STA.

Replay counter in Message 2

  1. Check the SNonce (Supplicant Nonce)

  • Random 32-byte number generated by the STA.

  • Used along with ANonce, MAC addresses, and PMK to derive PTK.

SNonce in Message 2

  1. Verify the MIC Field

  • Message Integrity Code generated using the derived PTK.

  • Proves STA has successfully calculated the PTK and knows the correct PSK.

MIC verification in Message 2

  1. Check the Key Data (WPA2 Information Element)

  • Contains WPA2 version, supported cipher suites, and AKM (PSK).

  • Helps AP confirm STA’s supported encryption capabilities.

WPA2 Key Data in Message 2

Acknowledgement after Message 2 Packet Analysis

  • The AP sends an ACK confirming successful reception of STA’s response.

  • ACK ensures reliable exchange before sending Message 3.

  1. Check the ACK Frame Subtype.

    • Subtype = 13 identifies the frame as an ACK.

    • Indicates successful MAC-layer acknowledgment from STA to AP.

    ACK subtype after Message 2

  2. Verify the ACK Receiver Address.

    • Receiver Address = AP MAC address (sender of the Association Response).

    • Confirms ACK is directed to the correct device.

    Receiver address of ACK after Message 2

Message 3 of 4 – EAPOL Key from AP to STA

  1. Check if AP is sending Message 3 of 4 – EAPOL Key

    • AP instructs STA to install PTK and provides GTK for group traffic.

    • STA will install PTK and GTK, then respond with Message 4 to complete the handshake.

  2. Check the Frame Subtype

    • Type = 2 → Data frame

    • Subtype = 0 → Standard Data

    • Flags = 0x02 → Indicates Protected Frame, meaning payload is encrypted under WPA2.

    Message 3 Subtype

  3. Verify Source Address

    • Source Address = AP MAC address.

    • Confirms the frame is transmitted from the AP.

    Source address in Message 3

  4. Check the Receiver Address

    • Receiver Address = STA MAC address.

    • Ensures the response is directed to the correct STA.

    Receiver address in Message 3

  5. Verify BSSID

    • BSSID = AP MAC address (same as Source).

    • Confirms that the response is part of the same BSS.

    BSSID in Message 3

  6. QoS Control Field

    • QoS Control = 0x0007

    • TID = 7 → Highest priority (Voice / Network Control)

    • Ack Policy = Normal ACK

    • EOSP = Service period for QoS flow

    QoS Control Field

  7. Check the EAPOL Version and Type

    • Version = 802.1X-2004 (2)

    • Type = Key (3) * Indicates that this is an EAPOL-Key frame used for key management.

    EAPOL version and type in Message 3

  8. Verify the Key Descriptor Type

    • Value = 2 → Identifies this as a EAPOL RSN Key (WPA2)

    • Confirms that WPA2 key exchange is being performed.

    Key Descriptor Type in Message 3

  9. Check the Key Information Field

    • Key Descriptor Version: 2 → Uses AES Cipher, HMAC-SHA1 MIC

    • Key Type: Pairwise → The key is for one STA, not for broadcast.

    • Install: set → STA should install PTK now.

    • Key ACK: Set → AP expects acknowledgment.

    • Key MIC: set → STA includes MIC for message integrity check.

    • Secure = Set → Key Data is encrypted (GTK included)

    Key Information field in Message 3

  10. Verify the Replay Counter

  • Value = 2 * Increments from previous message.

Replay counter in Message 3

  1. verify the ANonce

  • Same ANonce as in Message 1 → Confirms handshake continuity.

  • Used again for PTK confirmation.

SNonce in Message 3

  1. Verify the MIC Field

  • Ensures the message is authentic and not altered.

  • AP computes MIC using PTK and includes it here.

MIC verification in Message 3

  1. Check the Key Data Field

  • Contains Group Temporal Key (GTK).

  • GTK used for encrypting broadcast and multicast traffic.

  • Includes RSN Information Element (cipher suites, AKM) and GTK KDE.

WPA2 Key Data in Message 3

Acknowledgement after Message 3 Packet Analysis

  • STA sends ACK confirming receipt of the GTK and installation instruction.

  • Confirms that STA has installed the PTK successfully.

  1. Check the ACK Frame Subtype.

    • Subtype = 13 identifies the frame as an ACK.

    • Indicates successful MAC-layer acknowledgment from STA to AP.

    ACK subtype after Message 3

  2. Verify the ACK Receiver Address.

    • Receiver Address = AP MAC address (sender of the Association Response).

    • Confirms ACK is directed to the correct device.

    Receiver address of ACK after Message 3

Message 4 of 4 – EAPOL Key from STA to AP

  1. Check if STA is sending Message 4 of 4 – EAPOL Key

    • STA confirms successful installation of PTK and GTK.

    • The 4-way handshake is complete, and encrypted data transfer can now begin.

  2. Check the Frame Subtype

    • Type = 2 → Data frame

    • Subtype = 0 → Standard Data

    • Flags = 0x02 → Indicates Protected Frame, meaning payload is encrypted under WPA2/WPA2.

    Message 4 Subtype

  3. Verify Source Address

    • Source Address = STA MAC address.

    • Confirms the frame is transmitted from the STA.

    Source address in Message 4

  4. Check the Receiver Address

    • Receiver Address = AP MAC address.

    • Ensures the response is directed to the correct AP.

    Receiver address in Message 4

  5. Verify BSSID

    • BSSID = AP MAC address.

    • Confirms that the response is part of the same BSS.

    BSSID in Message 4

  6. QoS Control Field

    • QoS Control = 0x0007

    • TID = 7 → Highest priority (Voice / Network Control)

    • Ack Policy = Normal ACK

    QoS Control Field

  7. Check the EAPOL Version and Type

    • Version = 802.1X-2001 (1)

    • Type = Key (3) * Indicates that this is an EAPOL-Key frame used for key management.

    EAPOL version and type in Message 4

  8. Verify the Key Descriptor Type

    • Value = 2 → Identifies this as a EAPOL RSN Key (WPA2)

    • Confirms that WPA2 key exchange is being performed.

    Key Descriptor Type in Message 4

  9. Check the Key Information Field

    • Key Descriptor Version: 2 → Uses AES Cipher, HMAC-SHA1 MIC

    • Key Type: Pairwise → The key is for one STA, not for broadcast.

    • Install: Not set → STA should not install PTK yet.

    • Key ACK: Not Set → since STA does not expect acknowledgment

    • Key MIC: set → STA includes MIC for message integrity check.

    • Secure = Set → Confirms encryption of Key Data (if present)

    Key Information field in Message 4

  10. Verify the Replay Counter

  • Value = 2 * Matches Message 3 counter. * Ensures synchronization between AP and STA.

Replay counter in Message 4

  1. Verify the MIC Field

  • Confirms the final message is valid and unmodified.

  • Proves the STA successfully installed the PTK and GTK.

MIC verification in Message 4

  1. Check the Key Data Length

  • Value = 0 → No additional key data included.

  • Confirms this message is only an acknowledgment.

WPA2 Key Data in Message 4

Acknowledgement after Message 4 Packet Analysis

  • AP sends ACK confirming the final EAPOL message.

  • Both devices now share the same PTK and GTK, and can begin encrypted communication.

  1. Check the ACK Frame Subtype.

    • Subtype = 13 identifies the frame as an ACK.

    • Indicates successful MAC-layer acknowledgment from STA to AP.

    ACK subtype after Message 4

  2. Verify the ACK Receiver Address.

    • Receiver Address = AP MAC address (sender of the Association Response).

    • Confirms ACK is directed to the correct device.

    Receiver address of ACK after Message 4

ARP Request Packet Analysis

  • The ARP Reply in WPA2 mode is sent inside an 802.11 Data frame protected using CCMP (AES).

  • It may involve two flows: 1. STA → AP (STA initiates request) 2. AP → Broadcast (AP forwards to all stations)

  • Used by devices to discover the MAC address corresponding to a target IP.

  1. Check if STA is sending ARP Request

    • STA sends an ARP Request encapsulated inside a QoS Data frame (Subtype = 8).

    • Destination is broadcast (ff:ff:ff:ff:ff:ff), intended for AP and BSS.

    1.1. Check the Source Address

    • MAC of the STA sending the ARP Request.

    • Identifies which device initiated the request.

    STA to AP ARP Source Address

    1.2. Verify Destination Address

    • Broadcast MAC: ff:ff:ff:ff:ff:ff

    • Data frame is intended for all devices in BSS to eventually deliver ARP.

    STA to AP ARP Destination Address

    1.3. Verify Receiver Address

    • Receiver = AP MAC

    STA to AP ARP Receiver Address

    1.4. Verify Transmitter Address

    • Transmitter = STA MAC.

    • Indicates who physically transmitted the frame on the medium.

    STA to AP ARP Transmitter Address

    1.5. QoS Control Field

    • QoS Control: 0x0007 - TID: 7 → Network Control / Voice - Priority: Highest - Ack Policy: Normal ACK - TXOP Duration Requested: 0 - Payload Type: MSDU

    • Confirms QoS parameters used in this ARP Request frame.

    STA to AP ARP QoS Control Field

    1.6. CCMP Encryption Parameters

    • CCMP Ext. IV included

    • Key Index = 0

    • Encryption uses TK (Temporal Key) derived from WPA2 4-way handshake

    • Confirms ARP Request is sent securely over WPA2.

    CCMP Encryption Parameters

    1.7. Verify Sender IP and MAC

    • IP/MAC of the STA initiating the request

    • Identifies which device’s IP is being used to query the target.

    STA to AP ARP Sender IP and MAC

    1.8. Verify Target IP and Target MAC

    • IP of the device STA wants to reach.

    • Target MAC is unknown (00:00:00:00:00:00) in initial ARP Requests.

    STA to AP ARP Target IP and MAC

  2. Check if AP is sending ARP Request to broadcast

    • This frame shows the AP forwarding the ARP Request from STA to all devices in the BSS (broadcast).

    • The AP sets Receiver Address = Broadcast so all stations can see it.

    • Still encapsulated in a 802.11 Data frame (Subtype = 0).

    2.1. Check the Source Address

    • AP’s MAC address as the source of the forwarded ARP Request.

    • Shows that the AP is relaying the ARP.

    ARP Source Address

    2.2. Verify Destination Address

    • Broadcast MAC: ff:ff:ff:ff:ff:ff

    • Data frame is intended for all devices in BSS to eventually deliver ARP.

    STA to AP ARP Destination Address

    2.3. Verify Receiver Address

    • Broadcast: ff:ff:ff:ff:ff:ff

    • Confirms all stations are eligible to receive the ARP Request.

    STA to AP ARP Receiver Address

    2.4. Verify Transmitter Address

    • Transmitter = AP MAC.

    • Indicates who physically transmitted the frame on the medium.

    STA to AP ARP Transmitter Address

    2.5. verify the CCMP Encryption Parameters

    • CCMP Ext. IV included

    • Key Index = 1 → GTK (Group Temporal Key)

    • Encryption ensures secure broadcast of the ARP Request across WPA2 network.

    CCMP Encryption Parameters for Broadcast

    2.6. Verify Sender IP and MAC

    • IP/MAC of the STA initiating the request

    • Identifies which device’s IP is being used to query the target.

    STA to AP ARP Sender IP and MAC

    2.7. Verify Target IP and Target MAC

    • IP of the device STA wants to reach.

    • Target MAC is unknown (00:00:00:00:00:00) in initial ARP Requests.

    STA to AP ARP Target IP and MAC

ARP Reply Packet Analysis

  1. Check if AP is sending ARP Reply

    • After the STA sends an ARP Request, the device owning the target IP responds with an ARP Reply.

    • This is usually unicast from the AP to the STA.

    • The reply provides the MAC address corresponding to the target IP so the STA can update its ARP table.

  2. Verify Source Address

    • AP MAC (BSSID) — the sender of the ARP Reply.

    • Identifies which device owns the requested IP (192.168.1.10).

    AP to STA ARP Reply Source Address

  3. Verify Destination Address

    • STA MAC — unicast to the requesting STA.

    • Ensures only the requesting device receives this ARP Reply.

    AP to STA ARP Reply Destination Address

  4. Verify Receiver Address

    • STA MAC — confirms the intended recipient at the link layer.

    AP to STA ARP Reply Receiver Address

  5. Verify Transmitter Address

    • AP MAC — indicates who physically transmitted the frame.

    AP to STA ARP Reply Transmitter Address

  6. Verify WPA2 CCMP Parameters

    • CCMP Ext. Initialization Vector (PN): ensures per-frame uniqueness

    • Key Index: 0

    • GTK / TK: Per-pairwise key used for encryption

    • PMK: Pairwise Master Key

    • MIC: Validates integrity and authenticity of ARP payload

    WPA2 CCMP Parameters

  7. Verify Sender IP and MAC

    • IP: Target IP (AP’s IP)

    • MAC: AP’s MAC

    • Provides the requested mapping for the STA’s ARP table.

    AP to STA ARP Reply Sender IP and MAC

  8. Verify Target IP and MAC

    • IP: STA IP

    • MAC: STA MAC

    • Confirms the reply is directed to the original requester.

    AP to STA ARP Reply Target IP and MAC

Acknowledgement after ARP Reply Packet Analysis

  • The ARP Reply is a unicast frame, so the STA replies with an ACK.

  • This ensures the AP knows the STA successfully received its Reply packet.

  • The ACK is a Control frame (Subtype = 13) and follows a SIFS interval (~10 µs).

  1. Check the ACK Frame Subtype.

    • Subtype = 13 identifies the frame as an ACK.

    • Confirms the STA received the ARP Reply successfully.

    ARP Reply ACK Subtype

  2. Verify the ACK Receiver Address.

    • Receiver Address = AP MAC address

    • Confirms the acknowledgment is directed to the AP.

    ARP Reply ACK Receiver Address

ICMP Request Packet Analysis

  1. Check if STA is sending ICMP Echo (Ping) Request

    • The ICMP Echo Request is sent by the STA to the AP to test connectivity.

    • It is encapsulated inside an 802.11 Data frame and protected using WPA2 AES-CCMP

    • usually sent unicast to the AP.

    • This frame allows the STA to verify reachability and latency.

  2. Verify Data Rate

    • Data Rate indicates the PHY rate used by the STA (e.g., 24 Mbps or 36 Mbps).

    • Confirms the speed of transmission for the ping request.

    Data Rate in ICMP Echo Request

  3. Verify Channel

    • Channel used for transmission (e.g., Channel 6 / 2437 MHz).

    • Ensures the ping uses the correct RF channel.

    Channel in ICMP Echo Request

  4. Verify Source MAC

    • STA MAC address (e.g., e8:6f:38:71:f1:e3).

    • Confirms the correct STA is sending the ping.

    Source MAC in ICMP Echo Request

  5. Verify Receiver MAC

    • AP MAC address.

    • Confirms the frame is directed to the correct AP.

    Receiver MAC in ICMP Echo Request

  6. Verify Source and Destination IP

    • Source IP: STA IP (e.g., 192.168.1.1)

    • Destination IP: AP IP (e.g., 192.168.1.10)

    • Ensures correct layer-3 addressing for ICMP.

    Source and Destination IP in ICMP Echo Request

  7. Verify WPA2 CCMP Parameters

    • CCMP Ext. Initialization Vector: 0x000000000004

    • Key Index: 0

    • Temporal Key (TK): 548b4ecaccb0a70af3ebc8ee7bad3d5b

    • Pairwise Master Key (PMK): 9cac4539a5f7842823481419de3e855d9ce62b5efd2365a7cef51e175419f255

    • MIC ensures integrity.

    WPA2 Parameters

  8. Verify Protocol

    • Protocol = ICMP (0x01).

    • Confirms the packet is an ICMP message.

    Protocol field in ICMP Echo Request

  9. Verify Type

    • ICMP Type = 8 (Echo Request).

    • Identifies the frame as a ping request.

    ICMP Type in Echo Request

  10. Verify IP Version

  • Version = 4 (IPv4).

  • Confirms the ICMP packet uses IPv4.

IP Version in ICMP Echo Request

Acknowledgement after ICMP Echo Request Packet Analysis

  • The ICMP Request is a unicast frame, so the AP replies with an ACK.

  • This ensures the STA knows the AP successfully received its Request packet.

  • The ACK is a Control frame (Subtype = 13) and follows a SIFS interval (~10 µs).

  1. Check the ACK Frame Subtype.

    • Subtype = 13 identifies the frame as an ACK.

    • Confirms the AP received the ICMP Request successfully.

    ACK Subtype after ICMP Echo Request

  2. Verify the ACK Receiver Address.

    • Receiver MAC = STA MAC.

    • Confirms that the acknowledgment is sent back to the STA.

    ACK Receiver Address after ICMP Echo Request

ICMP Reply Packet Analysis

  1. Check if AP is sending ICMP Echo (Ping) Reply

    • The ICMP Echo Reply is sent by the AP back to the STA in response to the Echo Request.

    • Encapsulated inside an 802.11 Data frame with AES-CCMP and typically sent unicast.

    • Confirms that the AP is reachable and the network path is functioning correctly.

  2. Verify Data Rate

    • Data Rate indicates the PHY rate used by the AP (e.g., 36 Mbps).

    • Confirms the speed of transmission for the ping reply.

    Data Rate in ICMP Echo Reply

  3. Verify Channel

    • Channel used for transmission (e.g., Channel 6 / 2437 MHz).

    • Ensures the reply uses the correct RF channel.

    Channel in ICMP Echo Reply

  4. Verify Source MAC

    • AP MAC address (e.g., 0c:9a:3c:9f:17:71).

    • Confirms the reply originates from the correct AP.

    Source MAC in ICMP Echo Reply

  5. Verify Receiver MAC

    • STA MAC address.

    • Confirms the reply is delivered to the requesting STA.

    Receiver MAC in ICMP Echo Reply

  6. Verify Source and Destination IP

    • Source IP: AP IP (e.g., 192.168.1.10)

    • Destination IP: STA IP (e.g., 192.168.1.1)

    • Confirms correct layer-3 addressing for the ICMP reply.

    Source and Destination IP in ICMP Echo Reply

  7. Verify WPA2 Encryption Parameters

    • CCMP Ext. IV: 0x000000000002

    • Key Index: 0

    • Temporal Key (TK): 548b4ecaccb0a70af3ebc8ee7bad3d5b

    • Pairwise Master Key (PMK): 9cac4539a5f7842823481419de3e855d9ce62b5efd2365a7cef51e175419f255

    WPA2 Parameters

  8. Verify Protocol

    • Protocol = ICMP (0x01).

    • Confirms that the packet is an ICMP message.

    Protocol in ICMP Echo Reply

  9. Verify IP Version

    • Version = 4 (IPv4).

    • Confirms the ICMP packet uses IPv4.

    IP Version in ICMP Echo Reply

  10. Verify Type

  • ICMP Type = 0 (Echo Reply).

  • Identifies the frame as a ping reply.

ICMP Type in Echo Reply

Acknowledgement after ICMP Echo Reply Packet Analysis

  • The ICMP Reply is a unicast frame, so the STA replies with an ACK.

  • This ensures the AP knows the STA successfully received its Reply packet.

  • The ACK is a Control frame (Subtype = 13) and follows a SIFS interval (~10 µs).

  1. Check the ACK Frame Subtype.

    • Subtype = 13 identifies the frame as an ACK.

    • Confirms the STA received the ICMP Reply successfully.

    ACK Subtype after ICMP Echo Reply

  2. Verify the ACK Receiver Address.

    • Receiver MAC = AP MAC.

    • Confirms that the acknowledgment is sent back to the AP.

    ACK Receiver Address after ICMP Echo Reply

Deauthentication Packet Analysis

  1. Check if STA is sending Deauthentication Frame

    • Deauthentication is a management frame sent by either the AP or STA to terminate an existing connection.

    • It contains information about why the device is being deauthenticated.

    • The frame is unicast and will be acknowledged by the recipient.

  2. Verify Frame Subtype

    • Subtype = 12 identifies the frame as Deauthentication.

    • Ensures Wireshark captures the correct management frame.

    Deauthentication Subtype

  3. Verify Source MAC Address

    • MAC address of the device sending the deauthentication frame (AP or STA).

    • Confirms which device initiated the deauthentication.

    Source MAC in Deauthentication

  4. Verify Receiver MAC Address

    • MAC address of the recipient device.

    • Ensures the frame is targeted to the correct station or AP.

    Receiver MAC in Deauthentication

  5. Verify Fixed Parameters

    • Includes Reason Code (e.g., 0x0001: Unspecified reason).

    • Helps determine why the deauthentication occurred.

    Fixed Parameters in Deauthentication

Acknowledgement after Deauthentication Packet Analysis

  • The Deauthentication is a unicast frame, so the AP replies with an ACK.

  • This ensures the STA knows the AP successfully received its Reply packet.

  • The ACK is a Control frame (Subtype = 13) and follows a SIFS interval (~10 µs).

  1. Check the ACK Frame Subtype.

    • Subtype = 13 identifies the frame as an ACK.

    • Confirms the recipient received the deauthentication frame.

    ACK Subtype after Deauthentication

  2. Verify the ACK Receiver Address.

    • Destination MAC = sender of the deauthentication frame.

    • Confirms the acknowledgment is directed back to the sender.

    ACK Receiver Address after Deauthentication