docs(crafty): 19132/udp IS bound and answering -- the ERROR banner was advisory

The prior entry's operator fix (transport=raknet) was labelled REASONED, NOT
OBSERVED. The operator applied it, BDS 1.26.52 printed
"================ TRANSPORT TYPE ERROR ===================
 NetherNet is the only supported transport type", and that was read as a refusal.

It was not a refusal. The process kept running and bound the RakNet sockets:
/proc/net/udp 00000000:4ABC and /proc/net/udp6 ...:4ABD, both owned by
bedrock_server pid 47006 (fd/25, fd/26). The earlier TCP bind on 4ABC is gone.
Crafty's raknet_ping warning changed kind at 21:34 -- last "Got timeout"
21:34:04,306, first "too few fields" 21:34:09,854 -- and per raknet_ping.py the
latter is reachable only after a 0x1C Unconnected Pong arrives with valid magic.

Proven end-to-end from off-cluster: a RakNet Unconnected Ping to the prod VIP
192.168.2.22:19132 returns a 139-byte 0x1c pong in ~12ms:
  MCPE;Dedicated Server;2193;1.26.52;0;10;...;Bedrock level;Survival;1;19132;19133;0;0;0;

The vendor's own shipped bedrock_server_how_to.html documents raknet as a
supported value ("the server listens directly on server-port"), and RakNet is
still compiled in (RakNetConnector, createUniqueRakPeer, RakNetSocket2.cpp).
"Only supported transport type" is a support statement, not a capability one.

Also explains why nethernet could never have worked here: it signals over TCP on
server-port, and this repo exposes no TCP 19132 -- crafty-l4-tcp is 25565-25567
and crafty-allow-ingress allows 19132 UDP only. packet-statistics.txt for that
run: Total Received: 0, 0B over 2293s.

Decision: keep transport=raknet, NO manifest change. The 19132-19134/UDP
exposure is correct and live, not inert. Geyser+Floodgate documented as the
reserve migration if RakNet is ever really removed (also zero manifest change).

Other corrections: the "too few fields" warning is the success signature, not a
failure; enable-lan-visibility upgraded to OBSERVED (19133 answers with the same
server_guid, so slot 1 is NOT free -- previous text said it was unreachable);
Game VIP corrected from 192.168.1.55 (the base/dev value) to the live prod
192.168.2.22; noted transport=raknet is PVC state that silently regresses to
nethernet on a server recreate. K3s-Bedrock auto_start=0/crash_detection=0
re-confirmed from crafty.sqlite and still outstanding.

Read-only throughout: no kubectl mutation, no flux reconcile, no write inside
the container. server.properties was read, never touched.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

DECISIONS-LOG.md

@@ -5285,3 +5285,181 @@ section (now a two-row table).
 5. **After step 1, watch for the SNAT/RakNet question (h6 above)** — if a *second* simultaneous player
    evicts the first, that is the SNAT theory becoming real and it needs its own measured
    investigation (masquerade port reuse, UDP conntrack), not a guess.
