[BUG] Inhibit, uninhibit and radio check never reach the air on a conventional V.24 site (Quantar + DVM-V24)

Start in src/host/p25/packet/ControlSignaling.cpp at ControlSignaling::processNetwork() and in src/host/modem/ModemV24.cpp at convertFromAirV24(), comparing the TSDU path with the PDU stream path. Reproduce with the documented dvmcmd radio-check and inhibit commands and inspect the dvmhost log. Done means approved conventional-site commands reach the V.24 modem, the Quantar keys and transmits the TSBK, and the radio can respond.

Component

dvmhost

If "Other", specify component

dvmhost

Version / Commit

R05A04, commit 435ff45 (2026-04-01)

Build type

Built from source (native)

Compiler version

gcc (Debian 14.2.0-19) 14.2.0

Operating system / architecture

Debian 13.7 Trixie

Build flags / CMake options

Built from source with default CMake settings (no CMAKE_BUILD_TYPE set), installed with make old_install, so none. Plain cmake .. then make.

Summary

Hey all, I'm a HAM. We've got a conventional Quantar running on dvmhost through a DVM-V24 (v2) board and voice is working great both ways. The one thing I can't get working is stun. Inhibit, uninhibit and radio check never make it to the air.

1. If I send it from dvmconsole (through the FNE), dvmhost just drops it. Nothing in the log at all.
2. If I send it right on the site box with dvmcmd, dvmhost logs that it went out to RF, but the Quantar never keys up and the Quantar error log in RSS stays empty.

Voice works perfect on the same site, so the V.24 link, clocking, NAC and talkgroups are all good. From what I can find, P25 does support this on conventional, and Motorola conventional systems send it to conventional Quantars as a standalone TSBK from what I understand, So I don't think it's a hardware thing.

Expected behavior

The Quantar should key up and send the Extended Function TSBK (opcode $24) on the channel, and a radio with inhibit/check turned on should act on it and ACK back. A console inhibit that the FNE approves should make it through dvmhost to the modem.

Actual behavior

From the console: the FNE doesn't reject it (CanIssueInhibit passes), but dvmhost doesn't log anything and nothing gets written to the modem.

From dvmcmd: both commands come back {"message":"OK","status":200} and dvmhost logs the TSDU going out to RF, but in RSS the Hardware Status screen just sits on "Station is DeKeyed". I cleared the Quantar's error log, sent the command and hit refresh, and there wasn't anything in it. No response from the radio shows up either.

Steps to reproduce

From the console

1. In dvmconsole go to Commands, then Inhibit Subscriber (or Radio Check Subscriber), and target my test RID.
2. Watch the FNE log. It doesn't reject it.
3. Watch the dvmhost log on the site box. Nothing shows up and the Quantar doesn't key.

From the site box with dvmcmd

1. Turn on REST in the dvmhost config (localhost only).

2. Run these:

   dvmcmd -a 127.0.0.1 -p 9990 -P 'MYPASSWORD_REDACTED' p25-rid-check 1234
   dvmcmd -a 127.0.0.1 -p 9990 -P 'MYPASSWORD_REDACTED' p25-rid-inhibit 1234

3. dvmhost logs the TSDU going to RF. Watch RSS Hardware Status on the Quantar. It stays "Station is DeKeyed" and the Quantar error log stays empty.

Full logs

(RF) P25, TSDU (Trunking System Data Unit), TSBKO, IOSP_EXT_FNCT (Extended Function Command), mfId = $00, op = $00, arg = (V24 NODE ID REDACTED) , tgt = 1234
P25 RF radio check request from (V24 NODE ID REDACTED) to 1234
P25 RF radio inhibit request from (V24 NODE ID REDACTED) to 1234

