blekin/doc/plan/implementation.md

blekin — implementation plan

A Rust proxy that translates the Belkin OmniView Remote IP Manager's e-RIC RFB protocol (Peppercon LARA, served over a Java applet) into a modern HTML5 KVM console. The proxy speaks plain TCP to the OmniView, decodes the proprietary 8bpp protocol to RGBA, and bridges to a Vite/React frontend over WebSocket.

All Java references are paths under ~/rc-src/nn/pp/rc/ from the CFR-decompiled rc.jar. Line numbers reference the files as uploaded.

Target architecture

Browser (Vite + React + TS)
   │ WebSocket (binary, RGBA blits + input events)
   ▼
blekin (Rust, tokio + axum)
   │ HTTP session (cookie + APPLET_ID extraction)
   │ TCP to OmniView:443 (e-RIC RFB)
   ▼
Belkin OmniView Remote IP Manager

Workspace layout:

blekin/
├── Cargo.toml                     # workspace
├── crates/
│   ├── ericrfb/                   # pure protocol library, no IO
│   ├── ericrfb-proxy/             # tokio service: HTTP login + TCP + WS bridge
│   └── ericrfb-frontend/          # Vite/React/TS canvas client
└── PLAN.md

Protocol reference (one-page summary)

Every byte derives from aw.java, ac.java, and ByteColorRFBRenderer.java.

Wire facts:

• Read primitives are mixed: u8, u16-BE, varint (1–3 bytes, per aw.int() at line 484). Write primitives are u8 and u16-BE only.
• Pixel format is 8bpp RGB332 (mask 7 / 56 / 192). One byte per pixel on the wire. Decoded to 24-bit RGB via a 256-entry lookup table.
• Four hardcoded sub-palettes referenced by Hextile/Tight: 1bpp B/W, 2bpp gray, 4bpp gray, 4bpp 16-color. See ByteColorRFBRenderer.case() at line 691.
• Four parallel zlib streams (Inflater[4]) for Tight + encoding 9, indexed by bits 4–5 of the encoding control byte. State persists across rectangles — rectangles must not be skipped.

Handshake (aw.g() at line 226):

Step	Direction	Bytes	Source
1	C→S	75 bytes: "e-RIC AUTH=" + APPLET_ID, zero-padded, ISO-8859-1	line 259
2	S→C	1 byte status. 101 ('e') = OK. 3 = error (read 4 more, see aw.a(int))	line 264
3	S→C	15 bytes: "-RIC RFB MM.NN\n" (digits ASCII)	int(by) line 395
4	S→C	1 byte sync (w.new())	line 270
5	S→C	varint length + N bytes server name	l() line 413
6	S→C	1 byte sync	line 272
7	S→C	25 bytes pixel-format-ish struct	i() line 519
8	C→S	16 bytes: "e-RIC RFB " + PROTOCOL_VERSION + "\n"	try() line 405
9	C→S	2 bytes: [shared_flag, port_id]	char() line 425
10	S→C	1 byte sync	line 276
11	S→C	16 bytes ServerInit: [bX, w_u16, h_u16, bE, a, try, a3, x_u16, ao_u16, v_u16, bM, bW, bU, 3 pad]	k() line 435

After step 11, the client sends SetEncodings and a non-incremental FramebufferUpdateRequest, then enters the message dispatch loop.

Server-to-client message types (from ac.char() switch at line 244 of ac.java):

Type	Reader	Purpose
0	ac.f() → ac.e()	FramebufferUpdate
1	—	SetColourMapEntries (rejected)
2	—	Bell
3	aw.goto()	ServerCutText
7	aw.l()	server-name update
8	aw.e()	pixel-format change (reads 25-byte struct)
9	aw.else()	layout/locale string
16	aw.i()	desktop resize + name
17	aw.for()	2-byte ack (no-op)
128	aw.k()	mode change / framebuffer reinit
131	aw.d()	debug string
132	aw.long()	RFB-command channel: two strings (key, value)
148	aw.b()	ping — must respond with aw.if(0) (msg 149)
150	aw.do()	bandwidth measurement probe
161	aw.case()	RDP/Host-Direct mode events

