WEP-SHARED

Topics in this section,

Learnings in this section

Version Info

Packet flow in WEP-SHARED mode

Connection steps in wep-shared mode

STEP 1: Bring up AP

STEP 2: Bring up STA

Wireshark capture

Decrypting WEP-Encrypted 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 wep-shared mode

Version Info

#	Version
Supplicant	wpa_supplicant 2.10
Hostapd	hostapd 2.10

Packet flow in WEP-SHARED mode

Connection steps in wep-shared 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 : Add CONFIG_WEP=y in defconfig file

test:~$ sudo vim defconfig

CONFIG_WEP=y

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

Note

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

test:~$ sudo cp defconfig .config

See the full configuration of hostapd

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

# Driver interface for Host AP driver
CONFIG_DRIVER_HOSTAP=y

# Driver interface for wired authenticator
#CONFIG_DRIVER_WIRED=y

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

# QCA vendor extensions to nl80211
#CONFIG_DRIVER_NL80211_QCA=y

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

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

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


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

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

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

# Support Operating Channel Validation
#CONFIG_OCV=y

# Integrated EAP server
CONFIG_EAP=y

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# EAP-IKEv2
#CONFIG_EAP_IKEV2=y

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

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

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

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

# Build IPv6 support for RADIUS operations
CONFIG_IPV6=y

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

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

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

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

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

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

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

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

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

# Remove support for RADIUS accounting
#CONFIG_NO_ACCOUNTING=y

# Remove support for RADIUS
#CONFIG_NO_RADIUS=y

# Remove support for VLANs
#CONFIG_NO_VLAN=y

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# Hotspot 2.0
#CONFIG_HS20=y

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

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

# Enable CLI commands for FST testing
#CONFIG_FST_TEST=y

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

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

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

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

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

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

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

# Airtime policy support
#CONFIG_AIRTIME_POLICY=y

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

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

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

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

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

AP : Complile hostapd

Note

Compile hostapd by running make command

test:~$ sudo make

AP : Check for the binaries created

Note

Make sure hostapd and hostapd_cli are present

test:~$ ls
hostapd
hostapd_cli

AP : Create run_hostapd.conf

test:~$ sudo vim ./run_hostapd.conf

ctrl_interface=/run/hostapd
interface=wlp0s20f3
driver=nl80211
ssid=test_wep_shared_b
hw_mode=b
channel=6
macaddr_acl=0
auth_algs=2
ignore_broadcast_ssid=0
# A key may be a quoted string or unquoted hexadecimal digits.
# The key length should be 5, 13, or 16 characters, or 10, 26, or 32
# digits, depending on whether 40-bit (64-bit), 104-bit (128-bit), or
# 128-bit (152-bit) WEP is used.
# Only the default key must be supplied; the others are optional.
# default: not set
wep_key0=123456789a
wep_key1="vwxyz"
wep_key2=0102030405060708090a0b0c0d
wep_key3=".2.4.6.8.0.23"
wep_default_key=0

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 : Add CONFIG_WEP=y in defconfig file

test:~$ sudo vim defconfig

CONFIG_WEP=y

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

Note

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

test:~$ sudo cp defconfig .config

See the full configuration of wpa_supplicant

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


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

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

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

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

# QCA vendor extensions to nl80211
#CONFIG_DRIVER_NL80211_QCA=y

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

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

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


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

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

# Driver interface for wired Ethernet drivers
CONFIG_DRIVER_WIRED=y

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

# Driver interface for Linux MACsec drivers
CONFIG_DRIVER_MACSEC_LINUX=y

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

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

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

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

# EAP-MD5
CONFIG_EAP_MD5=y

# EAP-MSCHAPv2
CONFIG_EAP_MSCHAPV2=y

# EAP-TLS
CONFIG_EAP_TLS=y

# EAL-PEAP
CONFIG_EAP_PEAP=y

# EAP-TTLS
CONFIG_EAP_TTLS=y

# EAP-FAST
CONFIG_EAP_FAST=y

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

# EAP-GTC
CONFIG_EAP_GTC=y

# EAP-OTP
CONFIG_EAP_OTP=y

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

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

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

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

