WPA3

Topics in this section,

Learnings in this section

Version Info

Packet flow in WPA3 mode

Connection steps in wpa3 mode

STEP 1: Bring up AP

STEP 2: Bring up STA

Wireshark capture

Decrypting WPA3 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 wpa3 mode

Version Info

#	Version
Supplicant	wpa_supplicant 2.10
Hostapd	hostapd 2.10

Packet flow in WPA3 mode

Connection steps in wpa3 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
CONFIG_WPA_PSK=y
CONFIG_SAE=y

AP : Open .config file and copy below lines to .config file

test:~$ sudo vim .config

CONFIG_DRIVER_NL80211=y
CONFIG_WPA_PSK=y
CONFIG_SAE=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_wpa3_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=SAE
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
CONFIG_WPA_PSK=y
CONFIG_SAE=y

STA : Open .config file and copy below lines to .config file

test:~$ sudo vim .config

CONFIG_DRIVER_NL80211=y
CONFIG_WPA_PSK=y
CONFIG_SAE=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_wpa3_ng"
proto=WPA2
key_mgmt=SAE
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 WPA3 mode

Decrypting WPA3-Encrypted Frames in Wireshark

In this section — You will learn how to decrypt WPA3-encrypted frames in an 802.11ng (802.11n + 802.11g) mixed-mode wireless network.
802.11ng networks combine High Throughput (HT) features of 802.11n with legacy compatibility for 802.11g devices.
Unlike WPA2, WPA3 uses SAE (Simultaneous Authentication of Equals) for authentication, which provides forward secrecy and eliminates the use of a pre-shared key (PSK) handshake.
Decryption of WPA3 frames is only possible if you have access to the derived session key (TK or PTK) captured during the connection.
This key allows Wireshark to decrypt frames protected using AES-CCMP-128 or GCMP-128 encryption algorithms.

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 — these are essential for deriving the PTK (Pairwise Transient Key)

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 WPA3 Temporal Key (TK)

In the Decryption Keys dialog: * Click “+” to add a new key. * Choose Key type: tk * Enter the TK key directly in hexadecimal format.

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.

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 WPA3 mode, the Beacon contains the RSN (Robust Security Network) Information Element (Tag Number: 48), specifying SAE as the authentication method.
- 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.11ng).
- 802.11ng 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.
Capability Information
- Capability Info = 0x0411
- Bit-level breakdown: - ESS: 1 → Transmitter is an AP - Privacy: 1 → Encryption enabled (WPA3 active) - Short Slot Time: 1 → 9 µs slot duration for higher efficiency - QoS: 0 → QoS not indicated in this frame
- Confirms the AP supports WPA3 with short slot time enabled for 802.11g/n mixed mode.
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.
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_wpa3_ng”).
- Ensures the AP is broadcasting the correct SSID and the STA can identify it.
TIM (Traffic Indication Map)

TIM → DTIM 0 of 2 bitmap

Indicates DTIM Period = 2, meaning every second beacon includes delivery information for multicast/broadcast frames.

Check the ERP Information Element.

ERP Info: 0x04

Bit breakdown: - Non-ERP Present: 0 → No 802.11b-only devices detected - Use Protection: 0 → No RTS/CTS needed - Barker Preamble: 1 → Compatibility for older stations

Confirms efficient coexistence in mixed 802.11b/g/n environments.

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.

Inspect the RSN (Robust Security Network) Information Element

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

Defines WPA3 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 → 00:0f:ac → SAE (SHA-256)

RSN Capabilities: 0x000c → Indicates modern WPA3-SAE support with no PMF requirement in this beacon.

Confirms WPA3-SAE as the security mechanism using AES-CCMP encryption.

Check Supported Operating Classes

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

Defines regulatory operation within the 2.4 GHz band.

HT Capabilities (802.11n)

Tag Number: 45, Length: 26

Highlights: - Channel Width: 20 MHz - Short GI: Supported - A-MPDU Parameters: 0x17 → Aggregation supported - Rx MCS Set: Indicates supported Modulation and Coding Schemes

Confirms High Throughput (HT) operation with 802.11n features.

HT Information Element

Tag Number: 61, Length: 22

Defines HT operation parameters: - Primary Channel: 6 - Secondary Channel Offset: None - HT Protection: Enabled - Operating Mode: Mixed (b/g/n coexistence)

