// reference · session records

802.11 Session Records

An 802.11 session is not a TCP flow. It starts at Authentication, ends at Deauthentication, and includes everything in between -- EAPOL, data, retransmits, roaming events. This page defines what WiFi Analyser records per client session and how each field maps to a real PCAP measurement.

— Shankar K. · Schema adapted from: nfstream NFlow 130-slot dataclass, wlanpi-profiler IE timing gates

// tcp flow vs 802.11 session - the key differences
TCP / IP Flow (nfstream model)
Boundary SYN → FIN/RST
Identity 5-tuple: src IP, dst IP, src port, dst port, protocol
Direction src2dst (client→server) + dst2src (server→client)
Layer L4 transport - above Wi-Fi entirely
Auth/Crypto TLS handshake (if HTTPS) - separate from transport
Mobility IP address change = new flow (TCP breaks on L3 roam)
Tools Wireshark, nfstream, Zeek, Suricata
802.11 Session (WiFi Analyser model)
Boundary Auth Request → Deauthentication frame
Identity 3-tuple: client MAC, AP BSSID, SSID
Direction ToDS (STA→AP uplink) + FromDS (AP→STA downlink)
Layer L2 MAC -- below IP, captures everything including EAPOL
Auth/Crypto WPA2/WPA3 4-Way Handshake -- measured as eapol_ms
Mobility Reassociation continues the session -- roam is a sub-event
Tools WiFi Analyser, Wireshark, AirMagnet (discontinued)
// 802.11 session record fields - what wifi analyser tracks per client
Field 802.11 Measurement nfstream parallel Status
join_ms Auth Request → DHCP ACK (full join time) bidirectional_duration_ms Exists
auth_exchange_ms Auth Request → Auth Response dst2src_duration_ms V2: NEW
assoc_exchange_ms Assoc Request → Assoc Response src2dst_duration_ms Exists
eapol_ms EAPOL M1 → M4 (full 4-Way) bidirectional_duration_ms Exists
eapol_m1_m2_ms EAPOL M1 → M2 gap bidirectional_min_piat_ms V2: NEW
eapol_m3_m4_ms EAPOL M3 → M4 gap dst2src_duration_ms V2: NEW
dhcp_ms DHCP Discover → ACK bidirectional_first_seen_ms Exists
first_seen_ms Timestamp of first frame (Auth Request) bidirectional_first_seen_ms Exists
session_duration_ms Auth Request → Deauth frame bidirectional_duration_ms Exists
scenario Detected scenario (wpa2_personal, ft_psk_roam...) application_name Exists
anomaly_domain Primary anomaly domain (SECURITY, CONNECTIVITY...) application_category_name V2: NEW
retry_rate_pct % of frames with Retry bit set N/A - 802.11-specific Exists
avg_rssi_dbm Mean RSSI across all client frames in session N/A - 802.11-specific Exists
avg_mcs_index Mean MCS index across data frames N/A - 802.11-specific Exists
roam_count Number of reassociation events in session N/A - 802.11-specific Exists
// 802.11 session lifecycle
Auth Request STA → AP first_seen_ms = t₀
Session starts here. All timing measured relative to this frame.
Auth Response AP → STA auth_exchange_ms = t₁ - t₀
SLA: WARN >200ms, FAIL >500ms
Assoc Request STA → AP RSN IE negotiation
Cipher suite + AKM method declared here
Assoc Response AP → STA assoc_exchange_ms = t₃ - t₂
AID assigned. SLA: WARN >200ms, FAIL >500ms
EAPOL M1–M4 AP ↔ STA eapol_ms = t₇ - t₄
4-Way Handshake. SLA: FAIL >2000ms
DHCP DORA STA ↔ DHCP server dhcp_ms
Only on fresh join or L3 roam. FAIL >2000ms
Data frames STA ↔ AP retry_rate, avg_mcs, avg_rssi
Session metrics sampled continuously
Deauth / Disassoc either session_duration_ms = tₙ - t₀
Session ends. Reason code recorded.
See session records for your PCAP
WiFi Analyser builds a session record per client -- join time, EAPOL timing, retry rate, MCS distribution, and anomaly summary.
try it free ↗