Silent wifi wedge on Apple BCM4360 / broadcom-wl (link stays "connected", DHCP dies) — watchdog mitigation included

[jethrojones]

System details

Omarchy 4.0.0 (Quattro dev branch, omarchy-dev 4.0.0.r1387.gd3fdaca-1), Linux 7.1.5-arch1-1, Mac Mini (Apple-branded BCM4360 802.11ac wifi, PCI subsystem Apple Inc. Device 013b), driver: wl (broadcom-wl, out-of-tree).

What's wrong?

Wifi silently stops passing traffic after some hours of uptime, without ever showing as disconnected. Link stays associated (the interface keeps receiving LAN broadcast/multicast frames from other devices — confirmed via ufw kernel logs), but DHCP lease renewal stops succeeding and nothing above the driver notices anything is wrong. No amount of nmcli/networkctl retry logic recovers it — only a full reboot brings the interface back.

This looks like the same root cause as #5398 (broadcom-wl on BCM4360, closed as a CPU/IRQ-storm symptom on a MacBook Air 2015) — same driver bug, different manifestation. Filing separately since the symptom and evidence trail are different enough to be useful to future searchers, but I believe they share a root cause.

Diagnostic evidence

Kernel warns about the driver at every boot:

You are using the broadcom-wl driver, which is not maintained and is
incompatible with Linux kernel security mitigations. It is heavily
recommended to replace the hardware and remove the driver. Proceed at
your own risk!

And there's an active memory-safety bug logged during BSS/scan-result processing:

memcpy: detected field-spanning write (size 400) of single field "dst" at
src/wl/sys/wl_cfg80211_hybrid.c:3139 (size 0)
WARNING: src/wl/sys/wl_cfg80211_hybrid.c:3139 at wl_inform_single_bss+0x2de/0x470 [wl]
 ? wl_notify_scan_status+0x12d/0x290 [wl]

This is the same function (wl_inform_single_bss, reached via wl_notify_scan_status) flagged in #5398, just a different line offset (driver/kernel version drift). I also have an ERROR @wl_notify_scan_status from the driver on an earlier, unrelated boot days before this incident — so this code path appears to fault intermittently over time, not just once.

Timeline of one occurrence (from journalctl, NetworkManager unit):

• Lease renewals on wlp2s0 had been succeeding like clockwork, roughly every 24 minutes, for the prior ~4 hours of uptime.
• 21:45:11 — a DHCPv6 renewal attempt returns state changed no lease.
• Total silence from NetworkManager for the next ~10h 45m — no further renewal attempts, no state changes, nothing — until the box was rebooted the next morning for an unrelated reason.
• Throughout that entire silent window, kernel-level firewall logs show wlp2s0 still receiving mDNS/multicast frames from other LAN devices — i.e. the radio stayed associated to the AP the whole time. The failure is above the link layer, consistent with the driver's internal state getting corrupted rather than a clean disconnect.

What I'm doing about it (mitigation, not a fix)

Since the actual bug lives in the out-of-tree wl driver (unmaintained, as the kernel itself says), there's no real fix available from userspace — killing/reloading the wl module doesn't reliably recover it, and even rfkill cycling isn't consistent. So instead of trying to fix the driver, I built two systemd units that detect the wedge and force recovery within minutes instead of leaving the box dark until someone notices and power-cycles it.

1. A 5-minute watchdog that pings out and forces reconnection on failure:

/etc/systemd/system/network-watchdog.timer

[Unit]
Description=Internet Connectivity Watchdog (every 5 min)

[Timer]
OnBootSec=2min
OnUnitActiveSec=5min
AccuracySec=30s

[Install]
WantedBy=timers.target

/etc/systemd/system/network-watchdog.service

[Unit]
Description=Internet Connectivity Watchdog
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/network-watchdog.sh

/usr/local/bin/network-watchdog.sh

#!/bin/bash
# Checks internet via IP ping (bypasses DNS). Tries soft recovery if down.
# Logs state changes to systemd journal. Run every 5 min via systemd timer.

STATE_FILE="/run/network-watchdog-state"
PING_TARGET="1.1.1.1"
PING_COUNT=3
PING_TIMEOUT=5

internet_up() {
    ping -c "$PING_COUNT" -W "$PING_TIMEOUT" -q "$PING_TARGET" &>/dev/null
}

log() { logger -t network-watchdog "$*"; }

wifi_iface() {
    nmcli -t -f TYPE,DEVICE device status | awk -F: '$1=="wifi"{print $2; exit}'
}