Ensures proper interworking between legacy and HT stations.

Check Extended Capabilities

Tag Number: 127, Length: 8

Contains optional features for advanced management and coexistence.

Indicates support for 20/40 MHz coexistence and other WNM features.

Vendor Specific (WMM/WME Parameter Element)

Tag: Vendor Specific (Microsoft OUI: 00:50:f2), Type: WMM/WME Parameter Element

Defines Quality of Service (QoS) parameters for different traffic categories: - AC_BE (Best Effort) - AC_BK (Background) - AC_VI (Video) - AC_VO (Voice)

Confirms Wi-Fi Multimedia (WMM) is enabled — crucial for real-time performance in 802.11n.

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.
- Tag Number: 1
- Supported Rates: 6, 9, 12, 18, 24, 36, 48, 54 Mbps
- Indicates the STA supports OFDM modulation rates (802.11a/g/n).
- Legacy 1–11 Mbps rates are not included, confirming the STA prefers ERP-OFDM operation.
Check HT Capabilities (802.11n) field.
- Tag Number: 45
- Tag Length: 26 bytes
- This field advertises High Throughput (HT) features supported by the STA. - HT Capabilities Info: 0x19ef
  - Short GI for 20 MHz
  - Greenfield Mode capable
  - STBC (Space-Time Block Coding) supported
  - L-SIG TXOP protection supported
  - A-MPDU Parameters: 0x13 → Aggregation supported, maximum length & spacing defined.
  - Rx Supported MCS Set: MCS 0–7 (up to 150 Mbps in 20 MHz mode).
  - HT Extended Capabilities: 0x0000
  - Tx Beamforming Capabilities: 0x00000000 (none supported).
  - Antenna Selection (ASEL): 0x00
- Confirms the STA supports 802.11n High Throughput operation in WPA3 mode.
Inspect the Extended Capabilities tag.
- Contains optional flags for QoS, coexistence, and advanced features.
- Tag Number: 127
- Tag Length: 11 bytes
- Defines optional advanced capabilities at the MAC layer.
- Example octets: - 0x04, 0x00, 0x00, 0x00, 0x01, 0x00, 0x40, 0x0040, 0x00, 0x20
- Indicates: - Support for QoS Management and U-APSD - 20/40 MHz Coexistence mechanisms (for 2.4 GHz HT operation) - Interworking and Extended Security options for WPA3 networks - Management Frame Protection (PMF) readiness (important for WPA3 compliance)
VHT Capabilities (802.11ac)
- Optional, but some 802.11ng devices include VHT info for backward compatibility.
- Tag Number: 191
- Tag Length: 12 bytes
- Present even though the frame belongs to an 802.11ng (HT) STA — used for cross-standard compatibility. - VHT Capabilities Info: 0x03d071b2 - VHT Supported MCS Set: Indicates 1 spatial stream and support for 256-QAM.
- Confirms the STA can interoperate with 802.11ac (VHT) APs, offering higher efficiency and modulation support.

Probe Response Packet Analysis

Check if AP is sending Probe Response packet
- The AP responds to a STA’s Probe Request with its SSID, channel, and supported capabilities.
- The 802.11ng (802.11n + 802.11g compatibility) standard includes High Throughput (HT) features while maintaining legacy compatibility.
- In WPA3, the Authentication and Key Management (AKM) is SAE (Simultaneous Authentication of Equals), replacing PSK for better security.
- The following analysis details all key fields and Information Elements (IEs) from the Probe Response frame.
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 WPA3 is enabled on this AP.
- Confirms that security is configured at the AP level.
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.
Verify Supported Rates in the Probe Response.
- Rates: 1(B), 2(B), 5.5(B), 11(B), 6, 9, 12, 18 Mbps
- Shows backward compatibility with 802.11b/g clients.
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.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/g devices are in the network.
  - Use Protection bit – Enables CTS-to-Self or RTS/CTS when 802.11b/g 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.11ng operation).
