WPA2

Topics in this section,

Learnings in this section

Version Info

Packet flow in WPA2 mode

Connection steps in wpa2 mode

STEP 1: Bring up AP

STEP 2: Bring up STA

Wireshark capture

Decrypting WPA2 Frames in Wireshark

Wireshark capture Analysis

Learnings in this section

In this section, you are going to learn

How to run wpa_supplicant and hostapd in wpa mode

Version Info

#	Version
Supplicant	wpa_supplicant 2.10
Hostapd	hostapd 2.10

Packet flow in WPA2 mode

Connection steps in wpa2 mode

STEP 1: Bring up AP using hostapd

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_g
hw_mode=g
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

STEP 2: Bring up STA using supplicant

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_g"
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 wlp2s0
> status

Wireshark capture

Download file to check wireshark output

Packet capture in WPA2 mode

Decrypting WPA2-Encrypted Frames in Wireshark

In this section- To analyze ARP and ICMP packets captured in a WPA2 secured 802.11g network, you must decrypt the frames in Wireshark.
Decryption allows you to view the actual payload (ARP, ICMP, TCP, UDP, etc.) instead of encrypted bytes.
Unlike WEP, WPA2/WPA2 uses dynamic keys generated during the 4-way handshake, so Wireshark needs either the passphrase and EAPOL handshake or a PMK/PSK to decrypt data.

Decrypting WPA2-Encrypted Frames in Wireshark

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.

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

Enable Decryption

Go to Edit → Preferences → Protocols → IEEE 802.11.

Check “Enable decryption”.

Click “Edit” under Decryption Keys.

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

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.

Wireshark capture Analysis

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

Beacon Packet Analysis

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.
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.
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.
Verify that the Data Rate includes 1 Mbps (mandatory for 802.11g).
- 802.11g requires at least 1 Mbps support for legacy devices.
- If 1 Mbps is missing, some STAs may fail to connect.
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.
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.11g clients.
Check the Privacy bit in the Capability Information field.
- Privacy bit = 1 → encryption is enabled (not open).
- Indicates WPA2/WPA2 is active.
- Unlike WEP, WPA2 uses dynamic key management and stronger encryption suites.
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.
Check the SSID Tag
- The SSID field must match the configured network name(e.g., “test_wpa2_g”).
- Ensures the AP is broadcasting the correct SSID and the STA can identify it.
Check the ERP Information Element.

The ERP (Extended Rate PHY) element is unique to 802.11g 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 networks.

Verify Short Slot Time bit in Capability Info.

Short Slot Time = 1 → shorter slot duration (9 µs) for improved efficiency.

802.11b used long slot (20 µs).

Check Extended Supported Rates.

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

Confirms support for higher OFDM data rates.

Completes the 802.11g data rate range.

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 (CCM)

Pairwise Cipher Suite Count: 1 → AES (CCM)

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

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

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

Check Supported Operating Classes

Indicates regulatory and operating class information for frequency bands.

Useful for determining region and supported channels.

Check Extended Capabilities

Extended Capabilities field (8 bytes) may include optional features such as QoS, BSS transition, or 20/40 MHz coexistence.

Not critical for WPA2 operation but provides insight into AP capabilities.

Verify TIM (Traffic Indication Map)

Tag: TIM → DTIM 1 of 2 bitmap

TIM informs power-saving clients about buffered unicast/multicast data.

DTIM = 1 of 2 indicates one DTIM every two Beacon intervals.

Probe Request Packet Analysis

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.
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.
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.
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.
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.
Verify Supported Rates and Extended Supported Rates.
- Supported Rates: 1, 2, 5.5, 11, 6, 9, 12, 18 Mbps
- Extended Supported Rates: 24, 36, 48, 54 Mbps
- Confirms STA supports both legacy 802.11b and higher 802.11g data rates.
Check HT Capabilities (802.11n) field.
- Shows STA’s advanced features such as MCS support, A-MPDU, and channel width.
- Example: - HT Capabilities Info: 0x19ef - A-MPDU Parameters: 0x13 - Rx Supported MCS Set: Indicates supported MCS indexes.
- Confirms STA supports 802.11n (High Throughput) features.
Inspect the Extended Capabilities tag.
- Optional features are advertised here (QoS, 20/40 MHz coexistence, etc.).
- For this frame: - Tag length: 11 octets - Example values: 0x04, 0x00, 0x00, 0x00, 0x01, 0x00, 0x40…
- Indicates STA’s extended interoperability capabilities.

