N1: the tunnel checked with the device calling the peer, by name, with a preshared key (#8)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EhqxQ49eCju4CzKYNjZzwT

docs/milestones/N1.md

@@ -51,7 +51,7 @@ The issue asked for the libraries to be measured first. `esphome/wireguard` 0.4.
 
 ### Checks on the device (2026-10-07, against a WireGuard peer in a container)
 
-The test keys were made for the purpose and deleted. The device, on a guest Wi-Fi, can't open connections to the machine the test peer ran on, so **the peer called the device** (`ListenPort`), which WireGuard allows either way round.
+The test keys were made for the purpose and deleted. Two rounds: first with the device on a guest Wi-Fi that can't open connections to the machine the test peer ran on, so **the peer called the device** (`ListenPort`), which WireGuard allows either way round; then on a network where **the device called the peer**, as it normally would.
 
 | Check | Result |
 |---|---|
@@ -64,10 +64,13 @@ The test keys were made for the purpose and deleted. The device, on a guest Wi-F
 | "Start with Wi-Fi", then a restart | Up by itself 40 s after the restart, once Wi-Fi and the clock were there |
 | The peer silenced | After three minutes: "no answer yet", a Toast, `VPN` dim. With everything through the tunnel, an update check then fails: nothing leaves. The peer back: up again in under half a minute, and a Toast |
 | `vpn forget` | "not set"; DNS as before |
+| **The device calling the peer**, the server given by name, with a PresharedKey and `MTU = 1280` | Up in seconds; the peer shows the device's address and port as the endpoint; pings through it |
+| One subnet: a connection the device opens to the peer's tunnel address | Seen inside the tunnel at the peer |
+| Everything: a Gemini page from a public capsule | Fetched (TLS, 1,184 bytes), and seen inside the tunnel at the peer. Free memory fell to 45.9 KB at the lowest |
 | Memory | 106.1 KB free before, 104.3 KB with the tunnel up, 106.2 KB after |
 | Settings > VPN | The four rows, the state and "heard 66 s ago", the server, the address; no key anywhere on it |
 
-**Not checked:** the usual direction, the device calling the server, which the test network didn't allow: it needs a server the device can reach. A server named by a host name (the test used an address). PresharedKey and MTU from a file (parsed and host-tested, not used on the air). Roaming from one Wi-Fi to another. IRC and Gemini through the tunnel. A day of uptime.
+**Not checked:** a real server across the internet (both rounds were on a local network). That the MTU is what limits a packet (larger pings were answered too, in pieces). Roaming from one Wi-Fi to another with the tunnel wanted. IRC through the tunnel. A day of uptime.
 
 ### What went wrong while building it
 

site/content/dev/milestones/n1.md

@@ -59,7 +59,7 @@ The issue asked for the libraries to be measured first. `esphome/wireguard` 0.4.
 
 ### Checks on the device (2026-10-07, against a WireGuard peer in a container)
 
-The test keys were made for the purpose and deleted. The device, on a guest Wi-Fi, can't open connections to the machine the test peer ran on, so **the peer called the device** (`ListenPort`), which WireGuard allows either way round.
+The test keys were made for the purpose and deleted. Two rounds: first with the device on a guest Wi-Fi that can't open connections to the machine the test peer ran on, so **the peer called the device** (`ListenPort`), which WireGuard allows either way round; then on a network where **the device called the peer**, as it normally would.
 
 | Check | Result |
 |---|---|
@@ -72,10 +72,13 @@ The test keys were made for the purpose and deleted. The device, on a guest Wi-F
 | "Start with Wi-Fi", then a restart | Up by itself 40 s after the restart, once Wi-Fi and the clock were there |
 | The peer silenced | After three minutes: "no answer yet", a Toast, `VPN` dim. With everything through the tunnel, an update check then fails: nothing leaves. The peer back: up again in under half a minute, and a Toast |
 | `vpn forget` | "not set"; DNS as before |
+| **The device calling the peer**, the server given by name, with a PresharedKey and `MTU = 1280` | Up in seconds; the peer shows the device's address and port as the endpoint; pings through it |
+| One subnet: a connection the device opens to the peer's tunnel address | Seen inside the tunnel at the peer |
+| Everything: a Gemini page from a public capsule | Fetched (TLS, 1,184 bytes), and seen inside the tunnel at the peer. Free memory fell to 45.9 KB at the lowest |
 | Memory | 106.1 KB free before, 104.3 KB with the tunnel up, 106.2 KB after |
 | Settings > VPN | The four rows, the state and "heard 66 s ago", the server, the address; no key anywhere on it |
 
-**Not checked:** the usual direction, the device calling the server, which the test network didn't allow: it needs a server the device can reach. A server named by a host name (the test used an address). PresharedKey and MTU from a file (parsed and host-tested, not used on the air). Roaming from one Wi-Fi to another. IRC and Gemini through the tunnel. A day of uptime.
+**Not checked:** a real server across the internet (both rounds were on a local network). That the MTU is what limits a packet (larger pings were answered too, in pieces). Roaming from one Wi-Fi to another with the tunnel wanted. IRC through the tunnel. A day of uptime.
 
 ### What went wrong while building it