Check the RSN (Robust Security Network) Information Element.
- Defines WPA3 encryption and authentication settings.
- Tag Number: 48
- RSN Version: 1
- Group Cipher Suite: AES (CCMP)
- Pairwise Cipher Suite: AES (CCMP)
- Auth Key Management (AKM): SAE (Simultaneous Authentication of Equals)
- RSN Capabilities: 0x000c → Management Frame Protection (optional).
- Indicates WPA3-Personal (SAE) mode — provides resistance against offline dictionary attacks.
- SAE replaces PSK with a password-authenticated key exchange.
Supported Operating Classes
- Operating Class: 81 → 2.4 GHz channels 1–13, 25 MHz spacing.
- Used for regulatory and channel control purposes.
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).
- Confirms 802.11n High Throughput support.
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.
Check Extended Capabilities
- 8 octets total (0x04 … 0x40)
- Indicates optional features such as BSS transition, QoS enhancements, and Spectrum Management.
- Enhances 802.11n functionality beyond base rates.
WMM (Wi-Fi Multimedia) Parameter Element
- Tag Number: 221 (Vendor Specific)
- OUI: 00:50:f2 (Microsoft Corp.)
- Type: WMM/WME (0x02)
- Version: 1
- QoS Info: 0x01 → WMM enabled.
- Access Categories: BE, BK, VI, VO each with unique AIFSN, CWmin/max, TXOP values.
- Confirms QoS prioritization for real-time multimedia traffic (802.11e).
- Critical for maintaining low latency in WPA3-enabled HT environments.

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 1 Packet Analysis (WPA3 - 802.11ng)

In this section — We analyze the first Authentication frame (Commit message) exchanged in a WPA3-SAE (Simultaneous Authentication of Equals) handshake within an 802.11ng network.
Unlike WPA2, WPA3 uses the SAE handshake to achieve mutual authentication and forward secrecy, replacing the pre-shared key (PSK) exchange.
This first message (Commit) is sent from STA → AP, containing elliptic curve parameters, scalar, and finite field element values that contribute to the Diffie–Hellman key exchange.

Check if STA is sending Authentication Request 2
- The Station (STA) initiates the authentication process by sending this Authentication frame to the Access Point (AP).
- The frame uses the Simultaneous Authentication of Equals (SAE) algorithm.
- This is the first of four authentication frames in WPA3.
- Unlike WPA2, SAE performs an elliptic curve Diffie–Hellman (ECDH) exchange to establish a unique Pairwise Master Key (PMK).
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.
- Authentication Algorithm = 3 (Simultaneous Authentication of Equals, SAE).
- SAE replaces the Open System Authentication (Algorithm 0) used in WPA2.
- SAE provides: - Mutual authentication without requiring a shared password in plaintext. - Protection against offline dictionary attacks. - Forward secrecy by generating a unique PMK for each session.
Check the Authentication Sequence Number in the Authentication Request packet.
- Authentication Sequence = 1
- Indicates this is the Commit Message (first step) in the SAE handshake.
- The next message (Sequence = 2) will be the Commit Response from the AP.
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.
SAE Message Type and Group Information
- SAE Message Type: Commit (1)
- Group ID: 19 → 256-bit random Elliptic Curve (ECP group).
- This defines the Elliptic Curve group used for the Diffie–Hellman exchange.
- Curve 19 corresponds to NIST P-256, providing 128-bit security strength.
Scalar and Finite Field Element
- The Scalar and Finite Field Element are public components of the ECDH key exchange.
- These values are generated randomly by the STA for each session and are used by the AP to compute the shared secret.
  - Scalar: f82910fe911d854dfde4673abe5fd8c54f74e1e47b5ba8bec89af7222ed6b8c0
  - Finite Field Element: c920b612a489bf6b4c8e74b1da252fea8daeecb030a67eb35bcbf885d0197ac2ee43106176cf38abceffb9fa25d38376365d4ba9055cc5a90f24863b7b9d1f12
- Together, these enable both STA and AP to compute the shared key (K) securely.

Acknowledgement after Authentication Packet 1 Analysis

After the STA sends an Authentication 1, the AP must acknowledge it with an ACK frame.
This ACK confirms successful reception of the Authentication 1 before the AP sends the Authentication 2.
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 1 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 1.
Verify the ACK Receiver Address.
- The ACK frame’s Receiver Address should match the STA’s MAC address (the source of the Authentication 1).
- Confirms the AP has acknowledged the STA correctly.

Authentication 2 Packet Analysis (WPA3 Mode)

