Background

#3115 fixed a 20-second WSJT-X startup CAT stall caused by AetherSDR's bare-mode `\get_lock_mode` response missing the trailing `RPRT 0` status terminator that Hamlib's NET rigctl backend waits for after a long-form getter probe.

The fix was intentionally scoped to `get_lock_mode` because that was the observed stall. This issue tracks the broader audit: AetherSDR has the same omission on most other bare-mode getters. They may cause similar startup or runtime stalls in other Hamlib clients (fldigi, JTDX, Log4OM, hamlib-cli, etc.) that haven't been exercised yet.

Current state — bare-mode getters in `src/core/RigctlProtocol.cpp`

Extended-mode (`+` prefix) responses already include `RPRT` correctly throughout.

Why this matters

Hamlib's NET rigctl reference implementation appends `RPRT N` to every response, bare or extended. WSJT-X happens to be sensitive to its absence on `get_lock_mode` specifically, but other clients may have similar timeouts on other getters.

Suggested approach

Two ways to fix:

1. Mechanical sweep — every bare-mode getter returns `value + rprt(0)`. Mirrors the Hamlib reference exactly. Lowest cognitive load.

2. Wait for evidence — only fix bare-mode commands when a real-world client reports a stall (like [cat] Fix WSJT-X startup CAT lock-mode timeout #3115). Lower change risk, but spreads protocol fixes across many small PRs over time.

Recommend (1) once we have a couple more datapoints, or (2) if changes need to land defensively before public-release deadlines.

Test coverage

`tests/rigctld_test.cpp` section 13 covers the bare protocol path. Each bare-mode getter that gets a `RPRT` terminator added should also get a regression check in section 13 that asserts the exact two-line response.

Trigger criteria

File client-specific subissues under this umbrella when:

• Any Hamlib-using client (fldigi, JTDX, Log4OM, hamlib-cli, gpredict, CQRLOG, etc.) reports stalls or timeouts during startup or normal operation against AetherSDR's rigctld
• Attach: client-side log, AetherSDR `logpull` capture, and the timestamps showing the silence window

Related

• [cat] Fix WSJT-X startup CAT lock-mode timeout #3115 — first instance fixed (`get_lock_mode`)
• Originally diagnosed by @jensenpat via WSJT-X startup probe trace

73, Jeremy KK7GWY & Claude (AI dev partner)

🤖 Generated with Claude Code