Per-rectangle encoding dispatch (ac.e() at line 233 of ac.java):

Encoding	Renderer method	Notes
0	ByteColorRFBRenderer.if() line 98	Raw 8bpp, w×h bytes
1	ByteColorRFBRenderer.a() line 165	CopyRect
5	ByteColorRFBRenderer.int() line 169	Hextile (16×16, palette refs)
7	ByteColorRFBRenderer.a() line 244 → 324	Tight-derived
9	ByteColorRFBRenderer.do() line 248	IIP — defer
10	ByteColorRFBRenderer.for() line 109	Raw with tile-interleave flag

Client-to-server messages (writers in aw.java):

Byte	Method	Format
1	a(...) line 572	SetPixelFormat
2	a(int[], int) line 597	SetEncodings
3	a(...) line 562	FramebufferUpdateRequest
4	a(byte) line 655	KeyEvent (partial — see Phase 5)
5	a(false,...) line 612	PointerEvent: [5, mask, x_u16, y_u16]
7	a(String) line 418	ClientCutText
149	if(int) line 636	PingResponse [149, 0,0,0, n_u32]

---

Phase 0 — Repo & scaffolding

Goal: Empty workspace compiles. CI runs cargo test.

• cargo new --lib crates/ericrfb
• cargo new --bin crates/ericrfb-proxy
• Vite scaffold for crates/ericrfb-frontend (npm create vite@latest -- --template react-swc-ts)
• Workspace Cargo.toml pinning tokio = "1", axum = "0.7", bytes = "1", flate2 = "1", tracing = "0.1", anyhow, thiserror
• .envrc / direnv with RUST_LOG=ericrfb=debug,ericrfb_proxy=debug
• Forgejo Actions workflow on git.lair.cafe: build + test + clippy

Deliverable: cargo test green on a stub test in each crate.

---

Phase 1 — Protocol primitives (ericrfb/src/proto.rs)

Goal: Faithful Rust port of aw.java's read/write helpers. No I/O — all operations on &mut impl AsyncRead / &mut impl AsyncWrite (or Buf/BufMut for unit tests).

Java references:

• aw.int() line 484 — varint, 1–3 bytes, top bit = continuation. The single most important primitive; document it in a code comment with the exact byte examples.
• aw.new() line 454 — read_u8
• h.try(), h.do(), h.char(), h.byte() — wrapped i8/u8/i16/string reads through the h.java adapter class. Map to read_u8, read_u16_be, read-length-prefixed-string.
• aw.f() line 468 — rectangle header reader (varint x, varint y, varint w, varint h, u8 encoding). Critical — these coords are varints, not u16.

Tasks:

• read_varint / write_* primitives with property tests
• RectHeader { x: u32, y: u32, w: u32, h: u32, encoding: u8 }
• Length-prefixed-string reader with ISO-8859-1 decode
• Unit tests using fixed byte vectors — at least one for each primitive

Deliverable: cargo test -p ericrfb proto:: covers every primitive used later, with a property test ensuring write_varint(n) → read_varint = n roundtrips for n ∈ [0, 2²²).

---

Phase 2 — Handshake (ericrfb/src/handshake.rs)

Goal: Open a TCP socket to the OmniView, complete steps 1–11 of the table above, return a Session containing (width, height, pixel_format, name, read_half, write_half).

Java references:

• aw.g() line 226 — the connect-and-handshake sequence in full
• aw.int(byte) line 395 — server-version banner parser
• aw.try() line 405 — client version reply ("e-RIC RFB 01.11\n", exactly 16 bytes)
• aw.char() line 425 — 2-byte port-init message
• aw.k() line 435 — ServerInit reader
• aw.i() line 519 — pixel-format struct reader
• aw.a(int) line 350 — error code → string (1=no perm, 2=exclusive, 6=auth failed, etc.)

Tasks:

• Config { host, port, applet_id, protocol_version, port_id, shared }
• connect(cfg) -> Result<Session> walking all 11 steps with tracing spans
• Error type mapping the auth status code via aw.a(int)'s table
• Integration test gated behind OMNIVIEW_TEST_HOST env var that exercises the real device — skipped in normal CI

