enricobuehler
6774c4e7a2
The host's arming check asked `ethtool` about every NIC, which is the wrong question for Wi-Fi: the magic-packet trigger lives in nl80211's WoWLAN state, and most wireless drivers print `Wake-on: d` whether or not it is armed. An armed Wi-Fi host was therefore told it was NOT armed, and handed an `ethtool -s wlan0 wol g` its driver rejects. A NIC with an nl80211 phy (`/sys/class/net/<i>/phy80211`) is now asked `iw phy <phy> wowlan show` instead, and the warning carries WoWLAN-correct guidance — `iw ... wowlan enable magic-packet`, plus the NetworkManager `802-11-wireless.wake-on-wlan magic` that survives a reconnect. Two fallbacks for when `iw` can't answer (missing binary, driver without the command, or privilege the user-level host service lacks): a POSITIVE ethtool reading counts (brcmfmac & co do report there), a negative one never does, and sysfs `device/power/wakeup` reading `disabled` is conclusive in the negative. The client sender now emits from a socket bound to EACH non-loopback interface's own address rather than leaving the path to the routing table. A station in WoWLAN sleep stays associated and its AP buffers broadcast frames for it until the next DTIM beacon — but only if the datagram reaches the wireless segment at all, and with a VPN or mesh interface holding the default route `255.255.255.255` never did. A failed bind falls back to the routed socket, so no segment is lost. Tests: `iw`/`ethtool` output parsing split from the commands so both are unit- tested on any platform, and a new end-to-end test asserts a real listener receives the 102 magic-packet bytes. Verified on Linux (Ubuntu 26.04, 12 interfaces): `cargo fmt --all --check`, `cargo clippy -p punktfunk-core -p punktfunk-host --all-targets --locked -- -D warnings`, and both wol test sets green. NOT yet exercised against real Wi-Fi hardware — no Wi-Fi Linux box was reachable.
punktfunk-docs
The Punktfunk documentation site: Fumadocs on TanStack Start (Vite + Nitro/bun preset).
Content lives in content/docs/ as .md/.mdx. This site is the source of truth
for the user-facing guides; design rationale lives in the internal punktfunk-planning repo.
API reference
/api renders the host's management REST API as an interactive
Scalar reference (linked from the top nav, the docs
sidebar, and the landing page). It reads public/openapi.json — a
snapshot of the repo's generated spec. Refresh it after a management-API change:
# from the repo root — regenerate the spec, then copy the snapshot in:
cargo run -p punktfunk-host -- openapi > api/openapi.json
cp api/openapi.json docs-site/public/openapi.json
Nothing in CI diffs the two, so the snapshot goes stale silently — that manual cp is the only
thing keeping them in sync. Before publishing docs, check that they match:
diff <(jq -S . api/openapi.json) <(jq -S . docs-site/public/openapi.json)
That should print nothing. Right now it doesn't: the committed snapshot predates the
/api/v1/update/check, /api/v1/update/apply and /api/v1/update/status endpoints, so the
published /api reference is missing the host self-update surface — re-copy it.
Develop
bun install
bun run dev # http://localhost:3001 (docs at /docs)
CI gates every change on bun run build followed by bun run lint (the TypeScript typecheck), in
that order — the build emits the .source typegen the typecheck imports. Run both before you push.
Build & serve
bun run build
bun run start # serves .output/ via Bun
Layout
source.config.ts Fumadocs MDX collection (content/docs)
content/docs/ the docs content (.md/.mdx) + meta.json nav
src/
routes/
__root.tsx RootProvider + html shell
index.tsx landing page
docs/$.tsx catch-all docs renderer (Fumadocs DocsLayout)
api/index.tsx Scalar API reference (reads public/openapi.json)
api/search.ts Orama search endpoint
lib/source.ts Fumadocs loader over the generated collection
lib/layout.shared.tsx shared nav chrome
components/mdx.tsx MDX component map
styles/app.css Tailwind 4 + Fumadocs preset