Probe Response Packet Analysis

Check if AP is sending Probe Response packet
- The AP sends a Probe Response when it receives a Probe Request from a STA.
- It announces its SSID, channel, supported rates, and security configuration.
- In WPA2 mode, the RSN Information Element replaces the older WPA Vendor Specific tag.
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.
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.
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.
Check the SSID field in the Probe Response.
- SSID must match the AP configuration.
- Confirms the AP is broadcasting the expected network name.
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.
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.
Check Capability Information field for Short Slot Time = 1 in the Probe Response.
- Short Slot Time = 1 → Enabled for 802.11g high-rate operation.
Verify Supported Rates in the Probe Response.
- Supported Rates: 1, 2, 5.5, 11, 6, 9, 12, 18 Mbps.
- Indicates backward compatibility with 802.11b and support for OFDM modulation in 802.11g.
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.

Check ERP Information (New in 802.11g)
- The ERP Information element is unique to 802.11g and ensures backward compatibility with 802.11b.
- 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.
Check Extended Supported Rates
- Extended Rates: 24, 36, 48, 54 Mbps.
- Confirms full-rate support up to 54 Mbps (OFDM-based 802.11g operation).
Check the RSN (Robust Security Network) Information Element.
- Replaces the old WPA Vendor Tag in WPA2 networks.
- Tag Number: 48 (RSN Information)
- RSN Version: 1
- Group Cipher Suite: AES (CCMP)
- Pairwise Cipher Suite: AES (CCMP)
- Auth Key Management (AKM): PSK (Pre-Shared Key)
- RSN Capabilities: 0x0000 (No Management Frame Protection)
- Confirms the AP is configured for WPA2-PSK with AES encryption.
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.11g functionality.

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.

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.
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.

Authentication Request Packet Analysis (WPA2 - 802.11g)

Check if STA is sending Authentication Request packet
- After receiving the Probe Response, the Station (STA) begins the authentication process with the Access Point (AP).
- In WPA2 mode, this step still uses Open System Authentication — there is no challenge–response or encryption yet.
- Actual secure key exchange happens later in the 4-Way Handshake after association.
- The purpose of this frame is to confirm that both STA and AP are ready for higher-layer authentication.
- Since it’s a unicast management frame, the AP will send an ACK immediately after receiving it.
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.
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.
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.
Check the Authentication Algorithm field in the Authentication Request packet.
- The Authentication Algorithm field should be 0 for Open System.
- WPA and WPA2 both use Open System Authentication, even though encryption is enabled later.
- Actual encryption keys (PTK, GTK) are generated after the 4-Way Handshake.
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.
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.

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.

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.
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.

Authentication Response Packet Analysis (WPA2 Mode)

Check if AP is sending Authentication Response
- After receiving the STA’s first Authentication Request, the Access Point (AP) sends an Authentication Response frame.
- In WPA2 mode, this process still uses Open System Authentication (Algorithm = 0).
- The actual WPA2 security exchange happens after Association, during the 4-Way Handshake.
- This frame simply acknowledges that the STA is permitted to associate with the AP.
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.
Verify Source Address
- The Source Address should be the AP’s MAC address.
- Confirms the Authentication Response is sent by the Access Point.
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.
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.
Check the Authentication Algorithm Number
- The Authentication Algorithm = 0 (Open System) even for WPA2.
- WPA2 doesn’t use WEP’s Shared Key authentication; it relies on 802.1X/EAP or PSK later.
- This value only means that open authentication is allowed before secure key exchange.
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).
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.

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.

Check the ACK Frame Subtype.
- The ACK frame has Subtype = 13, identifying it as an acknowledgment.
- Confirms the STA received the Authentication Response correctly.
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.

Association Request Packet Analysis