Deliverable: cargo run --example handshake -- --host 10.3.0.130 --applet-id $TOKEN prints Connected: name="Remote IP Manager", 640×480, RGB332 and exits cleanly. First real-protocol milestone.

---

Phase 3 — Session pump + Raw decoder (ericrfb/src/codec/raw.rs)

Goal: Receive a FramebufferUpdate containing only Raw rectangles, apply to a Framebuffer { width, height, pixels: Vec<u8> } (8bpp), expand to RGBA via LUT, write a PNG to disk.

Java references:

• ac.char() line 244 (of ac.java) — server-msg dispatch loop
• ac.f() line 213 → ac.e() line 165 — FramebufferUpdate reader
• aw.null() line 459 — FramebufferUpdate header (1 pad + u16 num_rects)
• aw.f() line 468 — per-rectangle header
• ByteColorRFBRenderer.if(x,y,w,h) line 98 — Raw decoder (read w*h bytes, blit at offset)
• ByteColorRFBRenderer constructor lines 57–74 — RGB332 → 24bpp LUT construction (DirectColorModel(8, 7, 56, 192))

Tasks:

• Framebuffer struct with apply_raw(rect, &[u8])
• Static RGB332_TO_RGBA: [u32; 256] table generated at compile time via const fn matching the Java mask layout
• Message-dispatch loop with match on type byte; only type 0 implemented, everything else returns "unhandled type N" error
• Send SetEncodings([0]) + FramebufferUpdateRequest(full, incremental=false)
• examples/snapshot.rs saves first frame as frame.png

Deliverable: cargo run --example snapshot produces a PNG of whatever the KVM is showing — POST screen, BIOS, OS console, whatever. This is the moment the project stops being theoretical.

---

Phase 4 — Hextile + ping + extension messages (ericrfb/src/codec/hextile.rs)

Goal: Long-running session that stays connected for hours and renders a sequence of frames. Tight not yet supported, but the simpler encodings carry us a long way.

Java references:

• ByteColorRFBRenderer.int() line 169 — Hextile decoder. Walk the 16×16 grid; for each tile read subencoding byte, then optionally bg/fg colors, optionally subrect count + per-subrect coords. Pre-defined palettes don't apply here — Hextile uses 1-byte direct color tokens only.
• ByteColorRFBRenderer.a(srcX, srcY, x, y, w, h) line 165 — CopyRect: trivial source→dest blit within the framebuffer
• aw.b() line 629 — ping reader (3 bytes ignored + 1 byte payload)
• aw.if(int) line 636 — ping response writer

Tasks:

• Hextile decoder, with subrect bit-flag handling matching lines 192–238
• CopyRect handler with overlap-safe copy_within semantics
• Wire up message types 2 (Bell, log only), 17 (no-op ack), 131 (debug string, log), 132 (RFB command, log key=value), 148 (ping → respond), 150 (bandwidth probe — echo per aw.do() line 642)
• Type 16 (resize) + type 128 (mode change) trigger framebuffer reallocation; emit a Event::Resize(w, h) to consumers
• examples/record.rs: 30-second session, save 1 PNG/sec to out/

Deliverable: A folder of timestamped PNGs from a real session showing boot/login/whatever activity. Connection survives ≥ 1 hour without dropping (verifies ping handling).

---

Phase 5 — Tight decoder (ericrfb/src/codec/tight.rs)

Goal: Server defaults to Tight when bandwidth matters; without this, full desktop refreshes are painfully slow. With Tight, video is fluid.

Java references:

• ByteColorRFBRenderer.a(x,y,w,h) line 244 → a(... null, 0, 0, 0) line 324 — Tight dispatcher. Read control byte n13. Top 4 bits = stream-reset flags
  • stream-id; bottom 4 bits = subencoding type.