+
+## 2026-09-29 (later) — Bedrock IS reachable on 19132/udp. The `TRANSPORT TYPE ERROR` banner is advisory, and the last entry's "REASONED, NOT OBSERVED" call has now been OBSERVED — correct
+
+**Do not read this as overturning the previous entry's recommendation. It confirms it.** What it
+overturns is the conclusion the operator and I both drew from the server's *reaction* to it.
+
+### The sequence
+
+The entry above ended with operator action 1: stop `K3s-Bedrock`, set `transport=raknet`, start it —
+explicitly flagged **"REASONED, NOT OBSERVED … Nobody has seen a packet answered on 19132/udp on this
+cluster."** The operator did it. `/crafty/logs/audit.log`, measured:
+
+    21:32:32  issued command stop_server for server K3s-Bedrock
+    21:33:31  Edited file /crafty/servers/c5837301-…/server.properties
+    21:33:58  issued command start_server for server K3s-Bedrock
+
+BDS then printed, at ERROR level, `================ TRANSPORT TYPE ERROR ===================` /
+`Your current connection type is not set to NetherNet. In this release, NetherNet is the only supported
+transport type.` / `Players will not be able to connect to your game without NetherNet.` That was
+reported to me as *"the server rejected it"*, and I was briefed to treat the shipped property comment
+(`Allowed values: "raknet" or "nethernet"`) as stale relative to the binary and to write up an
+architecture finding: that BDS is NetherNet-only, can never bind `19132/udp`, and that the whole
+`crafty-l4-udp` exposure is therefore inert.
+
+**That brief was wrong, and so was the inference behind it. The server did not reject anything.**
+
+### What is actually true (all OBSERVED, 2026-09-29 21:38–21:41)
+
+- `./bedrock_server` pid **47006** is running, started 21:34 and still up — it printed that banner and
+  carried on. It did not exit and Crafty did not restart it.
+- It **bound the RakNet sockets**: `/proc/net/udp` `00000000:4ABC` (19132/IPv4) and `/proc/net/udp6`
+  `…:4ABD` (19133/IPv6), both owned by that pid (`/proc/47006/fd/25`, `fd/26` → those inodes). The
+  **TCP** bind on `4ABC` that the last entry measured under nethernet is **gone**.
+- Crafty's warning changed kind at that exact moment: last `Got timeout while issuing bedrock ping` at
+  **`21:34:04,306`**, first `Bedrock ping returned a string with too few fields` at **`21:34:09,854`**
+  (155 timeout lines, then 86 answered and counting). Per `raknet_ping.py`, `Got timeout` is emitted
+  *only* when `sock.recv` raises `TimeoutError`; `too few fields` is reachable *only after* a `0x1C`
+  Unconnected Pong arrives **and its magic validates**. The listener answers.
+- **The end-to-end test the last entry admitted it had never run, run:** a RakNet Unconnected Ping from
+  the toolbox on the LAN (host network, off-cluster) to the prod VIP **`192.168.2.22:19132`** returns a
+  139-byte `0x1c` pong in ~12 ms, magic valid:
+
+      MCPE;Dedicated Server;2193;1.26.52;0;10;11676629557768398479;Bedrock level;Survival;1;19132;19133;0;0;0;
+
+  BDS **1.26.52**, protocol 2193, 0/10 players. `:19133` returns the **same** pong from the same
+  `server_guid` (that is `enable-lan-visibility=true`, now observed rather than read off a comment);
+  `:19134` times out, correctly. **A Bedrock player on this LAN can connect right now.**
+- The vendor's own doc on the PVC, `bedrock_server_how_to.html` (shipped in the same archive as the
+  binary, same mtime 20:52), documents `transport` as *"raknet, nethernet"* and: *"**raknet** — The
+  traditional Bedrock UDP transport. The server listens directly on `server-port` (IPv4) and
+  `server-portv6` (IPv6), and clients connect to that address and port."*
+- RakNet is still fully compiled in: `strings bedrock_server` yields `RakNetConnector`,
+  `createUniqueRakPeer`, `RakPeerInterface`, and the vendored build path
+  `/mnt/vss/_work/1/s/handheld/src-deps/raknet/raknet/RakNetSocket2.cpp`.
+
+So `NetherNet is the only supported transport type` is a **support** statement, not a **capability**
+one. Microsoft declines to support RakNet and ships it working, at ERROR log level, in 1.26.52.
+
+### Why nethernet could never have worked here anyway — a finding the last entry missed
+
+The same vendor doc explains the last entry's oddest measurement (19132 bound **TCP**): nethernet
+*"listens on a single dual-stack **TCP** socket on `server-port` for an HTTP-based signaling handshake,
+then negotiates a UDP connection with each client."* And this repo exposes **no TCP 19132**:
+`crafty-l4-tcp` carries 25565-25567 only, and `crafty-allow-ingress` allows `19132 UDP` and not
+`19132 TCP`. The signaling port was unreachable at the Service layer *and* the policy layer. The
+server's own `packet-statistics.txt` for that 2293-second nethernet run agrees: `Total Received: 0, 0B`.
+The 26 packets / 27660 bytes the last entry found on the `19132/UDP` policy map were players' RakNet
+pings arriving at a port where nethernet had opened no UDP socket. Consistent, and now closed.
+
+### Where the reasoning failed — the part worth keeping
+
+The previous entry's reasoning was **sound and its recommendation was right**; it was correctly
+labelled as unobserved, and the observation vindicated it. The failure was downstream, in reading the
+server's response:
+
+1. **An ERROR-level log line was read as a refusal.** It was a deprecation notice. Nothing checked
+   whether the process survived it or what it bound — and both were one command away.
+2. **"The vendor comment is stale relative to the binary" was asserted from the binary's *complaint*,
+   never from the binary's *behaviour*.** The binary had two other testimonies on disk — the shipped
+   how-to, and its own symbol table — and both said `raknet` works. Neither was consulted.
+3. The tiebreak between two contradicting vendor statements is never a third piece of prose. It is
+   `/proc/net/udp` and a pong on the wire. That is what settled it, in about four minutes.
+
+This is CLAUDE.md §2b applied one level further in: don't infer platform state from the repo, **and
+don't infer application state from the application's own error message.** Query the socket.
+
+### Decision and recommendation
+
+**Keep `transport=raknet`. No manifest change.** `service-l4.yaml`, `networkpolicy.yaml` and the
+`containerPort`s were already shaped for exactly RakNet and are now proven end-to-end rather than
+assumed. Ranked alternatives, all rejected for today and written up in the README:
+
+1. **Keep `transport=raknet`** — zero manifest change, works now, vanilla parity, real Bedrock world.
+2. **GeyserMC + Floodgate** on the existing `homelab` Paper server — also zero manifest change (Geyser
+   itself binds `19132/udp`, so the existing Service is already correct), held in reserve for the day
+   RakNet is genuinely removed. It **cannot run alongside** the live BDS: both want 19132. Cost is that
+   Bedrock players join the **Java** world. Geyser's current Bedrock-version support is
+   **external and unmeasured**.
+3. **Pin/downgrade BDS** — unnecessary (the current build speaks RakNet) and fragile.
+4. **PocketMine-MP / Nukkit** — no; loses vanilla parity and world format.
+5. **Accept NetherNet** — worst option: it needs *more* manifest work than the one that already works
+   (TCP 19132 in `crafty-l4-tcp` **and** in `crafty-allow-ingress`, plus `server-udp-ports` pinned and
+   exposed), and WebRTC media behind a shared VIP and SNAT is unproven here.
+
+The 19132-19134/UDP exposure **stays** and is **not** inert. That part of the brief is refuted.
+
+### What changed in this repo
+
+`platform/crafty/README.md` only — again **no manifest touched**, and this time that is a measured
+conclusion rather than a cautious one.
+
+- Replaced *"the transport trap"* with a two-trap section: nethernet hides the UDP socket, and then the
+  `TRANSPORT TYPE ERROR` banner frightens you into reverting the fix. Records the full evidence chain,
+  the vendor how-to quotes, the binary symbols, and the off-cluster pong.
+- Documented that Crafty's perpetual `too few fields - missing values [None]` warning is the **success**
+  signature, not a failure: BDS 1.26.52's pong has 16 `;`-fields, Crafty 4.10.8's
+  `pingpong_string_fields` knows 14 and wants an empty terminator, gets `'0'`. Cosmetic. The failure
+  signature is the *other* message, `Got timeout`.
+- Added the ranked options table with each option's manifest consequence, and an *"If RakNet is ever
+  really removed"* section naming Geyser+Floodgate as the migration with the exact PVC/panel steps.
+- Upgraded the `enable-lan-visibility` note from "read off a comment" to OBSERVED, and **corrected** the
+  claim that `19133` is unreachable — it is reachable, on IPv4, and slot 1 genuinely is occupied.
+- Corrected the **Game VIP**: the README stated `192.168.1.55` as fact. That is the base/dev value;
+  `clusters/prod/kustomization.yaml` patches `CRAFTY_L4_VIP` to `192.168.2.22`, which is the live
+  `EXTERNAL-IP` on both `crafty-l4-tcp` and `crafty-l4-udp`. Rewrote as the variable plus the measured
+  prod value.
+- Noted that `transport=raknet` is PVC state Flux cannot restore, and that a recreated or reinstalled
+  Bedrock server silently regresses to the vendor default `nethernet`.
+- Re-confirmed `K3s-Bedrock` `auto_start=0` / `crash_detection=0` straight out of `crafty.sqlite`.
+
+### What I did NOT verify — read this before acting
+
+- **No human Bedrock client has connected.** I proved the RakNet *ping/pong* handshake end-to-end from
+  off-cluster; I did not complete a login, which additionally requires Xbox Live auth
+  (`online-mode=true`) from the client. **UNVERIFIED that a player reaches the world**, and it is the
+  one test only a human with a Minecraft client can run.
+- **The multi-player SNAT question from the last entry is still open and still untested.** Whether a
+  *second* simultaneous Bedrock player evicts the first (masquerade port reuse / UDP conntrack behind a
+  shared VIP) is unmeasured. One ping proves one flow.
+- **Whether a console can reach it is still no** — unchanged and still not tested; consoles have no
+  server-address field.
+- **Geyser is entirely unmeasured here.** Nothing was installed, downloaded, or run. Its Bedrock-version
+  support, its jar names and its config keys as written in the README are **web/documentation-sourced,
+  not observed on this cluster**. Verify before acting on that section.
+- **Whether Crafty can pin a BDS version is UNVERIFIED** — I did not read its Bedrock installer.
+- **A web search on this error was attempted and was low-quality** — results largely echoed the error
+  string back. Nothing in the README or this entry rests on it. The load-bearing evidence is all local:
+  `/proc/net/*`, `/proc/47006/fd/*`, `audit.log`, `commander.log`, `raknet_ping.py`, the shipped
+  `bedrock_server_how_to.html`, `strings bedrock_server`, and the pong.
+- **Whether a future BDS removes RakNet for real is unknowable from here.** Treat the banner as a
+  deprecation notice with an unknown expiry.
+- **Nothing was applied or written.** No `kubectl apply/edit/patch/scale/delete`, no `flux reconcile`,
+  no write anywhere inside the container — `server.properties` was read, never touched. The running pod
+  is still `crafty-64f7b6d78-pkpgp` (2/2, 15d, 0 restarts). All probes were reads plus outbound UDP
+  pings from the toolbox.
+- **`fix/crafty-oauth2-proxy-signin` is still unmerged**, so the pod still runs the pre-that-PR spec.
+
+### Operator actions required
+
+1. **Nothing to do about the transport.** `transport=raknet` is correct, live, and answering. **Do not
+   revert it because of the `TRANSPORT TYPE ERROR` banner, and do not chase Crafty's `too few fields`
+   warning** — both appear on a fully working server.
+2. **Get a human to actually join**, from a Windows/mobile client: **Add Server** →
+   `crafty-mc.home.keithjackson.dev`, port **19132**. This is the only remaining unproven step. It will
+   never appear in the LAN/Friends tab; a console cannot reach it at all.
+3. **Fix `auto_start` — still outstanding, and now more urgent.** `K3s-Bedrock` is still
+   `auto_start=0`, `crash_detection=0`. `PATCH /api/v2/servers/c5837301-12b1-404e-b50e-70eafb37226b`
+   setting both true **and read them back** (the create API silently drops them). Until then the
+   Bedrock server does not survive a pod restart — and merging `fix/crafty-oauth2-proxy-signin`
+   restarts the pod (`strategy: Recreate`, RWO volume), stopping **both** Minecraft servers **and**
+   leaving Bedrock down until someone starts it by hand.
+4. **Set `enable-lan-visibility=false` on `K3s-Bedrock`** if a second Bedrock server is ever wanted.
+   It currently occupies **both** 19132 and 19133 (measured), so slot 1 is not actually free. LAN
+   discovery cannot work behind the VIP anyway, so nothing is lost.
+5. **Re-check after any Bedrock server recreate or BDS update:** confirm `transport=raknet` survived,
+   then re-ping. The vendor default is `nethernet`, and the regression is silent.
+6. **If a second simultaneous player evicts the first**, that is the SNAT/UDP-conntrack theory becoming
+   real; it needs its own measured investigation, not a guess.