# EAP-PAX
CONFIG_EAP_PAX=y

# LEAP
CONFIG_EAP_LEAP=y

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

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

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

# EAP-SAKE
CONFIG_EAP_SAKE=y

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

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

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

# EAP-IKEv2
CONFIG_EAP_IKEV2=y

# EAP-EKE
#CONFIG_EAP_EKE=y

# MACsec
CONFIG_MACSEC=y

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

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

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

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

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

# Development testing
#CONFIG_EAPOL_TEST=y

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# Support Operating Channel Validation
#CONFIG_OCV=y

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# Hotspot 2.0
CONFIG_HS20=y

# Enable interface matching in wpa_supplicant
#CONFIG_MATCH_IFACE=y

# Disable roaming in wpa_supplicant
#CONFIG_NO_ROAMING=y

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

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

# Enable TDLS support
CONFIG_TDLS=y

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

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

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

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

# Enable CLI commands for FST testing
#CONFIG_FST_TEST=y

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

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

# Support Multi Band Operation
#CONFIG_MBO=y

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

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

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

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

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

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

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

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

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

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

STA : Compile wpa_supplicant

Note

Compile supplicant by running make command

test:~$ sudo make

STA : Check for the binaries created

Note

Make sure wpa_supplicant and wpa_cli are present

test:~$ ls
wpa_supplicant
wpa_cli

STA : Create run_supplicant.conf

test:~$ sudo vim ./run_supplicant.conf

ctrl_interface=/run/wpa_supplicant
update_config=1

# A key may be a quoted string or unquoted hexadecimal digits.
# The key length should be 5, 13, or 16 characters, or 10, 26, or 32
# digits, depending on whether 40-bit (64-bit), 104-bit (128-bit), or
# 128-bit (152-bit) WEP is used.
# Only the default key must be supplied; the others are optional.
# default: not set

network={
        ssid="test_wep_shared_b"
        key_mgmt=NONE
        wep_key0=123456789a
        wep_key1="vwxyz"
        wep_key2=0102030405060708090a0b0c0d
        wep_key3=".2.4.6.8.0.23"
        wep_tx_keyidx=0
        priority=5
        auth_alg=SHARED
        }

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 WEP-SHARED mode

Decrypting WEP-Encrypted Frames in Wireshark

In this section- To analyze ARP and ICMP packets captured in a WEP/Shared 802.11b network, you must decrypt the frames in Wireshark.
This allows you to view the actual payload (ARP and ICMP data) instead of only seeing encrypted bytes.

Decrypting WEP-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 management, control, and data frames from the shared key network.

Enable Decryption

Go to Edit → Preferences → Protocols → IEEE 802.11.

Check “Enable decryption”.

Click “Edit” under Decryption Keys.

Add the WEP Key

Add your shared WEP key in the format: * Set key type as WEP and key as 123456789a.

Apply the Key and Refresh

Click OK to save the key.

Wireshark will automatically decrypt frames that match the key.

