twisla/roro9stack
Public Access
1
0
Fork 0
Code Issues 42 Pull Requests Actions Packages Releases 25 Activity

N1: the tunnel against a real server, reached at its tunnel address (#8)
CI / build (pull_request) Successful in 1m41s
Details
Site / build (pull_request) Successful in 9s
Details

Browse Source 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EhqxQ49eCju4CzKYNjZzwT
This commit is contained in:
twisla
2026-10-08 01:41:31 +02:00
co-authored by Claude Opus 5.5
parent 681f436ff4
commit 904c421b10
2 changed files with 6 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/milestones/N1.md
+3 -1
View File
@@ -70,7 +70,9 @@ The test keys were made for the purpose and deleted. Two rounds: first with the
| Memory | 106.1 KB free before, 104.3 KB with the tunnel up, 106.2 KB after | | 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 | | Settings > VPN | The four rows, the state and "heard 66 s ago", the server, the address; no key anywhere on it |
**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. **Against a real server** (the maintainer's own, 2026-10-08): a configuration uploaded from a phone through the Storage App's sharing (issue #88) and imported in Settings; the server named by host name, on a port of its own, the device's address a /32, everything through the tunnel, "Start with Wi-Fi" on. The tunnel is up, and from another machine the device answers on its tunnel address: pings, and the Debug Console.
**Not checked:** from a network far from the server (the device was on the server's own network, reaching it by its public name). 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 ### What went wrong while building it
site/content/dev/milestones/n1.md
+3 -1
View File
@@ -78,7 +78,9 @@ The test keys were made for the purpose and deleted. Two rounds: first with the
| Memory | 106.1 KB free before, 104.3 KB with the tunnel up, 106.2 KB after | | 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 | | Settings > VPN | The four rows, the state and "heard 66 s ago", the server, the address; no key anywhere on it |
**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. **Against a real server** (the maintainer's own, 2026-10-08): a configuration uploaded from a phone through the Storage App's sharing (issue #88) and imported in Settings; the server named by host name, on a port of its own, the device's address a /32, everything through the tunnel, "Start with Wi-Fi" on. The tunnel is up, and from another machine the device answers on its tunnel address: pings, and the Debug Console.
**Not checked:** from a network far from the server (the device was on the server's own network, reaching it by its public name). 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 ### What went wrong while building it