v1.0.1 Changelog

This is a hotfix for two issues that surfaced after v1.0.0 went out.

No new features; routing, mesh, captive portal, and Bad-BT all behave identically to v1.0.0. Two corner-case bugs got smoothed over so the new on-device features work well.

Transfer Portal login: "Network error reaching device"

The Transfer Portal login was failing universally, with the popup "Network error reaching device" - the JS fetch's '.catch' block firing before any response touched the wire. The cause was browser CORS, not networking.

When a client connects to the Nano's access point, the operating system fires off a captive-probe to a well-known hostname ('captive.apple.com', 'msftconnecttest.com', etc.) to detect that it's behind a captive portal. The Nano's DNS hijack sends those probes back to itself, and the device used to serve the settings HTML inline at whatever path the probe hit. Result was that the settings page rendered in the browser with 'captive.apple.com' or whatever as its origin.

When the JS in that page then POSTed to 'http://192.168.4.1/auth' with 'Content-Type: application/json', the browser saw a cross-origin request, dropped out of the simple-CORS allowlist, and fired an OPTIONS preflight. The Nano's web server had no preflight handler, the preflight failed, and the actual POST was never sent. The browser surfaced this as a generic network error.

Fixed by making the page same-origin with the API. Any request whose 'Host' header isn't '192.168.4.1' now gets a 302 redirect to 'http://192.168.4.1' + the same URI. The captive sheet follows the redirect, the page renders with '192.168.4.1' as its origin, and the JS fetches stop being cross-origin. The login goes through cleanly.

If you saw "Network error reaching device" on v1.0.0, that's why - and v1.0.1 resolves it.

Config -> Changelog renders again

The in-device changelog viewer (Config -> Changelog) was failing on a fragmented heap. The viewer was holding the entire response body as one contiguous string allocation, which couldn't always be allocated after a long mesh session had carved up the heap into many small free blocks. The result was: open the viewer, watch it try to fetch, see it either error out or render nothing.

Fixed by streaming the response body straight into the wrapped-lines vector that the text viewer renders from. No contiguous allocation needed. The viewer now opens reliably regardless of how long the device has been running or how busy the mesh has been.