You should now see ARP and ICMP payloads in plain text instead of encrypted bytes.

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 WEP-Shared mode, the AP advertises WEP capability (Privacy bit = 1) and will require Shared-Key authentication for association if configured that way.
- It includes parameters such as supported data rates, channel information, and capability info that STA uses to decide if it can join the network.
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.11b).
- 802.11b requires at least 1 Mbps support for legacy devices.
- If 1 Mbps is missing, some STAs may fail to connect.
Check if the Receiver Address (RA) is Broadcast address.
- Beacon frames are sent to the broadcast address FF:FF:FF:FF:FF:FF so that all nearby STAs can receive them.
- This confirms that the beacon is not targeted to a specific STA but intended for all devices in range.
- No ACK is sent for Beacon frames because they are broadcast.
Verify Supported Rates.
- The Supported Rates element shows data rates the AP supports for association.
- Check for basic rates (1, 2, 5.5, 11 Mbps) and extended rates (if present).
- Confirms the AP supports both legacy and modern devices.
Check the Privacy bit in the Capability Information field.
- Privacy bit = 1 indicates WEP is enabled.
- This distinguishes WEP-Shared mode from completely open (non-encrypted) mode.
- Confirms that the AP is configured for encrypted data frames and (if configured) shared-key authentication.
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.
- Helps verify that the AP is correctly advertising your WEP-enabled SSID.

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 contains information about what the STA supports (SSID, data rates, and capabilities).
- APs receiving this may respond with Probe Response frames if the SSID matches or if the request is broadcast.
Check the Frame Subtype to confirm it is a Probe Request.
- In Wireshark, the Frame Control field indicates the subtype.
- Probe Request frames should have subtype 0x0004.
Verify the Source Address in the Probe Request.
- Source Address should match the STA’s MAC address.
- This ensures the frame is indeed coming from the correct STA.
Verify the Receiver Address in the Probe Request.
- Receiver Address should be the broadcast address (FF:FF:FF:FF:FF:FF).
- This allows all APs on the channel to receive the request.
- No ACK is expected for broadcast Probe Requests.
Check the SSID field in the Probe Request.
- For general network discovery, SSID should be set to Wildcard SSID(empty).
- A specific SSID can limit scanning to only that AP.
Verify Supported Rates and Extended Capabilities.
- Ensure all expected rates are advertised by the STA (1, 2, 5.5, 11 Mbps for 802.11b and 6, 9, 12, … Mbps for 802.11g/n).
- Check additional parameters: Extended Supported Rates, HT Capabilities, VHT if STA is modern.
- Confirms STA can support modern APs while maintaining backward compatibility.

Probe Response Packet Analysis

Check if AP is sending Probe Response packet
- A Probe Response is sent by an AP in reply to a Probe Request received from a STA.
- It contains detailed information about the AP’s capabilities, including SSID, supported rates, channel (DS Parameter), and whether the network is secure (Privacy bit)
- It helps the STA decide which AP to associate with.
- Note: Probe Responses are unicast to the requesting STA, so an ACK is expected from the STA.
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 WEP is enabled on this AP.
- Since this is WEP-Shared mode, the AP will perform the challenge/response exchange for authentication.
- Confirms that security is configured at the AP level.
Verify Supported Rates in the Probe Response.
- The Supported Rates element indicates the rates supported by the AP.
- For 802.11b, these must be 1 Mbps, 2 Mbps, 5.5 Mbps, and 11 Mbps.
- Confirms that both the AP and STA are using compatible DSSS data rates.
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.

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.

1st Authentication Request Packet Analysis (802.11b WEP-Shared Mode)

Check if STA is sending Authentication Request packet
- After receiving the Probe Response, the Station (STA) initiates authentication with the Access Point (AP).
- In Shared-Key mode, authentication is a four-step exchange: 1. STA → AP: Authentication Request (Algorithm = 1, Sequence = 1) 2. AP → STA: Authentication Response (Challenge Text included, Sequence = 2) 3. STA → AP: Authentication Request (Encrypted Challenge Response, Sequence = 3) 4. AP → STA: Authentication Response (Status = Success/Fail, Sequence = 4)
- The first packet in this exchange is an Authentication Request from STA to AP.
- This frame indicates the STA’s intent to authenticate using Shared Key authentication (WEP encryption will be used later during the challenge).
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.
- This field specifies which authentication algorithm is used.
- For WEP-Shared mode, the value must be 1.
- Field meaning: - 0 → Open System Authentication - 1 → Shared Key Authentication
- This confirms that the STA requests to use WEP-Shared key mechanism.
Check the Authentication Sequence Number in the Authentication Request packet.
- This value identifies the sequence step in the authentication exchange.
- For the first authentication request, the Sequence Number = 1.
- It indicates the start of the authentication handshake.
- The AP’s next response should have Sequence Number = 2.
Verify the Status Code in the Authentication Request packet.
- The Status Code field in the Authentication Request is usually 0 or not used.
- It is meaningful mainly in responses, but Wireshark may still display it as 0 (Successful) by default.
- This ensures that the STA is initiating authentication without reporting an error.

Acknowledgement after Authentication Request Packet Analysis

