problems decoding after NAC Change

[k7dq]

I have been monitoring a system when recently the NAC changed. Now nothing seems to be decoding. It recognized the new NAC. but i never see the WACN nor sysid etc. I wonder what i need to change in the JSON file. i am including the json file and some -v 10 debug output.
Thanks to anyone that can decypher the debug and give me some suggestions.

 

[wgbecks]

I have been monitoring a system when recently the NAC changed. Now nothing seems to be decoding.

There's not much logfile content to alanyze. However, the single LDU2 frame captured contained IMBE codewords that were encrypted with AES256 and would explain why you're not hearing any audio. Keep in mind that Crypt Behavior Option 2 skips, and temporarily blacklists encrypted traffic tgid as soon as it can be identified.

Perhaps all of the groups are now encrypted? Feel free to post additional logfile capture to provide for a more indepth analysis of what's happening on the system.

 

[k7dq]

if this is encrypted, does that mean that the web page will only show the NAC and no longer WACN etc? (and of course no audio).
here is a longer stderr.2 file

 

[wgbecks]

if this is encrypted, does that mean that the web page will only show the NAC and no longer WACN etc? (and of course no audio).
here is a longer stderr.2 file

Use of encryption does not obfuscate control channel messages. According to your logfile (sdterr.2), op25 is decoding the net_sts_bcast messages on the control channel that clearly logged the WACN and SYSID. Are they not appearing on the WEB UI?

From stderr.2 file

09/23/25 12:17:03.151797 [0] tsbk(0x3b) net_sts_bcst: wacn: bee00 syid: 3d6 ch1: 4782(ID-0x4782)

 

[k7dq]

the WACN, System ID, RFSS are not showing. Only the NAC and increasing TSBKs as time goes on.

 

[wgbecks]

the WACN, System ID, RFSS are not showing. Only the NAC and increasing TSBKs as time goes on.

The UI data is incomplete due to a "Fetch Error". Try closing your browser, then reopen and reconnect to the WEB UI to see
if you continue to receive this error message. If so, post your JSON file and op25.sh along with a complete description of your
hardware platform and operating system details.

 

[k7dq]

Sorry about that, i must have done the screen print after i had stopped op25. I get the fetch failed anytime i stop op25.
here are the files you requested.
I am running on a raspberry PI4 with Bookworm. i have both RLD-SDR v3 and V4 and have used both today.

 

[boatbod]

Please turn the logging up to -v 11 and re-run the stderr.2 capture. That will show the python message decoding and maybe explain why the system is silently ignoring you. It shouldn't make a difference, but try setting "nac": "0x0" in the .json file.

 

[k7dq]

i put 0x0 in and the NAC = 0x3D0 started showing up on the web ui.
i see in the stderr.2 file :wacn: bee00 syid: 3d6,however neither show up in the GUI
The following file is -v 11

 

[k7dq]

FYI, I read somewhere that Motorola signed a contract back in 2024 to upgrade this system. I wonder if the change of NAC is part of the upgrade.

 

[mtindor]

@k7dq

I don't see this site for BEE00.3D6 listed in the database. When you get everything else figured out, please consider submitting the site details for the site you are monitoring on this page:

United States Air Force (3D6) Trunking System, Various, Multi-State

United States Air Force (3D6) Trunking System Profile

www.radioreference.com

mike

 

[dlwtrunked]

Use of encryption does not obfuscate control channel messages. According to your logfile (sdterr.2), op25 is decoding the net_sts_bcast messages on the control channel that clearly logged the WACN and SYSID. Are they not appearing on the WEB UI?

From stderr.2 file

09/23/25 12:17:03.151797 [0] tsbk(0x3b) net_sts_bcst: wacn: bee00 syid: 3d6 ch1: 4782(ID-0x4782)

Not qyite accurate P25 control channel encryption?

 

[k7dq]

after a night of having my setup turned off, i restarted everything (including liquidsoap) and the UI is now alive. The system id=0x3D6, WACN=0xBEE00, NAC=0x3D0, RFSS=1. site=80 are now showing in the UI. The system is on a different control channel 406.5625 than yesterdays 406.9625.
Talk groups are showing up but are in the 98xx series not the 10xxx that are shown in the radiorefernce database for Hill field. as i am watching, I see these talkgroups flying by like the encrypted TGIDs i have seen in other system with no audio. However i did hear one very brief audio but didn't get the talkgroup number.
Anyway it looks like they have converted to an encrypted system. And my UI is working (at least as normal for an encrypted system).
Thanks all for your suggestions and help.
Since this is an encrypted Air Force system, i don't suppose there are any "crypt_keys" that i could use but if there are I would appreciate them.

 

[k7dq]

i changed my -v to be 1. I am hearing occasional audio but most or all of the other trunkgroups are digital and are suppressed. ("crypt_behavior": 2)
i am getting a few error messages like the following:

