V.34 handshake reliability: an opt-in carrier-loss watchdog workaround

[szeremeta1]

The README says:

Connections are unreliable, and it is currently difficult to connect at speeds higher than 14.4kbps or so.

To successfully connect, you will likely need to manually select a modulation and data rate. In our testing, V.32bis (14.4kbps) and below appears to be the most reliable, though V.34 (33.6kbps) connections are sometimes successful.

On one installation using slmodemd and the closed dsplibs.o with packet
audio, disabling a handshake carrier-loss criterion improved completed calls
in the interleaved comparison below. This is an installation-specific
workaround. The original claim that it explains the speed ceiling, or that
this intervention raised negotiated rates, was not supported by that comparison.

The mechanism

v34handshak (in dsplibs.o, at .text+0x62a92 in the build I have) ends the
call when a signal metric stays below a threshold for a run of consecutive
samples:

if ((short)metric < obj->lowsig_thresh)   obj->lowsig_count++;
else                                      obj->lowsig_count = 0;
if (obj->lowsig_count > 0x257f)           *status = 9;   /* -> hang up */

v34handshak runs once per sample, so 0x257f = 9599 samples is exactly one
second at the 9600 Hz DSP rate. The counter is consecutive: one good sample
resets it. status = 9 reaches vpcm_run, which logs vpcm: Link Error and
hangs up.

The threshold is the vendor default

The threshold is not a constant. VPcmV34SetMinimumSigLevel picks it from an
eight-entry table at .data+0xc0:

index      0    1    2    3    4    5    6    7
level    -48  -47  -46  -45  -44  -43  -42  -41   dBm
value     71   80   90  101  113  127  142  160

The index is a minLevel field plus 0x30, clamped to 3 when it falls
outside 0–7. dp_runtime_create zeroes that field and nothing in the object
or the host driver ever writes it, so the index is 0x30 on every installation,
hardware included, and the threshold is always 101 (−45 dBm on the table's own
scale). It's the datapump's default, not something a packet path falls into.

Correction, 2026-09-08. As originally filed, this section said the lookup
fell through to the clamp because a packet path has no dBm-calibrated level to
index it with. That was wrong (G.711 defines the digital milliwatt, and the
index is a field nobody writes anyway); Manawyrm pointed it out below. The
threshold is the vendor default. The cause of the low metric, and whether
additional RX noise/self-echo addresses it, remain separate experimental
questions; disabling the criterion does not answer them.

The historical capture analysis reported activity resuming at 4.03–4.07 s,
4.30–4.54 s, or after an internal restart at 8.7–9.2 s across 76 windows. Those
observations motivated the experiment. They do not by themselves prove that
the observed quiet intervals are protocol-required, identify the cause of
the low metric, or establish the correct driver I/O delay.

Evidence

Interleaved A/B, identical binary in both arms, one environment variable
between them, three blocks with two warm-ups discarded each, n=30 per arm:

	completions	status 9	acquisition timeouts
watchdog armed (as shipped)	19/30	6	5
watchdog disabled	27/30	0	3

Fisher exact, two-sided: p = 0.030. Every call that completed, in both arms,
reported 33,600 bit/s caller receive rate in both arms. This comparison
supports improved completion on that setup, not increased speed, both
directional rates, or 99% call reliability. Both arms also shared earlier host
fixes and inherited service settings. The deposited artifacts do not contain
every prerequisite needed to reconstruct that complete historical stack.

Fix

PR #14 weakens
VPcmV34Progress with objcopy and links a wrapper in
front of it, so no vendor instruction changes and the vendor object is never
redistributed — the build runs objcopy against your own copy. It is off unless
an environment variable is set, so default behaviour does not change.

Full write-up, method, and the data: https://dialup.litenet.tel/research/v34-modem/

Review update, 2026-09-10

The title and unsupported mechanism/rate claims above have been corrected.
PR #14 is now a focused, opt-in watchdog workaround with exact vendor-object
pinning and an isolated, verified build; its default path passes directly to
the original function. The historical 19/30 versus 27/30 result has not been
relabelled as a new hardware trial.