After the STA sends an Authentication Request, the AP must acknowledge it with an ACK frame.
This ACK confirms successful reception of the Authentication Request before the AP sends the Authentication Response.
The ACK is a Control frame (not Management or Data).
It is transmitted immediately after a SIFS (Short Interframe Space) interval.

Check the ACK Frame Subtype.
- Since the Authentication Request is unicast, the AP responds with an ACK frame.
- The ACK has Subtype = 13 in 802.11.
- Confirms that the AP successfully received the Authentication Request.
Verify the ACK Receiver Address.
- The ACK frame’s Receiver Address should match the STA’s MAC address (the source of the Authentication Request).
- Confirms the AP has acknowledged the STA correctly.

2nd Authentication Response Packet Analysis (802.11b WEP-Shared Mode)

Check if AP is sending Authentication Response
- After receiving the STA’s first Authentication Request, the Access Point (AP) replies with an Authentication Response frame.
- In WEP-Shared mode, this response contains a Challenge Text tag.
- The STA must later encrypt this challenge using its WEP key to prove possession of the correct key.
- This step confirms the start of the shared key challenge-response mechanism.
Check the Frame Subtype
- The Subtype field = 11 indicates it is an Authentication frame.
- Ensures that the AP has correctly responded to the STA’s authentication attempt.
Verify Source Address
- The Source Address should be the AP’s MAC address.
- Confirms the Authentication Response is sent by the Access Point.
Check the Receiver Address
- The Receiver Address should be the STA’s MAC address (the device being authenticated).
- Confirms that the AP is addressing the correct station.
Check the BSSID Field
- The BSSID must match the AP’s MAC address.
- Confirms that this frame belongs to the correct Basic Service Set (BSS).
- Useful when multiple APs operate on the same channel.
Check the Authentication Algorithm Number
- The Authentication Algorithm field specifies the type of authentication used.
- In WEP-Shared mode, this field must have a value of 1.
- Field meaning: - 0 → Open System Authentication - 1 → Shared Key Authentication
- This confirms the AP is performing WEP-Shared key authentication.
Check the Authentication Sequence Number
- This field indicates the step number in the authentication process.
- For the 2nd frame, the Sequence Number = 2.
- It confirms this message is the challenge sent by the AP to the STA.
- The STA’s next encrypted response will use Sequence Number = 3.
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.
Check the Tagged Parameters – Tag: Challenge Text
- In the WEP-Shared authentication sequence, this is the critical field.
- The AP includes a Challenge Text tag to test the STA’s WEP key.
Tag Number:
- Field used to identify the type of tag.
- Value: 16 (0x10) → Indicates “Challenge Text” tag.
Tag Length:
- Specifies the number of bytes in the challenge text field.
- Typically 128 bytes or depends on implementation.
Challenge Text:
- Random binary data or ASCII sequence generated by the AP.
- This challenge must be encrypted using the shared WEP key by the STA in the next frame.
- The AP will later verify this encrypted challenge to confirm key validity.

Acknowledgement after Authentication Response Packet Analysis

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

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

3rd Authentication Request (Encrypted Challenge) Packet Analysis (802.11b WEP-Shared Mode)

Check if STA is sending Encrypted Challenge Response packet
- After receiving the Challenge Text from the AP, the STA encrypts it using the configured WEP key.
- The STA then sends this encrypted challenge back to the AP in the third authentication frame.
- This frame is again an Authentication Request but includes the encrypted challenge as a tagged parameter.
- The goal of this step is for the AP to verify that the STA has the correct shared key.
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.
- This field specifies which authentication algorithm is used.
- For WEP-Shared mode, the value must be 1.
- Field meaning:
  - 0 → Open System Authentication
  - 1 → Shared Key Authentication