9/29/25 10:30:32.970703 [0] voice update: tg(9860), rid(0), freq(408.962500), slot(-), prio(3)
09/29/25 10:30:34.400691 [0] IMBE dc 74 a8 81 b5 f7 ca e5 08 3d 4e errs 0
09/29/25 10:30:34.400803 [0] IMBE 89 22 f9 0d 26 a7 72 5a ff b4 5f errs 13
09/29/25 10:30:34.400826 [0] IMBE 9e 27 26 d9 d8 2f d4 aa c5 1c c7 errs 15
09/29/25 10:30:34.400841 [0] IMBE c2 ab 53 d9 78 c2 26 aa ce df e6 errs 15
09/29/25 10:30:34.400868 [0] IMBE 59 c1 e8 4a 58 96 97 67 a1 9b 77 errs 14
09/29/25 10:30:34.400883 [0] IMBE 00 09 10 e6 0f f2 c0 a7 2c 9f ae errs 14
09/29/25 10:30:34.400899 [0] IMBE 13 ee 12 cb 0c 4f 6c 37 76 cf bf errs 0
09/29/25 10:30:34.400914 [0] IMBE 19 a0 d7 a7 f2 aa e9 30 07 ef 74 errs 0
09/29/25 10:30:34.400928 [0] IMBE bc 90 02 12 0b 93 2e 7d 57 47 b1 errs 0
09/29/25 10:30:38.078029 [0] voice update: tg(9860), rid(0), freq(408.962500), slot(-), prio(3)

any idea what these IMBE messages are about? Is there a way to interpret them?

 

[boatbod]

i changed my -v to be 1. I am hearing occasional audio but most or all of the other trunkgroups are digital and are suppressed. ("crypt_behavior": 2)
i am getting a few error messages like the following:

9/29/25 10:30:32.970703 [0] voice update: tg(9860), rid(0), freq(408.962500), slot(-), prio(3)
09/29/25 10:30:34.400691 [0] IMBE dc 74 a8 81 b5 f7 ca e5 08 3d 4e errs 0
09/29/25 10:30:34.400803 [0] IMBE 89 22 f9 0d 26 a7 72 5a ff b4 5f errs 13
09/29/25 10:30:34.400826 [0] IMBE 9e 27 26 d9 d8 2f d4 aa c5 1c c7 errs 15
09/29/25 10:30:34.400841 [0] IMBE c2 ab 53 d9 78 c2 26 aa ce df e6 errs 15
09/29/25 10:30:34.400868 [0] IMBE 59 c1 e8 4a 58 96 97 67 a1 9b 77 errs 14
09/29/25 10:30:34.400883 [0] IMBE 00 09 10 e6 0f f2 c0 a7 2c 9f ae errs 14
09/29/25 10:30:34.400899 [0] IMBE 13 ee 12 cb 0c 4f 6c 37 76 cf bf errs 0
09/29/25 10:30:34.400914 [0] IMBE 19 a0 d7 a7 f2 aa e9 30 07 ef 74 errs 0
09/29/25 10:30:34.400928 [0] IMBE bc 90 02 12 0b 93 2e 7d 57 47 b1 errs 0
09/29/25 10:30:38.078029 [0] voice update: tg(9860), rid(0), freq(408.962500), slot(-), prio(3)

any idea what these IMBE messages are about? Is there a way to interpret them?

IMBE message are voice codewords used by the xMBE codec, but the high error counts suggest they were afflicted by a noise burst that was uncorrectable. (7 bit errors is the upper limit with the Forward Error Correction used by IMBE)

 

[k7dq]

when i set "crypt_behavior": 0 and debug to be 1, is it normal to briefly hear what appears to be squelch tails (no real discernable audio) and many IMBE errs 0 and 15 as the UI shows encrypted talk groups?

 

[boatbod]

when i set "crypt_behavior": 0 and debug to be 1, is it normal to briefly hear what appears to be squelch tails (no real discernable audio) and many IMBE errs 0 and 15 as the UI shows encrypted talk groups?

crypt_behavior 0 generally means op25 should stay on the encrypted channel and play the "audio". It'll sound like garbage unless you know and have configured the appropriate encryption keys, but some people want to be able to study the xMBE codewords.

 

[k7dq]

while crypt_behavior is 0, i only hear chirps. When i change it back to 2, i hear chirps after a voice channel in the clear that is followed by an encrypted reply transmission. Anyway the chirps are sporadic as if the software needs time to squech the encrypted but a chirp is heard. This change for Hill AFB to encrypted has been an interesting challenge and a learning experience. i do miss listening to them though.

 

[boatbod]

while crypt_behavior is 0, i only hear chirps. When i change it back to 2, i hear chirps after a voice channel in the clear that is followed by an encrypted reply transmission. Anyway the chirps are sporadic as if the software needs time to squech the encrypted but a chirp is heard. This change for Hill AFB to encrypted has been an interesting challenge and a learning experience. i do miss listening to them though.

If you're only hearing short chirps with crypt_behavior set to 0, that sounds like something isn't set up right and op25 isn't able to hold on to the voice channel. Can you attach a -v 11 stderr.2 showing some voice traffic? Once I see that I'll know whether op25 is losing the connection or if it's receiving TDU15's.

 

[k7dq]

attached is crypt_behavior 0 with -v 11 During this short example the audio was quiet except for a couple of chirps. There were 5 or 6 encrypted trunk groups/transmissions. however i cant tell you which ones had chirped.