(don't have access to box right now, can provide more later if required)

Relevant config (redacted)

network:
    restEnable: true
    restAddress: 127.0.0.1
    restPort: 9990
    restPassword: "REDACTED"
protocols:
    p25:
        enable: true
        control:
            enable: false
system:
    duplex: true
    modem:
        protocol:
            type: "uart"
            mode: "dfsi"
            uart:
                port: /dev/serial/by-id/usb-Silicon_Labs_CP2102_...-if00-port0
                speed: 115200
        dfsi:
            rtrt: true
            jitter: 200
            callTimeout: 200
            fullDuplex: false

# Quantar RSS: Conventional, ASTRO CAI, Wireline Interface V.24 ONLY, 4 WIRE FULL DUPLEX,
# Astro To Wireline ENABLED, External Transmit Clock ENABLED, RT/RT DISABLED
# Quantar FW: station control R020.13.022, wireline R020.13.002
# DVM-V24: V2 board, firmware 2.2.0 (CP2102)
# Console peer in peer_list.dat has CanIssueInhibit = 1

Additional context

What I found in the code (commit 435ff45)

1. Network TSDUs get dropped when control is off

In src/host/p25/packet/ControlSignaling.cpp, ControlSignaling::processNetwork() starts like this:

719  bool ControlSignaling::processNetwork(...)
720  {
721      if (!m_p25->m_enableControl)
722          return false;

So every TSDU coming in from the network gets thrown out on a conventional site, even an inhibit the FNE already approved (TagP25Data.cpp checks canIssueInhibit()). It doesn't log anything when it does it either. Turning control on isn't really a fix, because then the host acts like a control channel and that's not what you want on a conventional repeater.

2. On V.24 the TSBK goes out without a start or stop frame

In src/host/modem/ModemV24.cpp, convertFromAirV24(), the case DUID::TSDU part (around line 3181) sends one MotTSBKFrame (0xA1) with the start ICW built into it (DSFI_MOT_ICW_PARM_PAYLOAD, payload MotStreamPayload::TSBK, which is 0x0F). It goes in the queue as STT_DATA_FAST. There's no separate MotStartOfStream in front of it and no stop frame (DFSI_MOT_ICW_PARM_STOP) after it.

Compare that to the other paths:

• Voice gets wrapped by startOfStreamV24() (payload VOICE) and endOfStreamV24() (ICW STOP).
• PDU data (around lines 2947 to 3021) sends its own MotStartOfStream (payload DATA), then the PDU frames, then the stop frame twice.

My guess is a trunked Quantar running as a control channel is already keyed up, so it's fine taking a TSBK frame by itself. A conventional Quantar sitting there dekeyed probably needs the stream opened first before it'll key, and that lines up with the Quantar log being totally clean. The community V.24 captures I found (the ZL4JY SQD dissector and the W9CR wiki) show conventional streams starting with a 0x00 start frame (ICW start 0x0C, stream type 0x0B for voice or 0x0F for page) and ending with ICW terminate 0x25, with 0xA1 frames carrying call alert and emergency. The 0x0F payload dvmhost already uses matches that.

Ideas for a fix

1. Network side. When control is off, let the TSBKs that are legal on conventional through processNetwork() instead of bailing right away. That'd be IOSP_EXT_FNCT (inhibit, uninhibit, check), IOSP_CALL_ALRT, IOSP_STS_UPDT, IOSP_MSG_UPDT and IOSP_RAD_MON, plus forwarding inbound ACK_RSP and emergency. Maybe put it behind a config flag that's off by default so nothing changes for anyone who doesn't turn it on. The FNE already checks CanIssueInhibit, so that can stay the gatekeeper.
2. V.24 side. For sites that aren't a control channel, wrap the TSBK the same way the PDU path does. Send a MotStartOfStream (ICW payload, MotStreamPayload::TSBK, RT/RT from the config), then the MotTSBKFrame, then the stop frame, maybe sent twice. It should probably go in the normal queue instead of FAST. Sending the TSBK 2 or 3 times might help too, since there's no ACK on conventional. Control channel sites can keep working the way they do now.

Stuff I couldn't confirm

• I couldn't find a public capture of real Motorola gear (DIU3000, MCC7500 with a CCGW, ASTRO-TAC) sending inhibit or radio check to a conventional Quantar over V.24. If anyone has one, it'd show the exact frame order and ICW values, and whether the RT/RT byte in the start frame has to match what's set in the Quantar.
• #68 (V.24 support for AMBTs/PDUs) looks related, but I don't think it's the same thing.
• I'm happy to test patches on this setup. I'd try dvmcmd first, then the console through the FNE, and report back whether the Quantar keys, whether the $24 TSBK shows up on an SDR, and whether the radio ACKs.

73