Check if STA is sending Association Request
- After successful WPA2 authentication, the STA sends an Association Request frame to the AP.
- This frame contains the STA’s capabilities, supported rates, SSID, and WPA2 RSN Information Element.
- It is a Management frame (Subtype = 0).
- Privacy bit = 1, indicating WPA2 encryption is supported.
- Being a unicast frame, it will be acknowledged by the AP.
Check the Frame Subtype
- Subtype = 0 identifies the frame as an Association Request.
- Ensures Wireshark captures the correct management frame.
Verify Source Address
- Source Address = STA MAC address.
- Confirms the frame is sent by the correct STA.
Check the Receiver Address
- Receiver Address = AP MAC address.
- Ensures the frame is targeted to the correct AP.
Verify BSSID
- BSSID = AP MAC address.
- Confirms the frame is part of the correct Basic Service Set.
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
Verify Capability Information – Short Preamble bit
- Short Preamble bit indicates whether STA supports short preamble.
- Helps verify compatibility with AP preamble configuration.
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.
Verify SSID Field
- SSID must match the AP’s network name.
- Confirms that the STA is associating with the correct BSS.
Check the Supported Rates and Extended Supported Rates

Supported Rates field lists the data rates that the STA can transmit and receive.

For 802.11g, STA advertises both DSSS rates (1, 2, 5.5, 11 Mbps) and OFDM rates (6, 9, 12, 18, 24, 36, 48, 54 Mbps).

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

Confirms STA and AP are compatible within 802.11g PHY specifications.

Verify Extended Capabilities

Extended Capabilities field lists additional STA features (e.g., QoS, 20/40 MHz, Radio Measurement, etc.).

Ensures AP can understand STA capabilities.

Verify Supported Operating Classes

Indicates which frequency bands and channels the STA can operate on.

Helps AP confirm STA compatibility with its configured channel.

Check the RSN Information Element (WPA2 Security)
- Tag Number = 48 → Identifies this as an RSN (Robust Security Network) IE.
- Confirms the AP supports WPA2 encryption and PSK (Pre-Shared Key) authentication.
- Group Cipher Suite: AES (CCM) → Defines the encryption algorithm used for multicast/broadcast frames.
- Pairwise Cipher Suite: AES (CCM) → Defines the encryption algorithm used for unicast frames between AP and STA.
- Authentication Key Management (AKM): PSK → Indicates pre-shared key is used for authentication.
- RSN Capabilities: May include options like PMF (Protected Management Frames) support, pre-authentication, and replay protection.
- Ensures secure communication using WPA2, preventing eavesdropping and unauthorized access.

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.

Check the ACK Frame Subtype.
- Subtype = 13 identifies the frame as an ACK.
- Confirms the AP received the Association Request correctly.
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.

Association Response Packet Analysis

Check if AP is sending Association Response
- After receiving the STA’s Association Request, AP sends an Association Response.
- Contains Status Code (success/failure) and assigns AID.
- Privacy bit = 1 → indicating that encryption (WPA2) is required for data frames.
- Management frame (Subtype = 1), unicast to STA.
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.
Verify Source Address
- Source Address = AP MAC address.
- Confirms the frame is transmitted from the AP.
Check the Receiver Address
- Receiver Address = STA MAC address.
- Ensures the response is directed to the correct STA.
Verify BSSID
- BSSID = AP MAC address (same as Source).
- Confirms that the response is part of the same BSS.
Check the Capability Information – Privacy bit
- Privacy bit = 1 → indicates WPA2 encryption is enabled.
- Confirms that subsequent data frames will use WPA2 protection.
Verify Capability Information – Short Preamble bit
- Short Preamble bit indicates AP supports short preamble operation.
- Confirms compatibility with STA’s preamble capabilities.
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.
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.
Check the Supported Rates ,Extended Supported Rates

STA and AP must agree on DSSS + OFDM rates (1,2,5.5,11 + 6,9,12,…54 Mbps).

Ensures both AP and STA agree on common rate sets for communication.

Extended Rates: 24, 36, 48, 54 Mbps

Confirms full OFDM data rate support under 802.11g.

Verify Extended Capabilities

Length = 11 octets.

Indicates additional optional features (e.g., QoS, HT support if present) supported by the AP.

For 802.11g, this may be minimal or absent, confirming a basic DSSS connection.

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).

Check the ACK Frame Subtype.
- Subtype = 13 identifies the frame as an ACK.
- Indicates successful MAC-layer acknowledgment from STA to AP.
Verify the ACK Receiver Address.
- Receiver Address = AP MAC address (sender of the Association Response).
- Confirms ACK is directed to the correct device.