Check if AP is sending Authentication 2
- This frame is the second message in the Simultaneous Authentication of Equals (SAE) exchange — part of WPA3’s initial handshake.
- It represents the AP’s SAE Commit Response to the STA’s first Commit message.
- SAE replaces the WPA2 4-Way Pre-Shared Key exchange with a more secure password-based key exchange using elliptic curve cryptography (ECC).
- This process ensures forward secrecy and protection against offline dictionary attacks.
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 2 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
- Authentication Algorithm = 3 (Simultaneous Authentication of Equals - SAE)
- SAE replaces Open System Authentication used in WPA2.
- This confirms the transition from WPA2 to WPA3 security.
Check the Authentication Sequence Number
- Authentication SEQ = 0x0001
- Both STA and AP use sequence number 1 in their Commit messages.
- The sequence helps Wireshark distinguish Commit/Confirm messages.
SAE Message Type and Group ID
- SAE Message Type: Commit (1) → This is a Commit Response from AP.
- Group ID: 19 → Indicates 256-bit random ECP group (NIST P-256 curve).
- This ECC group defines the mathematical domain used for the key exchange.
Scalar and Finite Field Element
- Scalar: 7e70c8df80051a44cd31d041c942f6dc5fe8845ba322c36a10437854e4d9b2c0
- Finite Field Element: 250049d6787f2a43a2d89e938485337939e8c39fca60a42c09abfc959bf35a40b8386b62eb4b7657c3d7a14713a43378131ebe1dae2398f48fdaffb2a087139c
- Together, these values form the elliptic curve point that contributes to the shared secret computation.
- Each side generates a random scalar and computes a finite field element using the selected ECC group.
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 Packet 2 Analysis

Once the AP sends the Authentication 2, the STA acknowledges it using an ACK frame.
This ensures reliable delivery of the Authentication 2 before moving on to the Authentication 3.

Check the ACK Frame Subtype.
- The ACK frame has Subtype = 13, identifying it as an acknowledgment.
- Confirms the STA received the Authentication 2 correctly.
Verify the ACK Receiver Address.
- The Receiver Address should be the AP’s MAC address (source of the Authentication 2).
- Confirms that the STA is acknowledging the correct transmitter.

Authentication 3 Packet Analysis (WPA3 - 802.11ng)

Check if STA is sending Authentication 3 packet
- This frame is the third message in the Simultaneous Authentication of Equals (SAE) handshake used in WPA3.
- It is the Confirm message sent by the STA to the AP, verifying the shared secret computed from the earlier Commit exchange.
- The successful verification indicates that both parties derived the same cryptographic keys without revealing the password.
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 3 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 3 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 3 packet.
- Authentication Algorithm = 3 (Simultaneous Authentication of Equals, SAE).
- Confirms this frame is part of WPA3’s SAE handshake.
- SAE is used instead of WPA2’s PSK-based 4-Way handshake initiation.
Check the Authentication Sequence Number in the Authentication 3 packet.
- Authentication SEQ = 0x0002
- Sequence number 2 indicates this is the Confirm message in the SAE exchange.
- Follows the Commit message pair (SEQ = 1 from both STA and AP).
SAE Message Type and Send-Confirm Field
- SAE Message Type = 2 (Confirm)
- Send-Confirm = 1 → Indicates the first confirm attempt from STA.
- This value is incremented if retransmissions occur.
- The Confirm message proves that the STA computed the same session key as the AP using its scalar and element values from the Commit phase.
Confirm Field (Cryptographic Proof)
- Confirm: db25ba37c40eaef9746d95106ba25bbeca114327b3bf0a1d61aecb1e1846acfd
- This is a HMAC-based cryptographic token that authenticates the computed shared secret.
- It proves possession of the password-derived key without exposing the password itself.
- If this value matches the AP’s expected confirm value, authentication proceeds successfully.
Verify the Status Code in the Authentication 3 packet.
- The Status Code field in the Authentication 3 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 Packet 3 Analysis

After the STA sends an Authentication 3, the AP must acknowledge it with an ACK frame.
This ACK confirms successful reception of the Authentication 3 before the AP sends the Authentication 4.
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 3 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 3.
Verify the ACK Receiver Address.
- The ACK frame’s Receiver Address should match the STA’s MAC address (the source of the Authentication 3).
- Confirms the AP has acknowledged the STA correctly.