Separate, disabled-by-default experiments now cover
RX conditioning,
near-echo output bypass,
socket stream handling,
and digital V.90 negotiation.
Their component/build checks do not establish higher rates or a
100+ call reliability criterion. Physical testing and end-to-end payload
validation are continuing. The digital negotiation work does not yet implement
a complete native 8 kHz digital transmitter/receiver journey or prove a 56k call.

[Manawyrm]

Thanks for tackling this long standing issue!

I'm not very happy about the reasoning in the blog post, though. A lot of the comments/conclusions don't quite make sense, might be hallucinated entirely.
There's still an underlying issue which we are missing here.

from that blog post:

Samples arriving over packets carry no dBm reference, so it never can be.

The real-world alternative are samples that arrive from a physical AC97 sound card in an old laptop with an internal modem card.
Those samples have just the same amount of external reference values: None.

Matter of fact: When we use alaw codecs in telecommunications, there's a very well defined reference level, often called a Milliwatt:
https://en.wikipedia.org/wiki/Digital_milliwatt
We know (or at least should know) very exactly what the signal level in alaw/ulaw G.711 audio is.

It's possible that the slmodem blob expects the audio to be scaled in a different way (remember, we convert from alaw/ulaw 8-bit to a much wider 16-bit signed linear range, so we have much more dynamic range).

It's possible that real AC97 samples would arrive with lower volume and maybe at an offset (so basically scaled down and transposed), buuuut:

The datapump asks the host for its I/O delay through an ioctl and was being told zero. That is correct for a codec on the same board and false across an RTP path, a PBX and an analog terminal adapter. Supplying a real value eliminated a handshake wedge that had affected 58% of calls

This is an offset calibration for the analog-to-digital & digital-to-analog converter pair inside the AC97 soundcard/modem combo.
After the sound card, analog electronics puts both the ADC and the DAC onto the same 2 wire pair (the analog phone line) again.
There might be a slight sample offset (few samples) between the time between the DAC outputting samples and the ADC "hearing" those same samples.

Delays on the physical line (like your RTP path, PBX, ATA and friends) were always normal! Back in the day you could have modem calls across the country, heck, even across the globe over satellite links! Modems had to automatically deal with that.

Having said that:
slmodem thinks it's an analog modem on a analog (2-wire) phone line, so both TX and RX are the same pair.
slmodem could be expecting to be able to hear itself, measure it's own output signal & power levels and correct them accordingly (or do something else with them).

On our digital setup here, slmodem won't be able to hear itself at all, though, because there is no physical line for it to ADC/DAC to.
I'll need to play around with this some more, but I think I see 2 possibilities here:
a) give it a virtual analog phone line (basically mix the incoming samples and slmodem's own outgoing samples together and feed it back into itself so it can hear itself)
b) tell it that it's actually connected to a digital/ISDN phone line. This was already a thing back in the day and modems could deal with digital phone lines. I saw some references to digital phone lines in the modem code, but couldn't figure out where they come into play.
With some more reverse engineering, this might significantly improve connection quality and fix this the proper way.

[szeremeta1]

Manawyrm -- you are absolutely right. While this may be of little or no value, and was achieved deplorably through rigorous, expensive, multi-day generative AI sessions running at all hours, all I have is what I can prove: the written words may be largely unintelligible, but the fix works, at least in some capacity. 32 simultaneous virtual modem engines on our D-Modem fork, all capable of negotiatiating at a maximum of 33.6k with what I would describe as reasonable (and what many would say is period accurate) reliability.

I feel that what remains is far beyond my scope of knowledge and all I would achieve is further embarassment. Hopefully someone comes along some day to finish what this clanker started 😄

[Manawyrm]

While this may be of little or no value

Just the opposite actually! I think the token/money usage was actually useful!
I'll look into this closer, but I think the actual fix might be even simpler and could fix many weird behaviours at once.