- This confirms that the STA requests to use WEP-Shared key mechanism.
Check the Authentication Sequence Number in the Authentication Request packet.
- The Sequence Number = 3, indicating this is the third message in the authentication process.
- This value confirms the STA’s encrypted challenge response step.
- The next (final) frame from AP will use Sequence Number = 4.
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.
Analyze the Tagged Parameters – Tag: Challenge Text
- This field contains the Encrypted Challenge Text generated by the STA.
- It is the same challenge text provided by the AP earlier, but now encrypted using the STA’s WEP key.
Tag Number:
- Identifies the tag type.
- Value = 16 (0x10) → “Challenge Text” tag.
Tag Length:
- Specifies the number of bytes of encrypted challenge data.
- Typically matches the original challenge length (e.g., 128 bytes).
Challenge Text:
- Contains the WEP-encrypted version of the AP’s challenge text.
- This encryption uses the WEP key configured on the STA.
- The AP will later decrypt and verify this in the final step.
- This confirms the STA is proving possession of the shared WEP key.
Verify WEP Parameters
- Initialization Vector (IV):
  - 24-bit random number prepended to WEP key for encryption.
  - Used by RC4 to combine with WEP key for encrypting payload.
  - Ensures each frame has a unique key stream.
- Key Index: 0
  - Indicates which WEP key (from the AP/STA configured set) is used to encrypt this frame.
- WEP Integrity Check Value (ICV):
  - CRC32 checksum applied to plaintext for integrity verification.
  - Encrypted along with the payload using WEP.
  - Ensures integrity of the encrypted payload. AP/STA verifies it to detect tampering.

Acknowledgement after Authentication Request Packet Analysis

After the STA sends an Authentication Request, the AP must acknowledge it with an ACK frame.
This ACK confirms successful reception of the Authentication Request before the AP sends the Authentication Response.
The ACK is a Control frame (not Management or Data).
It is transmitted immediately after a SIFS (Short Interframe Space) interval.

Check the ACK Frame Subtype.
- Since the Authentication Request is unicast, the AP responds with an ACK frame.
- The ACK has Subtype = 13 in 802.11.
- Confirms that the AP successfully received the Authentication Request.
Verify the ACK Receiver Address.
- The ACK frame’s Receiver Address should match the STA’s MAC address (the source of the Authentication Request).
- Confirms the AP has acknowledged the STA correctly.

4th Authentication Packet (Authentication Response) Analysis

Check if AP is sending Authentication Response
- This is the final step in the WEP-Shared authentication process.
- After the STA encrypts the challenge text using the WEP key and sends it in the 3rd Authentication frame, the AP verifies it by decrypting and comparing it with the original challenge.
- If the challenge matches, the AP responds with an Authentication Response (Sequence Number = 4) and a Status Code = 0 (Successful).
- If verification fails, the AP sends Status Code ≠ 0, indicating authentication failure.
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.
- Since this is the 4th frame, it represents the Authentication Response completing the process.
Verify Source Address
- The Source Address should be the AP’s MAC address.
- Indicates the AP is responding after verifying the challenge text sent by the STA.
Check the Receiver Address
- The Receiver Address should be the STA’s MAC address (the device being authenticated).
- Confirms that the AP is addressing the correct station.
Check the BSSID Field
- The BSSID must match the AP’s MAC address.
- Confirms that this frame belongs to the correct Basic Service Set (BSS).
- Useful when multiple APs operate on the same channel.
Check the Authentication Algorithm Number
- The Authentication Algorithm field value is 1, representing WEP-Shared Key Authentication.
- This indicates that the authentication process used encryption and challenge-response mechanism.
- Confirms the mode is WEP-Shared, not Open System.
Check the Authentication Sequence Number
- The Sequence Number is 4, meaning this is the final frame in the four-step authentication exchange.
- Sequence numbers help identify the correct stage of the authentication process: 1 → Request 2 → Response with Challenge 3 → Request with Encrypted Challenge 4 → Final Response (Success/Failure)
- Confirms completion of the Shared Key authentication sequence.
Check the Status Code
- The Status Code value is 0 (Successful) if the challenge text matches after decryption by the AP.
- If the challenge decryption fails, the Status Code will indicate failure (non-zero value).
- This field is critical — it determines whether the STA is allowed to proceed to the Association phase.

Acknowledgement after Authentication Response Packet Analysis

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

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

Association Request Packet Analysis