• Subencoding 8 (line 348) — fill rect with 1-byte color
• Subencoding 15 (line 351) — fill rect with palette-indexed color (1-byte palette selector 1–4 → palettes C/x/L/I, then 1-byte index)
• Subencodings 0–7 (line 380) — zlib-compressed pixel data, optional palette filter (filter id 1 = palette mode, 2-color sub-palette from C/x/L/I)
• Subencodings 10–13 (line 432) — reduced bit-depth packed (1/2/4 bpp)
• aw.int() is reused for compressed-stream length (line 297, 457)
• case() at line 691 of the renderer — the four hardcoded sub-palettes, ported verbatim

Tasks:

• ZlibStreams { streams: [Option<Decompress>; 4] } with reset-on-flag logic matching lines 336–341
• Subencoding 8 (single-color fill)
• Subencoding 15 (palette-indexed fill)
• Subencoding 0–7 with optional filter byte: copy raw, palette-filtered (1-bit packed when palette size = 2)
• Subencoding 10–13: bit-unpacking via the predefined LUTs (ByteColorRFBRenderer.if() at line 580 is the reference)
• Constants module with PALETTE_2, PALETTE_4, PALETTE_GRAY16, PALETTE_COLOR16 ported from lines 691–735

Deliverable: SetEncodings advertises [7, 5, 1, 0, -250]. The example from Phase 4 runs at recognizable framerate. Bandwidth on tcpdump drops by ≥5× vs. Phase 4. Visual diff between Tight-decoded and Raw-snapshot frames is byte- identical for static screens.

---

Phase 6 — Input: keyboard and mouse (ericrfb/src/input.rs)

Goal: Send pointer events and keystrokes to the OmniView so the console is actually usable.

Java references:

• aw.a(boolean, int, int, int, int, int) line 612 — PointerEvent writer. Payload: [5, button_mask, x_u16, y_u16]. With bl=true, byte 0 becomes 147 for "exclusive/relative" mode — ignore for v1.
• MouseHandlerAbsolute.java — confirms button-mask bit layout matches RFB (bit 0 = left, bit 1 = middle, bit 2 = right, bit 3/4 = wheel up/down)
• KeyEventHandler.java + nn.pp.rckbd.* — the keyboard handler is more involved than the 2-byte aw.a(byte) writer suggests. Read KeyEventHandler to understand the multi-byte key sequences (HID-style, with separate press/release bytes per the KeyDef.java model).
• KbdLayout_104pc.java — US layout scancode tables, used as default
• KbdMapping_en.java (in rcsoftkbd) — alternate mapping path

Tasks:

• PointerEvent { mask: u8, x: u16, y: u16 } writer
• Browser-side: capture mousemove/mousedown/mouseup → WS frames
• Initial keyboard: send raw scancodes via msg type 4 with the 104pc layout table verbatim from KbdLayout_104pc.java
• Browser-side: keydown/keyup → JavaScript KeyboardEvent.code → lookup → scancode → WS frame
• CtrlAltDel button in UI sends the hotkey sequence from the HTML param HOTKEYCODE_0 ("36 f0 37 f0 4e " = Ctrl down, Alt down, Del down, Del up, Alt up, Ctrl up)

Deliverable: Type into BIOS, click in OS installer. The OmniView is genuinely usable.

---

Phase 7 — Proxy daemon (crates/ericrfb-proxy)

Goal: Long-running tokio service that holds a session per browser connection. HTTP login flow extracts the APPLET_ID; WebSocket upgrade hands off to the protocol pump.

Java references:

• RemoteConsoleApplet.if(boolean) line 312 of RemoteConsoleApplet.java — shows where APPLET_ID, PORT, HOST, PROTOCOL_VERSION are pulled from HTML <param>. Replicate by HTTP GET-ing /title_app.asp (or whatever the login flow lands on) and parsing the params from the returned HTML.
• The login HTTP flow itself is not in the jar — it's web UI. Capture it with browser DevTools' Network tab.

Tasks:

• axum server: POST /login proxies credentials to OmniView, scrapes cookies, reads /title_app.asp, extracts APPLET_ID and other params
• GET /ws/console upgrades to WebSocket, opens TCP to OmniView, runs handshake, then runs a bidirectional pump: - OmniView → decoder → RGBA blit messages → WS - WS → input event → PointerEvent/KeyEvent → OmniView
• Static-files handler serving the built Vite frontend from dist/
• Configurable via config.toml: bind addr, OmniView host, Step CA cert paths for mTLS-protecting the proxy itself
• systemd quadlet manifest for Podman deployment on whichever homelab host cichlid eventually places it

