# AeroTUN live deployment — 2026-10-30

Both `debtik` services were upgraded through independent management SSH.
The local host is Linux amd64 using the veth fallback; `192.168.132.45` is Linux
arm64 using native TUN. Each received the correct architecture build.

The existing generated PSK and overlay configuration were preserved:

| Setting | Local | Remote |
| --- | --- | --- |
| Mode | client | server |
| Overlay address | 172.16.233.2/30 | 172.16.233.1/30 |
| Outer endpoint | 192.168.132.45:51830 | learned authenticated peer |
| Configured maximum MTU | 1420 | 1420 |

The effective MTU initially negotiated to 1332 based on the client's WireGuard
link. The remote route subsequently reported a cached path MTU of 1380, so both
peers converged to **1292** (1380 minus 88 bytes of IPv4/UDP/AeroTUN overhead).
Control packets advertise the effective MTU. A newly lowered value is announced
immediately, rather than leaving one direction oversized until the next periodic
keepalive. Regression tests model different MTUs on the two underlay interfaces.

## Live measurements

These are short samples of a variable routed connection, not a maximum capacity
claim. Tests targeted the overlay addresses, with ordinary incompressible iperf3
payloads. Separate underlay tests bypassed AeroTUN.

| Test | Received rate | Notes |
| --- | ---: | --- |
| Original implementation, TCP | no connection | control connection timed out; ping still worked |
| AeroTUN TCP local → remote | 12.443 Mbit/s | two TCP streams, 5 seconds |
| AeroTUN TCP remote → local | 24.641 Mbit/s | two TCP streams, 6 seconds |
| AeroTUN UDP local → remote | 4.947 Mbit/s | target 5 Mbit/s; 0% loss |
| Underlay TCP local → remote | 10.343 Mbit/s | two TCP streams, 6 seconds |
| Underlay TCP remote → local | 38.970 Mbit/s | two TCP streams, 6 seconds |

The earlier one-stream reverse TCP sample was 2.726 Mbit/s. Parallelism and
congestion significantly affect these short measurements. Underlay TCP also
showed retransmissions; AeroTUN telemetry showed no authentication failures or
replay drops. These comparisons do not isolate all overhead or prove that the
remaining throughput limit is solely outside AeroTUN.

## Built-in Bandwidth Test fixes

Testing the real application's benchmark revealed two independent problems:

1. TCP data, JSON control messages, and reports shared a byte stream with multiple
   readers. Readers could consume each other's bytes and raw writes could
   interleave control reports with test data.
2. The limiter capped its bucket at 100 ms of tokens. At 2 Mbit/s that is 25 KB,
   so a 64 KB TCP block could never accumulate enough tokens and never be sent.

Before these fixes, a live four-second bidirectional TCP test at a 2 Mbit/s limit
reported **zero transmitted bytes**. Its small reported RX value was control
traffic incorrectly consumed as data.

TCP tests now negotiate `frames-v1` in the JSON handshake, use one reader and
serialized framed writes, and count only data payload. Unsupported old TCP peers
receive an explicit upgrade error. UDP control framing remains unchanged. The
limiter can accumulate one complete block and can be interrupted on cancellation.
Generated benchmark payloads are random rather than all zeroes, to avoid measuring
compression of synthetic padding as if it were ordinary link capacity.

Regression tests cover bidirectional framing, TX/RX/both, low-rate large blocks,
stop/cancellation, malformed frames, and rejection of the old unframed TCP mode.
The unit/race tests and all repository tests pass.

After deploying the fixes to both hosts, the same four-second bidirectional
built-in test at a 2 Mbit/s limit delivered:

| Built-in test | TX | RX | Loss |
| --- | ---: | ---: | ---: |
| TCP | 1.966 Mbit/s | 1.966 Mbit/s | 0% |
| UDP | 2.024 Mbit/s | 2.024 Mbit/s | 0% |

TCP delivered 983,040 data bytes in each direction; UDP delivered 1,012,000 bytes
in each direction. Both tests completed without errors. Final telemetry on both
hosts showed `running=true`, `connected=true`, MTU 1292, zero authentication
failures and zero replay drops.

## Artifacts and recovery

Builds and raw benchmark JSON are stored under:
`/root/.local/share/debtik-builds/aerotun-v2/`.
The benchmark JSON contains no login credentials or session tokens.

Backups on **both** hosts:

- `/root/.local/share/debtik-backups/aerotun-v2-20261030T112440Z/` — original v1
  executable, AeroTUN configuration, complete application configuration, and
  interface/address/route snapshots.
- `/root/.local/share/debtik-backups/aerotun-v2-20261030T113257Z/` — first working v2
  executable before the built-in Bandwidth Test fixes.

Rollback timers protected activation and were cancelled after validation. The
`committed` marker in each backup prevents its automatic rollback script from
running after success. A deliberate manual rollback requires removing that
marker's guard and coordinating both peers; v1 and v2 AeroTUN are incompatible.

The original persistent AeroTUN configuration was not changed. iperf3 was added
to the remote host for the measurements; its package service is inactive, and
transient benchmark listeners are stopped after testing.

## Follow-up: default UDP RX

A later default/unlimited UDP test exposed congestion and incorrect offered-TX
reporting that the fixed 2 Mbit/s checks had not covered. See the
[RX investigation and subsequent fix](bwtest-rx-fix.md).