Check if STA is sending Association Request
- After successful WEP-Shared authentication, the STA sends an Association Request frame to the AP.
- This frame contains the STA’s capabilities, supported data rates, SSID, and encryption support (WEP).
- It is a Management frame (Subtype = 0).
- Privacy bit = 1, meaning encryption is enabled for subsequent data frames.
- Being a unicast frame, it will be acknowledged by the AP.
Check the Frame Subtype
- Subtype = 0 identifies the frame as an Association Request.
- Ensures Wireshark captures the correct management frame.
Verify Source Address
- Source Address = STA MAC address.
- Confirms the frame is sent by the correct STA.
Check the Receiver Address
- Receiver Address = AP MAC address.
- Ensures the frame is targeted to the correct AP.
Verify BSSID
- BSSID = AP MAC address.
- Confirms the frame is part of the correct Basic Service Set.
Check the Capability Information – Privacy bit
- Privacy bit = 1 indicates WEP 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

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

For 802.11b, only the DSSS rates are supported: 1 Mbps, 2 Mbps, 5.5 Mbps, and 11 Mbps.

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

Verify Extended Capabilities

Extended Capabilities field lists additional STA features (e.g., HT support, QoS, etc.).

Ensures AP can understand STA capabilities.

Verify Supported Operating Classes

Supported Operating Classes indicate which frequency bands and channels the STA can operate on.

Helps AP confirm STA compatibility with its configured channel.

Acknowledgement after Association Request Packet Analysis

Since the Association Request is a unicast frame from the STA to the AP,the AP responds with an ACK frame to confirm successful reception.
The ACK is a Control frame (Subtype = 13) and ensures reliable MAC-layer delivery.
This ACK is sent immediately after a SIFS interval.

Check the ACK Frame Subtype.
- Subtype = 13 identifies the frame as an ACK.
- Confirms the AP received the Association Request correctly.
Verify the ACK Receiver Address.
- The Receiver Address of the ACK should be the STA’s MAC address (source of the Association Request).
- Confirms that the AP is acknowledging the correct station.

Association Response Packet Analysis

Check if AP is sending Association Response
- After receiving the STA’s Association Request, AP sends an Association Response.
- Contains Status Code (success/failure) and assigns AID.
- Privacy bit = 1 → encryption enabled for subsequent data frames.
- Management frame (Subtype = 1), unicast to STA.
Check the Frame Subtype
- Subtype = 1 identifies the frame as an Association Response.
- Confirms that the AP has acknowledged the STA’s request to join the BSS.
Verify Source Address
- Source Address = AP MAC address.
- Confirms the frame is transmitted from the AP.
Check the Receiver Address
- Receiver Address = STA MAC address.
- Ensures the response is directed to the correct STA.
Verify BSSID
- BSSID = AP MAC address (same as Source).
- Confirms that the response is part of the same BSS.
Check the Capability Information – Privacy bit
- Privacy bit = 1 → indicates WEP encryption is enabled.
- Confirms that subsequent data frames will use WEP 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 denial reasons (e.g., unsupported rates or capacity limits).
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

Supported Rates field should list 1, 2, 5.5, and 11 Mbps for 802.11b.

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

Verify Extended Capabilities

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

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

Acknowledgement after Association Response Packet Analysis

The Association Response is a unicast frame, so the STA replies with an ACK.
This ensures the AP knows the STA successfully received its association confirmation.
The ACK is a Control frame (Subtype = 13) and follows a SIFS interval (~10 µs).

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

ARP Request Packet Analysis

The ARP Request in WEP-SHARED mode is sent inside an 802.11 Data frame encrypted using WEP with Shared Key authentication.
It may involve two flows: 1. STA → AP (STA initiates request) 2. AP → Broadcast (AP forwards to all stations)
Allows devices to resolve MAC addresses for given IPs.