Deliverable: podman run blekin, navigate to its URL, log in, see the OmniView KVM in a browser tab. Works on any machine on the wireguard mesh, no Java anywhere.

---

Phase 8 — Frontend (crates/ericrfb-frontend)

Goal: Minimal, fast canvas-based renderer matching your stack preferences (Vite, React, SWC, TS).

No Java references — the frontend is pure WS-protocol consumer.

Tasks:

• Console.tsx: <canvas> sized to framebuffer dimensions; resize handler reallocates on Event::Resize
• decoder.ts: receive WS messages, dispatch on tag: - blit: ctx.putImageData(new ImageData(rgba, w, h), x, y) - copy: ctx.drawImage(canvas, srcX, srcY, w, h, x, y, w, h) - resize: reallocate canvas - ping: ignored (handled in proxy)
• input.ts: pointer + keyboard event capture, send as binary WS frames
• Toolbar: CtrlAltDel, full-screen, mouse-mode toggle
• Light/dark themes matching your other tools' aesthetic

Deliverable: A polished console UI that doesn't look like a 2005 Java applet.

---

Phase 9 — Optional: encoding 9 (IIP) and encoding 10

Goal: Performance parity with the original Java applet, only worth doing if encoding 7 (Tight) doesn't cut it in practice.

Java references:

• ByteColorRFBRenderer.do() line 248 — encoding 9 dispatcher
• ByteColorRFBRenderer.if(...) line 490 + line 580 — the per-tile delta application using the t[] cache
• t.java — the per-tile state class. Read this in full; it's stateful across rectangles in a way the other encodings aren't.
• ByteColorRFBRenderer.for(x,y,w,h) line 109 — encoding 10 (Raw with tile interleave); much simpler than encoding 9

Approach:

• Port t.java first as tile_cache.rs
• Encoding 10 is a quick win — basically Raw with a 16×16 deinterleave loop
• Encoding 9 needs the cache plumbed end-to-end. Get a known-good capture from a real Java session as ground truth. Compare frame-by-frame to validate.

Deliverable: Bandwidth and latency matching the original applet. May never be needed.

---

Phase 10 — Polish

• Virtual media (the Floppy/CD-ROM image redirection in the Belkin UI) — separate sub-protocol, not in ac.java. Probably documented in another aj/ac sibling class. Defer until everything else works.
• Reconnection logic: the OmniView drops sessions on reboot; reconnect with backoff
• Multi-port switching: the OmniView fronts an Avocent KVM — the port_id field in the ServerInit selects between attached HP servers
• mTLS between proxy and browser using your Step CA
• Quantum-safe TLS for the proxy's frontend listener (matches your preferences); the OmniView side stays plain TCP because the device can't do anything modern

---

Risk register

Risk	Likelihood	Mitigation
Encoding 9 needed for usable framerates	Low	SetEncodings doesn't advertise 9 unless user picks "advanced" mode in RemoteConsoleApplet.if(d2) line 423; default [255, 7, -250] works fine
Keyboard wire format more complex than aw.a(byte) suggests	Medium	KeyEventHandler.java is small; read it before Phase 6
HTTP login flow has CSRF / session-binding quirks	Medium	Capture with DevTools first; any irregularities are scriptable
Varint vs u16 confusion in aw	High during development	Strict types on proto.rs primitives; never use raw integers
Zlib stream desync from dropped/skipped rectangles	High if architecture wrong	Decoder owns the stream; consumers can drop output but never input

Success criteria

A working v1 ships when:

1. Browser tab on any device on the wireguard mesh shows the live OmniView KVM
2. Mouse and keyboard work for BIOS, OS installer, and running OS
3. Connection survives ≥ 8 hours uninterrupted
4. No Java anywhere in the stack
5. Source on git.lair.cafe under a permissive license, with a README that names the Peppercon e-RIC heritage so the next person searching for this has a chance of finding it