Message 1 of 4 – EAPOL Key from AP to STA

Check if AP is sending Message 1 of 4 – EAPOL Key
- After successful authentication and association, the WPA2 4-Way Handshake begins.
- Its main purpose is to derive and confirm encryption keys between the Access Point (AP) and Station (STA).
- This process uses:
  - Pairwise Master Key (PMK): Derived from the pre-shared key (PSK) or 802.1X authentication.
  - Pairwise Transient Key (PTK): Generated from PMK + Nonces + MAC addresses.
  - Group Temporal Key (GTK): Used for broadcast and multicast traffic.
- The handshake involves four messages
- The AP sends ANonce to STA to initiate key generation.
- The STA will use this ANonce, its own SNonce, and the shared PSK to derive PTK.
Check the Frame Subtype
- Type = 2 → Data frame
- Subtype = 0 → Standard Data
- Flags = 0x02 → Indicates Protected Frame, meaning payload is encrypted under WPA2.
Verify Source Address
- Source Address = AP MAC address.
- Confirms the frame is transmitted from the AP.
Check the Receiver Address
- Receiver Address = STA MAC address.
- Ensures the response is directed to the correct STA.
Verify BSSID
- BSSID = AP MAC address (same as Source).
- Confirms that the response is part of the same BSS.
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.
Verify the Key Descriptor Type
- Value = 2 → EAPOL RSN Key (WPA2).
- Confirms that WPA2 key exchange is being performed.
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
Verify the Replay Counter
- Value = 1 → Used to prevent replay attacks. Must increase with each new handshake message.
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.

Verify the Key Data Length

Value = 0 → No additional data present.

Confirms this is the first message containing only ANonce.

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.

Check the ACK Frame Subtype.
- Subtype = 13 identifies the frame as an ACK.
- Indicates successful MAC-layer acknowledgment from STA to AP.
Verify the ACK Receiver Address.
- Receiver Address = AP MAC address (sender of the Association Response).
- Confirms ACK is directed to the correct device.

Message 2 of 4 – EAPOL Key from STA to AP

Check if STA is sending Message 2 of 4 – EAPOL Key
- STA sends SNonce and MIC to AP.
- AP verifies MIC using PTK and confirms both sides share the same key material.
- This message ensures STA participates in PTK derivation and confirms key agreement.
Check the Frame Subtype
- Type = 2 → Data frame
- Subtype = 0 → Standard Data
- Flags = 0x02 → Indicates Protected Frame, meaning payload is encrypted under WPA2.
Verify Source Address
- Source Address = STA MAC address.
- Confirms the frame is transmitted from the STA.
Check the Receiver Address
- Receiver Address = AP MAC address.
- Ensures the response is directed to the correct AP.
Verify BSSID
- BSSID = AP MAC address.
- Confirms that the response is part of the same BSS.
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.
Verify the Key Descriptor Type
- Value = 254 → Identifies this as a WPA2 Key frame.
- Confirms that WPA2 key exchange is being performed.
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
Verify the Replay Counter
- Value = 1 * Matches Message 1 counter. * Ensures synchronization between AP and STA.
Check the SNonce (Supplicant Nonce)

Random 32-byte number generated by the STA.

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

Verify the MIC Field

Message Integrity Code generated using the derived PTK.

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

Check the Key Data (WPA2 Information Element)

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

Helps AP confirm STA’s supported encryption capabilities.

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.

Check the ACK Frame Subtype.
- Subtype = 13 identifies the frame as an ACK.
- Indicates successful MAC-layer acknowledgment from STA to AP.
Verify the ACK Receiver Address.
- Receiver Address = AP MAC address (sender of the Association Response).
- Confirms ACK is directed to the correct device.

Message 3 of 4 – EAPOL Key from AP to STA

Check if AP is sending Message 3 of 4 – EAPOL Key
- AP instructs STA to install PTK and provides GTK for group traffic.
- STA installs both keys and prepares to send final confirmation.
Check the Frame Subtype
- Type = 2 → Data frame
- Subtype = 0 → Standard Data
- Flags = 0x02 → Indicates Protected Frame, meaning payload is encrypted under WPA2.
Verify Source Address
- Source Address = AP MAC address.
- Confirms the frame is transmitted from the AP.
Check the Receiver Address
- Receiver Address = STA MAC address.
- Ensures the response is directed to the correct STA.
Verify BSSID
- BSSID = AP MAC address (same as Source).
- Confirms that the response is part of the same BSS.
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.
Verify the Key Descriptor Type
- Value = 2 → Identifies this as a EAPOL RSN Key (WPA2)
- Confirms that WPA2 key exchange is being performed.
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)
Verify the Replay Counter
- Value = 2 * Increments from previous message.
verify the ANonce

