// reference · top n analysis
Top N Analysis for Enterprise Wi-Fi
In a busy enterprise PCAP -- 500 clients, 40 APs, 2 million frames -- the most actionable question is always the same: which client is causing the most harm? Top N views answer that. Pattern adapted from Zeek's anomaly_detector LOG_WEIGHTS ranking and Malcolm's Elasticsearch aggregation endpoint.
— Shankar K. · Pattern: zeek_anomaly_detector LOG_WEIGHTS + scores.nlargest(), Malcolm /agg endpoint
// why ranked views matter
1
Scale problem
A 30-minute enterprise PCAP contains 2-5 million frames. Manual review is impossible. Top N collapses the dataset to the 10 clients or flows that actually need attention.
2
The 90/10 pattern
In every enterprise capture, 90% of the pain comes from 10% of the clients. One sticky client at MCS 0 can consume 40% of airtime. One broken EAPOL loop generates hundreds of deauth events.
3
Weighted ranking
Not all metrics are equal. A client with 5 CRITICAL anomalies ranks above one with 50 INFO findings. Zeek's LOG_WEIGHTS model (weight per log type) maps to anomaly severity weighting in 802.11.
// available top n views - what wifi analyser ranks
| View | Ranked by | Zeek parallel | Why it matters |
|---|---|---|---|
| Top Retransmitters | retry_rate_pct descending | LOG_WEIGHTS['conn'] + zscore_series() | One client at 40% retry = 40% airtime wasted on repairs. Find them first. |
| Slowest Handshakes | eapol_ms descending | scores.nlargest(n) on eapol_duration | Slow 4-Way = RADIUS latency, wrong PSK loop, or driver bug. Blocks client. |
| Most Anomalies | weighted anomaly score | score_conn_hybrid() per flow | Weights by severity: CRITICAL=10, HIGH=5, MEDIUM=2, LOW=1, INFO=0. |
| Lowest MCS at Good RSSI | (rssi - mcs_min_rssi) descending | score_isolation_forest() fallback | Identifies interference victims masquerading as weak-signal clients. |
| Longest Join Time | join_ms descending | bidirectional_duration_ms nlargest | Clients with join_ms >5000ms degrade UX even if everything else looks clean. |
| Most Deauths | deauth_count descending | LOG_WEIGHTS['notice'] * count | Deauth storms indicate roaming loops, RADIUS rejection, or active attack. |
| Highest Airtime Consumers | frames_count * avg_frame_size | LOG_WEIGHTS['conn'] weight | Legacy devices at low MCS inflate per-frame airtime, starving faster clients. |
| Top DHCP Delays | dhcp_ms descending | bidirectional_first_seen_ms | Hidden roam latency: a 50ms 802.11r roam can still produce 4s UX delay from DHCP. |
// how the weighted anomaly score is calculated
Each client session receives a composite anomaly score derived from the Zeek
LOG_WEIGHTS pattern adapted for 802.11 severity levels:
score = Σ (anomaly_count[severity] × weight[severity])
where weight = [object Object]
top_n = sorted(sessions, key=score, reverse=True)[:n]
where weight = [object Object]
top_n = sorted(sessions, key=score, reverse=True)[:n]
CRITICAL
10
1 KRACK = 10 pts
HIGH
5
2 EAPOL timeout = 10 pts
MEDIUM
2
5 retry storms = 10 pts
LOW
1
10 config warnings = 10 pts
INFO
0
Not scored
// triage workflow - how to use top n views in the field
01
Start with Top Anomalies
Sort by weighted score. Any client with a CRITICAL anomaly jumps to the top regardless of frame count. This immediately surfaces active attacks or catastrophic misconfigurations.
02
Cross-reference Top Retransmitters
A client at the top of both rankings (high anomaly score + high retry rate) has both a protocol problem and an RF problem. Address them in that order -- fix the protocol issue first, then verify if the retry rate improves.
03
Check join time for outliers
A client not in the top anomaly list but with join_ms >5000ms is causing UX pain silently. DHCP delay is the most common cause -- check dhcp_ms separately.
04
Validate with raw frames
Top N is a triage tool, not a verdict. Always click through to the raw frame sequence for any client in the top 3. The anomaly code tells you what happened -- the frames tell you exactly when and how.
See Top N views on your PCAP
WiFi Analyser ranks clients by weighted anomaly score, retry rate, and join time automatically on every upload.