Authentication 4 Packet Analysis (WPA3 Mode)

Check if AP is sending Authentication 4
- This frame is the fourth and final message of the Simultaneous Authentication of Equals (SAE) process.
- It is sent by the Access Point (AP) to the Station (STA) to confirm mutual authentication.
- Upon successful verification, both devices derive the Pairwise Master Key (PMK) and proceed to the 4-Way Handshake to establish encryption keys.
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 4 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
- Authentication Algorithm = 3 (SAE - Simultaneous Authentication of Equals)
- Verifies that this frame belongs to the WPA3 SAE key exchange.
- SAE replaces WPA2’s pre-shared key (PSK) authentication for improved resistance against offline dictionary attacks.
Check the Authentication Sequence Number
- Authentication SEQ = 0x0002
- Sequence number 2 again indicates a Confirm message, but this time from the AP.
- It corresponds to the STA’s earlier Confirm (also SEQ = 2), forming a matched exchange pair.
SAE Message Type and Send-Confirm Field
- SAE Message Type = 2 (Confirm)
- Send-Confirm = 1 — indicates the first confirm attempt by the AP.
- Confirms that the AP also computed the same password-derived key as the STA during the Commit phase.
- This mutual confirmation step ensures both sides derived identical cryptographic material.
Confirm Field (Cryptographic Proof)
- Confirm: 536939a73f4b42b7db33d62c934dd454f24c5dc1649cb11700fea7dd7e0a1a33
- This value is a cryptographic hash computed from both the scalar and finite field element values exchanged earlier.
- The AP uses this to prove possession of the same key without exposing the password.
- The STA validates this value before proceeding to the association phase.
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 Packet4 Analysis

Once the AP sends the Authentication 4, the STA acknowledges it using an ACK frame.
This ensures reliable delivery of the Authentication 4 before moving on to the Association request.

Check the ACK Frame Subtype.
- The ACK frame has Subtype = 13, identifying it as an acknowledgment.
- Confirms the STA received the Authentication 4 correctly.
Verify the ACK Receiver Address.
- The Receiver Address should be the AP’s MAC address (source of the Authentication 4).
- Confirms that the STA is acknowledging the correct transmitter.

Association Request Packet Analysis

Check if STA is sending Association Request
- After completing the SAE 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 WPA3 SAE parameters.
- Being a Management frame (Subtype = 0) and unicast, the AP acknowledges it immediately.
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 WPA3 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: 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.

RSN Information Element (WPA3 Security)
- Tag Number = 48 → RSN IE
- Group Cipher Suite: AES (CCM)
- Pairwise Cipher Suite: AES (CCM)
- AKM Suite: SAE (SHA256)
- Confirms WPA3 SAE operation with AES encryption.
HT Capabilities (802.11n High Throughput)
- Tag Number = 45 → HT Capabilities IE
- Key parameters: - HT Capabilities Info = 0x19ef - A-MPDU Parameters = 0x13 - Rx MCS Set - TxBF = 0x00000000
- Confirms STA supports 802.11n high throughput.
Extended Capabilities
- Tag Number = 127, length = 11 bytes.
- Indicates advanced STA features like coexistence, QoS, and extended channel support.
Supported Operating Classes
- Tag Number = 59, length = 21.
- Frequency bands and channels STA can operate on.
- Current Operating Class = 81 → 2.4 GHz, Channels 1–13.
Vendor-Specific: WMM/WME Information Element
- Tag Number = 221, OUI = 00:50:f2 (Microsoft).
- Type = 2, Subtype = 0, Version = 1, QoS Info = 0x00
- Confirms QoS support for prioritized traffic in 802.11n.

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 a valid Association Request from the STA, the AP responds with an Association Response frame.
- Confirms successful connection setup before starting the WPA3 SAE key exchange.
- Frame Type = Management (Type 0) Subtype = Association Response (1)
- Sent unicast from AP → STA, acknowledged by 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 WPA3 SAE encryption is enabled.
- Confirms that subsequent data frames will use WPA3 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 WPA3 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

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.

HT Capabilities (802.11n)

Tag Number: 45, length: 26 bytes

Key fields:

HT Capabilities Info (0x000C):

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