Same ANonce as in Message 1 → Confirms handshake continuity.

Used again for PTK confirmation.

Verify the MIC Field

Ensures the message is authentic and not altered.

AP computes MIC using PTK and includes it here.

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.

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.

Check the ACK Frame Subtype.
- Subtype = 13 identifies the frame as an ACK.
- Indicates successful MAC-layer acknowledgment from STA to AP.
Verify the ACK Receiver Address.
- Receiver Address = AP MAC address (sender of the Association Response).
- Confirms ACK is directed to the correct device.

Message 4 of 4 – EAPOL Key from STA to AP

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.
Check the Frame Subtype
- Type = 2 → Data frame
- Subtype = 0 → Standard Data
- Flags = 0x02 → Indicates Protected Frame, meaning payload is encrypted under WPA2/WPA2.
Verify Source Address
- Source Address = STA MAC address.
- Confirms the frame is transmitted from the STA.
Check the Receiver Address
- Receiver Address = AP MAC address.
- Ensures the response is directed to the correct AP.
Verify BSSID
- BSSID = AP MAC address.
- Confirms that the response is part of the same BSS.
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.
Verify the Key Descriptor Type
- Value = 2 → Identifies this as a EAPOL RSN Key (WPA2)
- Confirms that WPA2 key exchange is being performed.
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)
Verify the Replay Counter
- Value = 2 * Matches Message 3 counter. * Ensures synchronization between AP and STA.
Verify the MIC Field

Confirms the final message is valid and unmodified.

Proves the STA successfully installed the PTK and GTK.

Check the Key Data Length

Value = 0 → No additional key data included.

Confirms this message is only an acknowledgment.

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.

Check the ACK Frame Subtype.
- Subtype = 13 identifies the frame as an ACK.
- Indicates successful MAC-layer acknowledgment from STA to AP.
Verify the ACK Receiver Address.
- Receiver Address = AP MAC address (sender of the Association Response).
- Confirms ACK is directed to the correct device.

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.

Check if STA is sending ARP Request
- STA sends an ARP Request encapsulated in a WPA2-encrypted Data frame.
- WPA2 uses AES-CCMP for encryption and integrity protection.
1.1. Check the Source Address
- MAC of the STA sending the ARP Request.
- Identifies which device initiated the request.
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.
1.3. Verify Receiver Address
- Receiver = AP MAC
1.4. Verify Transmitter Address
- Transmitter = STA MAC.
- Indicates who physically transmitted the frame on the medium.
1.5. Verify WPA2 CCMP Parameters
- CCMP Ext. Initialization Vector (PN): 0x00000000001B → ensures per-frame uniqueness
- Key Index: 0 → indicates which pairwise key is used
- TK (Temporal Key): db3fb8bd336519d2fbc60536943cb399
- PMK (Pairwise Master Key): 5a62cbe806170c6e2090ae65eb29a29d357db4660d93751ac0dbe5e54a5d52da
- MIC: ensures integrity and authenticity of ARP payload
1.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.
1.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.

ARP Reply Packet Analysis

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.
Verify Source Address
- AP MAC (BSSID) — the sender of the ARP Reply.
- Identifies which device owns the requested IP (192.168.1.10).
Verify Destination Address
- STA MAC — unicast to the requesting STA.
- Ensures only the requesting device receives this ARP Reply.
Verify Receiver Address
- STA MAC — confirms the intended recipient at the link layer.
Verify Transmitter Address
- AP MAC — indicates who physically transmitted the frame.
Verify WPA2 TKIP Parameters
- CCMP Ext. Initialization Vector (PN): → ensures per-frame uniqueness
- Key Index: 0
- TK (Temporal Key): db3fb8bd336519d2fbc60536943cb399
- PMK (Pairwise Master Key): 5a62cbe806170c6e2090ae65eb29a29d357db4660d93751ac0dbe5e54a5d52da
- MIC: ensures integrity and authenticity of ARP payload
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.
Verify Target IP and MAC
- IP: STA IP
- MAC: STA MAC
- Confirms the reply is directed to the original requester.

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).

