Wrong conventional NAC filter drops all frames silently; the Decoding check still says OK #33

New Issue

2026-10-04T18:12:08-04:00

logan commented

2026-10-04 18:12:08 -04:00

Found 2026-10-04 reviewing the node-26#24 post-merge GO (80a0e88).

What. When a conventional channel has a NAC filter that doesn't match what the agency transmits, the Decoding check on the node dashboard reports OK: "no P25 traffic heard yet... Normal on a quiet channel", indefinitely.

Why. tk_drb_conv sends set_nac to the frame assembler. Upstream p25_framer::nid_codeword (gr310) then returns false for every frame whose NAC differs, so no HDU/LDU/LCW message reaches tk_drb_conv. The channel's nac stays None, and health._conventional_decode_check treats "no NAC heard" as a quiet channel. The only evidence is the NAC check fail: received=..., expected=... line on op25's stderr, which the edge node never reads.

Impact. A mistyped NAC silently records nothing, and the dashboard says that's fine. The workaround today is the guidance on #24 (leave NAC blank until the dashboard shows the heard NAC).

Fix shape. Either (a) in tk_drb_conv, filter by NAC itself (accept all at the framer and drop non-matching calls in _process_conv, while still recording nac_heard), so the dashboard can say "hearing NAC 0x294, filter is 0x293", or (b) when nac_filter is set and nothing has been heard for N busy minutes, downgrade the check to WARN and name the filter as the likely cause.

Linked: node-26#24.

Found 2026-10-04 reviewing the node-26#24 post-merge GO (80a0e88). **What.** When a conventional channel has a NAC filter that doesn't match what the agency transmits, the Decoding check on the node dashboard reports **OK: "no P25 traffic heard yet... Normal on a quiet channel"**, indefinitely. **Why.** tk_drb_conv sends `set_nac` to the frame assembler. Upstream `p25_framer::nid_codeword` (gr310) then returns false for every frame whose NAC differs, so no HDU/LDU/LCW message reaches tk_drb_conv. The channel's `nac` stays None, and `health._conventional_decode_check` treats "no NAC heard" as a quiet channel. The only evidence is the `NAC check fail: received=..., expected=...` line on op25's stderr, which the edge node never reads. **Impact.** A mistyped NAC silently records nothing, and the dashboard says that's fine. The workaround today is the guidance on #24 (leave NAC blank until the dashboard shows the heard NAC). **Fix shape.** Either (a) in tk_drb_conv, filter by NAC itself (accept all at the framer and drop non-matching calls in `_process_conv`, while still recording `nac_heard`), so the dashboard can say "hearing NAC 0x294, filter is 0x293", or (b) when `nac_filter` is set and nothing has been heard for N busy minutes, downgrade the check to WARN and name the filter as the likely cause. Linked: node-26#24.

logan added the area/sdr-radio

labels 2026-10-05 02:05:12 -04:00

logan referenced this issue

2026-10-05 02:08:58 -04:00

P25 conventional is unsupported — "P25" always means trunked, so White Plains PD (Toughny) can never decode #24

logan referenced this issue