[Bug]: WiFi saturation on wireless host node / WLAN driver deadlock

PAIR version or commit

0.1.1 (0.1.1.463)

Affected component

Desktop application

Environment

OS: macOS 26.6.2 (25G83) on affected node (wireless host); peers run macOS (current)
Architecture: arm64 (Apple Silicon, Mac16,8) on all nodes
GPU and driver: Affected node — Apple Silicon integrated GPU (no NVIDIA GPU). WLAN driver: com.apple.DriverKit-AppleBCMWLAN (system DriverKit extension). Peers — Apple Silicon integrated GPUs.
Engine and version: PAIR 0.1.1 (0.1.1.463, com.nvidia.nvpair); engines: LM Studio 0.4.24 (headless llmster daemon) + Ollama on all nodes
Model: N/A on affected node (no model loaded); issue occurs with cluster idle — no inference running
Cluster size: 5 nodes (4 on wired Ethernet, 1 on WiFi — the affected host is the only wireless node)

Steps to reproduce

1. Set up a 5-node PAIR cluster: 4 nodes on Ethernet, 1 node on WiFi. Pair and trust all nodes.
2. Leave the cluster idle (no model loads, no jobs).
3. On the WiFi node, launch PAIR and leave it running for 8–10 minutes.
4. From the WiFi node, ping the local gateway continuously (1/s) while PAIR runs.
5. Observe latency for ~10 minutes, then quit PAIR and keep pinging.

Expected behavior

The wireless host's network stays healthy while PAIR runs: gateway latency stays in the single-digit
milliseconds with 0% loss, on any SSID. Cluster background traffic (discovery, sync, health polls)
should not meaningfully degrade the host's connectivity.

Actual behavior

After ~8 minutes of PAIR running on the wireless host, gateway latency explodes in continuous bursts
regardless of which SSID is selected:

Healthy (PAIR just launched): 3–12 ms, 0% loss
Degraded (after ~8 min): bursts up to 1,441 ms (also 1,169 / 1,118 / 1,085 / 1,048 ms...),
internet pings degrade in mirror -> bottleneck is the local link
Quit PAIR: instant recovery to 3–7 ms, 0% loss (reproduced twice)

In a worst case the same day, the WLAN driver itself wedged and was killed by macOS:
com.apple.DriverKit-AppleBCMWLAN crashed (SIGABRT, thread "WLANDextWatchdogDQ") with stack
IO80211DeadlockPolice::handleDextWatchdogTimer() -> DriverKit panic -> abort() —
a hard WiFi outage until the dext restarted. This was the only WLAN crash in 72h and never
reproduced outside PAIR execution.

Sanitized logs or screenshots

1) Ping timeline (gateway, 1/s, local times)
   11:48–11:55  PAIR running, healthy: 3–12 ms
   11:56–11:58  PAIR running, degraded: sustained bursts 300–1,441 ms; 0 timeouts
   11:58        PAIR quit -> recovery within one ping sample

2) PAIR cluster traffic during the degraded window (from nvpair.jsonl, 5 minutes):
   ~750 "cluster:trust-changed" events
   ~165 remote engine-status polls
   ~38 mDNS discovery cycles
   i.e. cluster writes fan-out to 4 peers every ~500 ms + multicast discovery, with
   zero PAIR-side errors (peers kept responding — the radio link itself saturated).

3) WLAN driver crash report (worst case, same day):
   Process:      com.apple.DriverKit-AppleBCMWLAN (system DriverKit extension)
   Termination:  SIGABRT (abort() called), thread "WLANDextWatchdogDQ"
   Crash stack (top frames):
     libsystem_kernel.dylib __pthread_kill
     libsystem_pthread.dylib pthread_kill
     libsystem_c.dylib abort
     DriverKit panic
     IO80211DriverKit IO80211DeadlockPolice::handleDextWatchdogTimer() (.cold.1)
     IO80211DriverKit IO80211DeadlockPolice::handleDextWatchdogTimer()
     IO80211DriverKit IO80211DQTimer::TimeOutOccurred_Impl(OSAction*, unsigned long long)
     DriverKit IOTimerDispatchSource::TimerOccurred_Invoke(...)
   Last DISASSOC logged ~35 s after crash capture; cascade of re-associations followed.

4) Ruled out:
   - PAIR installs no kernel/network system extension (pure userspace: app + launchd helper
     listening on no port + userspace proxies). Helper CPU ~0% at rest.
   - No interface errors on the wireless interface all day (0 Ierrs/Oerrs).
   - Issue does not occur on the 4 wired nodes (identical PAIR versions).

Confirmations

• I searched existing issues for duplicates.
• This is not a security vulnerability.
• I agree to follow the Code of Conduct.