Check the ACK Frame Subtype.
- Subtype = 13 identifies the frame as an ACK.
- Confirms the STA received the ARP Reply successfully.
Verify the ACK Receiver Address.
- Receiver Address = AP MAC address
- Confirms the acknowledgment is directed to the AP.

ICMP Request Packet Analysis

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.
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.
Verify Channel
- Channel used for transmission (e.g., Channel 6 / 2437 MHz).
- Ensures the ping uses the correct RF channel.
Verify Source MAC
- STA MAC address (e.g., e8:6f:38:71:f1:e3).
- Confirms the correct STA is sending the ping.
Verify Receiver MAC
- AP MAC address.
- Confirms the frame is directed to the correct AP.
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.
Verify WPA2 CCMP Parameters
- CCMP Ext. Initialization Vector: 0x00000000001C
- Key Index: 0
- Temporal Key (TK): db3fb8bd336519d2fbc60536943cb399
- Pairwise Master Key (PMK): 5a62cbe806170c6e2090ae65eb29a29d357db4660d93751ac0dbe5e54a5d52da
- MIC ensures message integrity and authenticity.
Verify Protocol
- Protocol = ICMP (0x01).
- Confirms the packet is an ICMP message.
Verify Type
- ICMP Type = 8 (Echo Request).
- Identifies the frame as a ping request.
Verify IP Version

Version = 4 (IPv4).

Confirms the ICMP packet uses IPv4.

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).

Check the ACK Frame Subtype.
- Subtype = 13 identifies the frame as an ACK.
- Confirms the AP received the ICMP Request successfully.
Verify the ACK Receiver Address.
- Receiver MAC = STA MAC.
- Confirms that the acknowledgment is sent back to the STA.

ICMP Reply Packet Analysis

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.
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.
Verify Channel
- Channel used for transmission (e.g., Channel 6 / 2437 MHz).
- Ensures the reply uses the correct RF channel.
Verify Source MAC
- AP MAC address (e.g., 0c:9a:3c:9f:17:71).
- Confirms the reply originates from the correct AP.
Verify Receiver MAC
- STA MAC address.
- Confirms the reply is delivered to the requesting STA.
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.
Verify WPA2 Encryption Parameters
- CCMP Ext. IV: 0x000000000002
- Key Index: 0
- Temporal Key (TK): db3fb8bd336519d2fbc60536943cb399
- Pairwise Master Key (PMK): 5a62cbe806170c6e2090ae65eb29a29d357db4660d93751ac0dbe5e54a5d52da
Verify Protocol
- Protocol = ICMP (0x01).
- Confirms that the packet is an ICMP message.
Verify IP Version
- Version = 4 (IPv4).
- Confirms the ICMP packet uses IPv4.
Verify Type

ICMP Type = 0 (Echo Reply).

Identifies the frame as a ping 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).

Check the ACK Frame Subtype.
- Subtype = 13 identifies the frame as an ACK.
- Confirms the STA received the ICMP Reply successfully.
Verify the ACK Receiver Address.
- Receiver MAC = AP MAC.
- Confirms that the acknowledgment is sent back to the AP.

Deauthentication Packet Analysis

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.
Verify Frame Subtype
- Subtype = 12 identifies the frame as Deauthentication.
- Ensures Wireshark captures the correct management frame.
Verify Source MAC Address
- MAC address of the device sending the deauthentication frame (AP or STA).
- Confirms which device initiated the deauthentication.
Verify Receiver MAC Address
- MAC address of the recipient device.
- Ensures the frame is targeted to the correct station or AP.
Verify Fixed Parameters
- Includes Reason Code (e.g., 0x0001: Unspecified reason).
- Helps determine why the deauthentication occurred.

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).

Check the ACK Frame Subtype.
- Subtype = 13 identifies the frame as an ACK.
- Confirms the recipient received the deauthentication frame.
Verify the ACK Receiver Address.
- Destination MAC = sender of the deauthentication frame.
- Confirms the acknowledgment is directed back to the sender.