prev_state=$(cat "$STATE_FILE" 2>/dev/null || echo "unknown")

if internet_up; then
    echo "up" > "$STATE_FILE"
    if [[ "$prev_state" == "down" ]]; then
        log "RESTORED: internet is back (was down since $(cat /run/network-watchdog-down-since 2>/dev/null || echo unknown))"
        rm -f /run/network-watchdog-down-since
    fi
    exit 0
fi

# Internet is down
echo "down" > "$STATE_FILE"
if [[ "$prev_state" != "down" ]]; then
    date --iso-8601=seconds > /run/network-watchdog-down-since
    log "DOWN: internet lost — attempting recovery"
fi

# Attempt 1: flush and restart systemd-resolved
log "recovery step 1: restarting systemd-resolved"
systemctl restart systemd-resolved
sleep 3
internet_up && { echo "up" > "$STATE_FILE"; log "RESTORED after systemd-resolved restart"; rm -f /run/network-watchdog-down-since; exit 0; }

# Attempt 2: reconnect wifi via NetworkManager (interface detected dynamically,
# since it has renamed before — wlan0 -> wlp2s0 — when the network stack changed)
iface=$(wifi_iface)
if [[ -n "$iface" ]]; then
    log "recovery step 2: reconnecting $iface via NetworkManager"
    nmcli device disconnect "$iface" &>/dev/null
    nmcli device connect "$iface" &>/dev/null
else
    log "recovery step 2 skipped: no wifi device found"
fi
sleep 5
internet_up && { echo "up" > "$STATE_FILE"; log "RESTORED after NetworkManager reconnect"; rm -f /run/network-watchdog-down-since; exit 0; }

log "recovery failed — internet still down (router/ISP issue likely)"
exit 1

The key part for anyone on wl/BCM4360: since the driver wedges above the link layer (radio stays associated, so nmcli/iwctl will report "connected" the whole time), a plain "is the device connected?" check won't catch it — you need an actual ping/DNS check, then a disconnect+reconnect cycle through NetworkManager to force the driver to renegotiate.

2. A boot-time check for a related-but-separate flakiness, where NetworkManager's own autoconnect sometimes just doesn't fire after boot:

/etc/systemd/system/nm-wifi-watchdog.service

[Unit]
Description=Ensure wifi auto-connects after boot (NetworkManager)
After=NetworkManager.service
Requires=NetworkManager.service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/nm-wifi-watchdog.sh

[Install]
WantedBy=multi-user.target

/usr/local/bin/nm-wifi-watchdog.sh

#!/bin/bash
# Waits after boot, then forces the wifi connection up if NetworkManager
# has not auto-connected yet.
# Interface is detected dynamically (not hardcoded) since it has renamed
# before (wlan0 -> wlp2s0) when the network stack changed.

sleep 20

iface=$(nmcli -t -f TYPE,DEVICE device status | awk -F: '$1=="wifi"{print $2; exit}')
if [[ -z "$iface" ]]; then
    logger -t nm-wifi-watchdog "no wifi device found"
    exit 0
fi

state=$(nmcli -t -f DEVICE,STATE device status | awk -F: -v d="$iface" '$1==d{print $2}')
if [[ "$state" == "connected" ]]; then
    logger -t nm-wifi-watchdog "$iface already connected, no action needed"
    exit 0
fi

logger -t nm-wifi-watchdog "$iface not connected (state: $state) after boot, forcing connection up"
nmcli device connect "$iface"

Verified this is actually doing something, not just cargo-culted: I disabled network-watchdog.timer for ~39 hours as a deliberate test to see if the box was stable without it. It wasn't — the wedge described above happened during that exact window and sat unreachable for nearly 11 hours with zero recovery attempts, until I rebooted it manually. Re-enabled the timer immediately after confirming that.

Neither unit fixes the underlying driver bug — they just cap the outage at 5 minutes instead of "until someone notices." Posting mainly so:

1. This is searchable for the next person who hits a Mac + broadcom-wl box that goes silently unreachable rather than cleanly disconnecting.
2. To flag to maintainers that broadcom-wl on BCM4360 hardware (at least Mac Mini + MacBook Air 2015, per Severe CPU degradation on MacBook Air 2015 caused by broadcom-wl (BCM4360) IRQ storm on kernel 6.19 #5398) has at least two independently-observed failure modes (CPU/IRQ storm, and this silent network wedge) traced to the same wl_inform_single_bss memory-safety warning — might be worth a documented known-issue / hardware-compatibility note for anyone installing Omarchy on older Apple hardware with this chip, given the driver itself is unmaintained upstream.