A-MPDU Parameters = 0x17:

Aggregation support

MCS Set:

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

TxBF = 0x00000000 → No beamforming

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

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 Subsets 1–3, Basic MCS set.

Verify Extended Capabilities

Tag Number: 127, Length = 8 octets

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

WMM/WME Parameter Element (QoS)

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

Type = 2, Subtype = Parameter Element (1), Version = 1

QoS parameters for 4 Access Categories: - AC_BE: AIFSN=3, CWmin/max=15/1023, TXOP=0 - AC_BK: AIFSN=7, CWmin/max=15/1023, TXOP=0 - AC_VI: AIFSN=2, CWmin/max=7/15, TXOP=94 - AC_VO: AIFSN=2, CWmin/max=3/7, TXOP=47

WME QoS Info = 0x01 → QoS enabled on AP.

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 4-Way Handshake begins.
- WPA3 uses SAE (Simultaneous Authentication of Equals) to derive encryption keys securely.
- Message 1 is sent by the AP to the STA, containing the ANonce / SAE Commit parameters.
- STA uses this ANonce + SNonce + PMK to compute the PTK.
- Keys involved: - PMK (Pairwise Master Key): Derived from SAE handshake. - 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.
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.
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.
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 (WPA3/SAE).
- Confirms that WPA3 key exchange is being performed.
Check the Key Information Field
- Key Descriptor Version: 2 → Uses AES, HMAC-SHA256 MIC (WPA3)
- 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)/ SAE Commit

Random 32-byte number generated by the AP.

Contains SAE commit parameters for password-authenticated key exchange.

Verify the Key Data Length

Contains SAE commit parameters (non-zero length).

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 responds to Message 1 with Message 2 of the WPA3 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 : Contains SAE confirm or group parameters.
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.
QoS Control Field
- QoS Control = 0x0007
- TID = 7 → Highest priority (Voice/Network Control).
- Ack Policy = Normal ACK.
- TXOP Duration = 0 → No TXOP requested.
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 = 3 → RSN Key for WPA3 / SAE
Check the Key Information Field
- Key Descriptor Version: 2 → Uses AES Cipher, HMAC-SHA256 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 PMK 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 (WPA3 Information Element)

Contains SAE confirm data, group ID, or supported ciphers

AP uses this to verify the STA’s SAE commitment

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 will install PTK and GTK, then respond with Message 4 to complete the handshake.
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.
QoS Control Field
- QoS Control = 0x0007
- TID = 7 → Highest priority (Voice / Network Control)
- Ack Policy = Normal ACK
- EOSP = Service period for QoS flow
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 = 3 → RSN Key (SAE / WPA3)
Check the Key Information Field
- Key Descriptor Version: 2 → Uses AES-256 / HMAC-SHA256 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 GTK for group traffic, SAE group parameters, RSN Information Element

Data is encrypted (Secure bit set)

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.
QoS Control Field
- QoS Control = 0x0007
- TID = 7 → Highest priority (Voice / Network Control)
- Ack Policy = Normal ACK
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 WPA3 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 WPA3 mode is sent inside an 802.11 Data frame protected using CCMP (AES-256, HMAC-SHA256).
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 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.
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. 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.
1.6. CCMP Encryption Parameters
- CCMP Ext. IV included
- Key Index = 0
- Encryption uses TK (Temporal Key) derived from WPA3 SAE handshake
- Confirms ARP Request is sent securely over WPA2.
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.
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.

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 WPA3 CCMP Parameters
- CCMP Ext. Initialization Vector ensures per-frame uniqueness.
- Key Index: 0
- TK derived from SAE handshake (AES-256, HMAC-SHA256)
- MIC validates integrity and authenticity.
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 WPA3 AES-256 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 WPA3 CCMP Parameters
- CCMP Ext. Initialization Vector (PN) for frame uniqueness
- Key Index: 0
- Temporal Key (TK) derived from SAE handshake (AES-256, HMAC-SHA256)
- MIC validates 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-256 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 WPA3 Encryption Parameters
- CCMP Ext. Initialization Vector (PN) for per-frame uniqueness
- Key Index: 0
- Temporal Key (TK) derived from SAE handshake (AES-256, HMAC-SHA256)
- MIC ensures integrity and authenticity of payload
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.