[szeremeta1]

You were right on both counts, and thank you for reading it closely enough to catch them. I went back to the disassembly before touching anything, so here's what it actually says.

The dBm claim. Yes, G.711 has the digital milliwatt, so my samples are if anything better referenced than a sound card's. What I should have looked at is what the table is indexed by. It's a field the blob's own debug string calls minLevel, in the runtime-config struct that dp_runtime_create mallocs (0x88 bytes; obj+0xac3c points at it). That function writes a literal 0 to cfg+0x60, nothing else in the object ever writes it, and modem_get_param on the host side has no parameter that reaches it. So the index is 0 + 0x30, out of range, clamp to 3, threshold 101, on every install of this blob including the vendor's own cards. It's the default, not something my path "falls into". The threshold is therefore the vendor default. Disabling its one-second criterion improved completion in the historical comparison, but the cause of the low metric and the status of the observed pauses remain separate questions.

The I/O delay. Also your reading. In the vendor's ALSA driver MDMCTL_IODELAY is the playback prefill plus INTERNAL_DELAY (40), the kernel driver adds ST7554_HW_IODELAY (48), and vpcm_create subtracts 0x30 from whatever it's told, so the socket driver's hard-coded 0 is negative by the time it's used. Anything in roughly 128–768 un-wedges the V.8/INFO0 receiver in deterministic replay. The actually-correct value for this stack (the socket driver's own buffering plus that constant) I never measured, and the paper now says so. It's read by v8_process, v32_create and vpcm_create, and it barely moves the Phase 1 bulk-delay estimate, which I'd implied elsewhere that it did.

Self-echo. That fits my data better than my own story did. Cross-correlating the DSP's transmit against its receive out to 900 ms finds nothing (peak |r| 0.013–0.075), which motivates testing an explicit TX reference. That correlation alone does not establish the physical echo/noise floor or identify the metric's position in the cancellation path. At the September 8 posting I had not tried mixing TX back in or pinned down whether the metric at obj+0x398 is pre- or post-cancellation, so I'm calling it a hypothesis rather than a finding. If you get to it first, the wrapper in #14 can dump that metric every N fragments (SLM_V34_METRIC=N), which should show directly whether self-echo would keep it above 101.

Digital mode — corrected 2026-09-10. The earlier version of this paragraph incorrectly said that the second argument to VPCMXF_Create selects V90ModemSide, and that the first only changes a log string. The verified C order is VPCMXF_Create(int digital, void *v34, void *params, unsigned fragment_ms, unsigned computational_mode). The first argument is inverted and passed as the C++ side enum: first argument 1 produces digital-side enum 0 and an actual modulator. The second argument is the V.34 object pointer; replacing it with an enum would corrupt that pointer. Disassembly and isolated construction/teardown tests agree on both audited vendor objects.

The digital INFO0 path also does not require forcing mode 5. The V.90 mode-1 branch retains PCM initialization and its reset path; with the reviewed role correction it reaches role 0x66. The isolated digital-negotiation experiment documents the exact gates, fallback/lifetime checks and ABI boundary. It does not implement a complete waveform handshake or prove a physical V.90 connection. Native 8 kHz transport and the remaining receive/phase transitions are separate unfinished work.

The September 8 posting described the paper as v1.1 with a revision history at the end that says exactly what changed and credits you. The A/B and the acceptance numbers stand; the explanations didn't, and I'd rather say that here than quietly edit. I've fixed the issue body above to match, and #14's README paragraph gets the same correction.

Review note, 2026-09-10. The digital ABI paragraph and overstrong mechanism sentences were corrected in place with the earlier mistake identified explicitly. The historical measurements remain historical; they are not new tests, both-direction rate proof or 99% reliability evidence. The current review also found omitted inherited settings and predecessor host fixes in the historical reproduction recipe. Correcting that recipe is not a new DOI deposit or rendered paper edition.

[Manawyrm]

Fantastic, this seems very reasonable!
I think I'll try a prototype with self-echo and maybe even a tiny bit of fake white noise being introduced into the line (?)...

Your SIP usecase is quite a bit different from mine. I'll play around and see where I land.

[Manawyrm]

I played with sl-modem locally a bunch and found something interesting.
You only fixed a symptom indeed. The modem is unhappy about the lack of an analog phone line (and it's artifacts) and that's what's happening here.

A real phone line has a tiny bit of echo (due to the internal hybrid not being 100% perfect) and also some noise.
If you add -65dBFS of white noise to the slin16 RX data (and only there, not the TX and definitely not the G.711) the modem is suddenly much happier and doesn't time out anymore.

If you then add a tiny bit of echo (-40dB attenuated and delayed by 20ms aka one buffer and set the ->delay accordingly to 192 samples) the modem is really happy and will happily negotiate at full rate every time 😸

Now, having said that: It would be very cool to disable the internal near-end echo canceller. It can only add noise in our usecase.
That would be a worthy binary patch and a good use of AI, maybe?

[szeremeta1]

Two things from this week, one of which is an answer to your last message and one of which is a different bug entirely.

Your noise + echo proposal, and what we can and cannot say about it

We ran it on real hardware before you posted the full recipe, so it is not an exact reproduction of what you described, and the result is null rather than negative.

48 calls, six arms, two modems (a USR and a StarTech CX93001), interleaved with the arm order reversed on the second cycle and no warm-ups or top-ups: control, −65 dBFS RMS white noise, −40 dB self-echo, both, and two more arms repeating control and both at a different host I/O delay. 43 of 48 held verified PPP with checksummed payload both ways; five failed before CONNECT; zero unexpected ends among the 43. No arm separated from its matched control on either held calls or final directional rates.

Three reasons not to read that as "it does not work":

• The carrier-loss watchdog was disabled in every arm, so the experiment could not test the thing you are actually claiming, which is that noise stops the modem timing out. The screen designed to test noise with the stock watchdog was started and interrupted at 14 of its 32 attempts; its results are indeterminate and we are not quoting them.
• Our echo was not your echo. We delayed the reference by a fixed number of processed samples at the DSP rate, which is an index separation and not a calibrated physical 20 ms round trip — host delay changes can consume or generate samples outside that index. Your ->delay = 192 against a real buffer boundary is a different quantity.
• n = 4 per cell. This line's connect rate swings 33%–88% within an hour at fixed settings; measured over 93 consecutive calls bucketed by 20 minutes it went 44, 50, 75, 50, 50, 71, 57, 88, 33, 67 with no trend. Nine results on this project have failed to survive being looked at twice, always the same shape: large and obvious at n≈6–16, gone when the sample grew. Four per cell is not enough to see anything, and it is the number we had.

So: still worth doing properly, and the thing to test is noise with the watchdog left alone, which is exactly what you said and exactly what we have not managed to run yet.

The other bug, which is upstream and costs real service silently

slmodemd/modem.c:1578, unchanged from upstream:

m->dp_requested = 0;
m->automode_requested = 0; /* MODEM_AUTOMODE(m) */

The answering side therefore comes up locked to whatever datapump AT+MS names and will not try another one. It is visible in the blob's own trace as v8: create: caller 0, automode 0, dp id 34 — on every call.

We had this written down as an "incidental finding worth keeping" for a week and did not join it up to anything. What it means in production is that a pool pinned to V.34 does not serve a V.32bis modem at all. Not slowly, not at 14,400: the caller gets ATA, a few seconds of relayed audio, and then the call ends. At default verbosity the answering side logs nothing whatsoever — no change dp, no error, no NO CARRIER reason. The line is healthy, the port is listening, the process is fine.

Measured on our production pool, same caller (AT+MS=132,1,1200,14400, the 8000 build, so V.32bis only), same dialplan, inside ten minutes, slot chosen at random per call:

slot	answers	outcome
15, 2, 16, 11, 19	V.34	0 of 5 — answered, 8 s of audio, no carrier
30, 25, 27	V.32bis	3 of 3 — CONNECT 14400, PPP, page fetched

One subscriber on a real copper line spent nine days unable to connect at all — eleven calls in twenty minutes across three numbers on the last evening, every one answered, not one PPP session — after we moved that pool from V.32bis to V.34. The same modem had connected 8 of 8 three weeks earlier. Nothing in any log said why, because there is nothing to log: the code never gets far enough to fail.

If you are running this in front of anything real, that is the failure mode to know about. Our mitigation is at the pool level rather than in the modem: some of the lines answer V.32bis, the dialplan sends a caller who has repeatedly failed to one of those, and the two configurations are otherwise identical.

The obvious fix is the commented-out line. One data point against it, which is the only one anybody here has: with the automode bit honoured and AT+MS=92,1, the blob constructed V90Modem/V92Modem for the first time but do_modem_change_dp then recreated the V.34 datapump in a loop until info0 CRC not received properly and NO CARRIER, where the pinned-V.34 baseline had connected. That is one configuration on one build. Nobody has tried it at AT+MS=34,1 on the 9600 tree, which is the case that matters for a mixed pool, and it is cheap to try if someone has a V.22bis-only modem to point at it.

A much smaller change than any of that would also help: say something at hangup when no datapump was ever created. Right now the most common way for this stack to fail a caller is completely silent, and one line naming the offered dp and how far it got would have saved us nine days.

[szeremeta1]

Following up on the last paragraph of my previous comment, because suggesting it and not writing it would have been cheap: diag/no-carrier-reason.

One MODEM_INFO in modem_hup's STATE_DP_ESTAB branch, which is by definition "the call ended while still handshaking". It names what was offered, whether automode was asked for, which datapump was actually running, and how many samples went by.

Measured hermetically — two processes, no telephone line, no SIP:

answerer AT+MS=34,1,4800,33600, caller AT+MS=132,1,1200,14400
  litenet101: no carrier: still handshaking after 92160 samples
              (offered dp 34, automode requested, running dp 8)

control — answerer AT+MS=132,1,1200,14400, same caller
  CONNECT 14400, pppd up, and no such line

The control is the half that matters: a handshake that completes prints nothing new, so this costs one line per failed call and nothing per good one.

Two things to know before taking it. It is built -m32 against the unmodified vendor object in this tree, but the measurement was made with the identical hunk applied to a sibling tree of the same modem.c that carries a socket device driver, because D-Modem's own slmodemd reaches its audio through SIP and a hermetic pair needs a socket. And MODEM_INFO writes to stdout, so anyone running this under something that does not capture stdout will not see it; if you would rather it went through eprintf like MODEM_ERR, that is a one-word change and probably the better call for upstream.

[aarmono]

The I/O delay. Also your reading. In the vendor's ALSA driver MDMCTL_IODELAY is the playback prefill plus INTERNAL_DELAY (40), the kernel driver adds ST7554_HW_IODELAY (48), and vpcm_create subtracts 0x30 from whatever it's told, so the socket driver's hard-coded 0 is negative by the time it's used. Anything in roughly 128–768 un-wedges the V.8/INFO0 receiver in deterministic replay. The actually-correct value for this stack (the socket driver's own buffering plus that constant) I never measured, and the paper now says so. It's read by v8_process, v32_create and vpcm_create, and it barely moves the Phase 1 bulk-delay estimate, which I'd implied elsewhere that it did.

FWIW I was experimenting with this the other day just trying to get two slmodem instances talking to each other locally over a FIFO pair, and the clanker I was using also picked up on the delay = 0 issue. Once I simply uncommented the delay code that was there I was able to reliably connect the two instances at 33.6 where previously it would only do V.32bis. The negotiation still sounds slow to my ear so there's still probably something else going on, but I suspect the delay is at least part of the issue.