skywave mercury_sock: session fails with a mercuryv2-built Mercury (sim exits ~5s; branch builds work)

[rafael2k]

mercury_sock (the skywave virtual-clock transport) cannot complete a session with a mercuryv2-built Mercury. The MFSK/windowed branches work on the same harness, so this blocks using it for any A/B whose baseline is trunk.

Symptom

Connect fails repeatedly, then the adapter dies with BrokenPipeError on the control socket:

-> A: LISTEN ON
-> B: CONNECT W2XYZ W1ABC
<- B: BUFFER 1205
(connect 1/12 failed; retry)
...
BrokenPipeError: [Errno 32] Broken pipe

At 32 KB it shows up as garbage goodput instead (0.5 B/s clean, partial; fail_connect at mid-SNR).

What is actually failing

Not Mercury. Both station logs show the sim going away first, ~5 s in:

[audio-sock] send failed; reconnecting
[audio-sock] waiting for sim socket /tmp/skywave-mercsock-*/a.sock: Connection refused

and the stations then keep accepting LISTEN ON / CONNECT normally for another 80 seconds. The BrokenPipeError is downstream, after the adapter had torn its station down.

Also checked:

• the trunk binary starts fine standalone under -x sock (modem, mode pool and ARQ all initialise, then it waits for the sim socket as designed);
• audioio/sock_wire.h is byte-identical between mercuryv2 and arq-windowed, so it is not a wire-format mismatch.

Most likely the adapter/sim depends on sock-path behaviour that only exists on the branch (the clipped-head sync fallback and the IRS ladder mirror), or on startup sequencing that trunk does not satisfy.

Impact

Test-only — -x sock is a development transport, no user path uses it. The released modem is fine: 1.9.11 connects on real radios (field reports today), and this is a harness failure, not a modem one.

What it does cost: the trunk column of the Phase-5 A/B is unusable, so windowed-vs-released cannot be measured on this harness. That comparison moves to loopsim (which predates -x sock and can therefore also run 1.9.10) and to the dummy-load bench.

Next

Instrument the sim side to log why it exits at ~5 s, rather than inferring it from the stations' reconnect warnings.