Check if STA is sending ARP Request to AP
- STA sends an ARP Request encapsulated in a WEP-encrypted Data frame (Subtype = 0, unicast to AP).
- Frame fields include MAC addresses, IP addresses, and 802.11 headers.
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 address.
- Confirms the AP is the frame’s immediate recipient.
1.4. Verify Transmitter Address
- Transmitter = STA MAC.
- Indicates who physically transmitted the frame on the medium.
1.5. Verify WEP Parameters
- Initialization Vector (IV): * 24-bit random number prepended to WEP key for encryption. * Used by RC4 to combine with WEP key for encrypting payload. * Ensures each frame has a unique key stream.
- Key Index: 0 * Indicates which WEP key (from the AP/STA configured set) is used to encrypt this frame.
- WEP Integrity Check Value (ICV): * CRC32 checksum applied to plaintext for integrity verification. * Encrypted along with the payload using WEP. * Ensures integrity of the encrypted payload. AP/STA verifies it to detect tampering.
1.6. Verify Sender IP and MAC
- IP/MAC of the STA initiating the request
- Identifies which device’s IP is being used to query the target.
1.7. Verify Target IP and Target MAC
- IP of the device STA wants to reach.
- Target MAC is unknown (00:00:00:00:00:00) in initial ARP Requests.
Check if AP is forwarding ARP Request to Broadcast
- This frame shows the AP forwarding the ARP Request from STA to all devices in the BSS (broadcast).
- The AP sets Receiver Address = Broadcast so all stations can see it.
- Still encapsulated in a 802.11 Data frame (Subtype = 0).
2.1. Check the Source Address
- AP’s MAC address as the source of the forwarded ARP Request.
- Shows that the AP is relaying the ARP.
2.2. Verify Destination Address
- Broadcast MAC: ff:ff:ff:ff:ff:ff
- Sent to all stations in the BSS.
2.3. Verify Receiver Address
- Broadcast: ff:ff:ff:ff:ff:ff
- Confirms all stations are eligible to receive the ARP Request.
2.4. Verify Transmitter Address
- Transmitter = AP MAC.
- Indicates which device physically transmitted this broadcast.
2.5. Verify WEP Parameters
- Initialization Vector (IV): * 24-bit random number prepended to WEP key for encryption. * Ensures each frame has a unique key stream.
- Key Index: 0 * Indicates which WEP key is used for encryption.
- WEP Integrity Check Value (ICV): * CRC32 checksum applied to plaintext for integrity verification. * Encrypted along with the payload using WEP.
- Indicates which device physically transmitted this broadcast.
2.6. Verify Sender IP and MAC
- IP/MAC of the STA initiating the request (carried inside AP’s forwarded ARP).
- AP forwards this information so other stations know who is requesting.
2.7. Verify Target IP and Target MAC
- IP of the device STA wants to reach.
- Target MAC is unknown (00:00:00:00:00:00) in initial ARP Requests.

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 WEP Parameters
- Initialization Vector (IV): * Ensures unique encryption for each reply frame.
- Key Index: 0 * Indicates which WEP key is used for this reply.
- WEP Integrity Check Value (ICV): * Provides integrity verification for the ARP Reply payload.
Verify Sender IP and MAC
- IP: Target IP (AP’s IP)
- MAC: AP’s MAC
- Provides the requested mapping for the STA’s ARP table.
Verify Target IP and MAC
- IP: STA IP
- MAC: STA MAC
- Confirms the reply is directed to the original requester.

Acknowledgement after ARP Reply Packet Analysis

The ARP Reply is a unicast frame, so the STA replies with an ACK.
This ensures the AP knows the STA successfully received its Reply packet.
The ACK is a Control frame (Subtype = 13) and follows a SIFS interval (~10 µs).

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

ICMP Request Packet Analysis

Check if STA is sending ICMP Echo (Ping) Request
- The ICMP Echo Request is sent by the STA to the AP to test connectivity.
- It is encapsulated inside an 802.11 Data frame and 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., 5.5 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 WEP Parameters
- Initialization Vector (IV): * Ensures unique encryption for each ICMP request frame.
- Key Index: 0 * Indicates the WEP key used to encrypt the ICMP payload.
- WEP Integrity Check Value (ICV): * Encrypted CRC32 checksum ensures the integrity of the ICMP Request.
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 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., 11 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 WEP Parameters
- Initialization Vector (IV): * Unique for each ICMP reply frame to prevent key reuse.
- Key Index: 0 * Indicates which WEP key was used to encrypt this frame.
- WEP Integrity Check Value (ICV): * Encrypted checksum ensures payload integrity.
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.