Don't tune to encrypted channels (P25) or muted talkgroups

[f3ndot]

Because my city's police service is fully encrypted, but EMS and fire are not, and tuning to the encrypted channels is unideal. For reasons stated in #1045.

Next steps:

• Make it a configurable option?
• Tests (maybe. very little coverage already)
• Make muting P25 agnostic (unsure if works on other protocols, only tested mine)

[f3ndot]

Config UI looks like this:

[whelgeson]

This bin directory probably should be added to the main .gitignore file

[f3ndot]

Didn't intend to commit bin/ 😅. I agree with you it should go into the main .gitignore file but I don't want to presume what the project structure and hygiene should be. I'll leave any such changes out in this PR.

[whelgeson]

I'm in the same situation you are re: encrypted channels, this looks great and hopefully it'll get merged in soon.

[f3ndot]

Thanks for the review @whelgeson, Java isn't my main language so scrutiny is appreciated.

[zpdx]

Thank you for your work on this. Can it be adapted for P25 P2 systems? I compiled with the changed files, but it is still tuning to various encrypted/muted talkgroups.

The command window displays many messages like these, but Now Playing shows constant tuner activity to muted and encrypted talkgroups.
21:04:45.824 DEBUG i.g.d.m.d.p.P25TrafficChannelManager - Channel is encrypted. Ignoring. - APCO-25 DECODE EVENT: Encrypted Group Call - Ignored DETAILS:IGNORING ENCRYPTED CHANNELS IDS:P25-1,859737500,WCN (P25) Network,Washington,Control,WCN,2468,3000,305694,SCRAMBLE PARAMETERS WACN:781824 SYSTEM:2474 NAC:2468 DURATION:0 CHANNEL:2-1156 TS1 [201MB/372MB 54%]

[cptmedic]

Can someone tell me what JDK you guys are using to compile. I downloaded the latest JDK for MacOS and it fails to compile.

[RonRN18]

I think I used OpenJDK 17

On Sat, Feb 19, 2022 at 06:12 cptmedic ***@***.***> wrote: Can someone tell me what JDK you guys are using to compile. I downloaded the latest JDK for MacOS and it fails to compile. — Reply to this email directly, view it on GitHub <#1091 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABWEF3DVCBYKCB33IN25OK3U36QM5ANCNFSM5FZUM7KQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Sent from Ron Webb's iPad using Gmail Mobile

[zpdx]

Can someone tell me what JDK you guys are using to compile. I downloaded the latest JDK for MacOS and it fails to compile.

Zulu OpenJDK 17 on Win10

[smyers119]

I am currently testing this push with good results so far.

[ImagoTrigger]

trying this also with v5 beta1 (with no issues noted)

[smyers119]

I've been testing this on the bleeding edge builds for about a month now on a p25 phase 2 system. I have found it correctly logs the encrypted channels as encrypted and adds ignored but it doesn't actually get ignored. Channel is still tuned to.

[ImagoTrigger]

have to tune to it to find out its really encrypted

[smyers119]

That's not how it works at all.

[f3ndot]

It's been a while, so apologies, and I haven't been able to polish this work.

Based on my real-world experimentation back in the fall, sometimes a control channel is not given info about an encrypted traffic channel/the channel does not emit the header packet containing the encryption flag (or it's missed) and the software will tune to said channel. This is marginally better than always tuning.

The best possible way to avoid tuning to encrypted channels is to define them as such in talkgroups so the software will avoid them up front once their ID is detected from the control channel.

Think of it this way:

1. Rely primarily on talkgroup definitions, stating which channels are encrypted or not
2. Should a new traffic channel show up not already defined, the software will attempt to avoid it if it sees the header packet stating its an encrypted traffic channel
3. Should the software miss said header and tuned to the encrypted channel anyway, it'll notice encrypted data and at least state that in the UI

I may be wrong, but I'm pretty sure that's how I witnessed it when I last experimented with this project.

[smyers119]

I've enabled logging and will keep an eye on this. but to your points:

1. You can not define a alias as encrypted, unless I am missing something.
2. I have enabled event logging and will check, but this did not seem to be working for my phase 2 system.
3. the UI does seem to label encrypted traffic successfully.

[zpdx]

I experience the same behavior as @smyers119 on my P25P2 system. @f3ndot, did you have success with this on any P25P2 systems, or only P25P1?

When "Ignore encrypted channels" is on, lines like the following appear in the command line window. But it looks like every encrypted transmission is still being tuned to and held until it ends.

15:01:51.242 DEBUG i.g.d.m.d.p.P25TrafficChannelManager - Channel is encrypted. Ignoring. - APCO-25 DECODE EVENT: Encrypted Group Call - Ignored DETAILS:IGNORING ENCRYPTED CHANNELS IDS:P25-1,859737500,WCN (P25) Network,A,Control,WCN,2468,34000,3452516,SCRAMBLE PARAMETERS WACN:781824 SYSTEM:2474 NAC:2468 DURATION:0 CHANNEL:2-836 TS0 [188MB/316MB 59%]
15:02:02.542 DEBUG i.g.d.m.d.p.P25TrafficChannelManager - Channel is encrypted. Ignoring. - APCO-25 DECODE EVENT: Encrypted Group Call - Ignored DETAILS:IGNORING ENCRYPTED CHANNELS IDS:P25-1,859737500,WCN (P25) Network,A,Control,WCN,2468,34000,3407532,SCRAMBLE PARAMETERS WACN:781824 SYSTEM:2474 NAC:2468 DURATION:0 CHANNEL:2-676 TS1 [272MB/380MB 71%]
15:02:07.342 DEBUG i.g.d.m.d.p.P25TrafficChannelManager - Channel is encrypted. Ignoring. - APCO-25 DECODE EVENT: Encrypted Group Call - Ignored DETAILS:IGNORING ENCRYPTED CHANNELS IDS:P25-1,859737500,WCN (P25) Network,A,Control,WCN,2468,34000,3452516,SCRAMBLE PARAMETERS WACN:781824 SYSTEM:2474 NAC:2468 DURATION:0 CHANNEL:2-996 TS1 [183MB/380MB 48%]

I am not able to see any behavior change with "Ignore muted talkgroups". I defined a range of all "other" talkgroups as "Lockout", and muted them. Sdrtrunk is still tuning to them, encrypted or not, for the whole transmission, and there are no "ignoring" messages like above in the command line.

[bradjtrammell]

Is it safe to assume that if an unencrypted channel is added to a streaming group, and that option (ignore muted talk groups) is selected, that it will still be process and streamed, and it just won't show up on the listing of active calls? Or will this ignore anything you don't actively having going for audio monitoring via the soundcard/speakers, and just drop it entirely?

[louisik1]

Is it safe to assume...that option (ignore muted talk groups) is selected, that it .....

Where do you see an option for "ignore muted talk groups" in sdrtrunk?

Edit: Oh, it's in a separate branch, I see.

[PhillyPhoto]

2 years since this has been done, what's the likelihood of this being added to the main branch?

Also, what java should I be using specifically? I tried pointing JAVA_HOME to the SDRTrunk directory (in Windows) and keep getting "ERROR: JAVA_HOME is set to an invalid directory".

[ghost]

Maybe a low priority feature, and probably for good reason. It seems like mostly just a clerical/log feature. I mean how can you truly block something at the receiver end? I understand it's "unideal" but what harm does tuning to a encrypted p25 talkgroup cause? It's already blocked/ignored by design. I don't see how it effects sdrtrunk,. I maybe wrong but I just don't understand why this needs to be an option at all. For example, I block-out tons of city buses , encrypted, and other non-encrypted transmissions from my live police/fire feeds. I can still see them key up on sdrtrunk, and I still let it all get uploaded to CALLS , but how does allowing these unwanted talkgroups to just playout harm your feed? You can have tons of talkgroups all talking at the same time on a p25 system.

[zpdx]

You can have tons of talkgroups all talking at the same time on a p25 system.

This is actually the problem for me. The P25 P2 system I monitor is spread over 10Mhz, is very busy, and is saturated with encrypted calls. Theoretically, this system would require 5 tuners running at 2.4Msps to guarantee 100% coverage. Even then, the way Sdrtrunk dynamically reassigns each tuner's center freqs could still leave gaps.

As it is, I only have 3 tuners at 2.4Msps, which capture most non-encrypted calls. They miss maybe 10-20% because the tuners become needlessly stuck on encrypted talkgroups while non-encrypted calls transmit on freqs too far from the set center freqs.

Even after compiling with this branch I was unable to get sdrtrunk to completely ignore the encrypted calls on my P25 P2 system, so it did not solve my problem.

[Cortexian]

I'm confirming a similar issue to @zpdx . The system I monitor is very busy with a mix of about 80% encrypted and 20% unencrypted traffic. I notice that SDRtrunk tunes to and maintains a channel for encrypted traffic, almost pointlessly. This is seeming to result in parts of conversations being missed because all the channels are currently in use. Spectrum spread is only about 3.8 MHz, so I have two RTL-SDR V3 dongles in use for this, which should in theory be enough bandwidth but I'm still missing out on certain transmissions.

[cptmedic]

Similar to @Cortexian my local area has many encrypted groups that needlessly take up channel space causing missed calls on unencrypted groups. Shortly after my question in February of last year, I was able to compile SDRtrunk with this modification, and it rarely tuned to encrypted channels. There were a few exceptions where it appeared than when the talkgroup was not recognized as encrypted until it tuned. But it was a highly effective PR. It would still be ideal to see this implemented in some form, but I do not have the time in my schedule to make changes and to get it current with the current build of SDRtrunk.

[zpdx]

@cptmedic Out of curiosity, is your system P25P1 or P25P2? I didn't see any decrease in encrypted tuning on my P2 system.

[PhillyPhoto]

Maybe a low priority feature, and probably for good reason. It seems like mostly just a clerical/log feature. I mean how can you truly block something at the receiver end? I understand it's "unideal" but what harm does tuning to a encrypted p25 talkgroup cause? It's already blocked/ignored by design. I don't see how it effects sdrtrunk,. I maybe wrong but I just don't understand why this needs to be an option at all. For example, I block-out tons of city buses , encrypted, and other non-encrypted transmissions from my live police/fire feeds. I can still see them key up on sdrtrunk, and I still let it all get uploaded to CALLS , but how does allowing these unwanted talkgroups to just playout harm your feed? You can have tons of talkgroups all talking at the same time on a p25 system.

Because it still tunes a receiver to the talkgroup despite it being ignored. It's not just a "clerical" issue. I monitor sites that have both 700 & 800 MHz channels and would need a dozen or more SDR dongles to cover a single site. If I only care about a handful of groups, why should it expend resources tuning to dozens of ignored ones? The program is telling the receivers what to tune to, that's how it "blocks" it. I'm not sure where the confusion lies.

[TRENT310]

Regarding an earlier comment whether the traffic needs to be tuned to first, in order to determine that it is encrypted. That is not entirely true.

In P25 the GRP_V_CH_GRANT opcodes include the Service Options octet with the Protected flag in Bit 6 so that the receivers can be prepared to look for the HDU frames upon tuning to the Traffic channel which then contain the ALGID, KID, MI initialization vector - thus preparing the radio to decrypt the traffic as soon as it begins on LDU1 and preventing truncating the beginning of the speech. This Protected flag should be used by SDRTrunk, an application which does not currently implement cryptography, to intentionally NOT allocate a resource to follow that call.

Now, this does not help for a late-entry scenario or a poor control channel decode scenario where the initial channel grant is missed or unrecoverable, since the GRP_V_CH_GRANT_UPDT instead allocates its bits to describe more events (up to 2 group calls) per outbound packet OSP and does not include the Service Options or Protected flag information so the receiver tuning to the traffic in late-entry mode has to remain muted until the LDU2 where it receives the required data that it missed on the initial HDU. So then a secondary handling for this in SDRTrunk should be that if a tuner resource gets allocated to following the voice call upon late-entry condition and on the Traffic channel the LDU2 Low Speed Data block reveals an ALGID that is not 0x80 then immediately release that tuner resource for the remainder of that call and follow something else that may be clear and dispose of any stored or buffered audio that may have been attempted to be demodulated/vocoded (since it likely only contains a bunch of unintelligible chirps and squawks). Upon a future grant, re-evaluate all of these conditions and do not cache or temporarily mark the encrypted state (eg. if the talkgroup was noted to be encrypted last time, still evaluate it next time instead of "remembering" that it had encrypted traffic.).

Now there have been certain P25 system FNE observed to not set the Service Options octet correctly either consistently or occasionally, that would amount to non-compliant infrastructure or improper configuration of said infrastructure and we can't help that there on a passive receiver. The users would likely be suffering unpleasant behaviour on their actual system radios as well. As a niche application (raw data decoding) there should still remain a GUI option for this encryption skipping logic to be disabled so that protected/encrypted calls are still followed and logged but typically this is for use of the software for system troubleshooting or debugging in a raw data logging mode, and not of use to the casual listener who is more interested in the audio content than the inner workings.

The rationale for this case-by-case evaluation rather than merely tagging in a playlist or database that talkgroup has encrypted traffic is because some systems utilize mixed encryption whether by design (operator or console selectable, emergency in clear functions) or accidentally (due to user error, equipment mis-configuration, equipment being zeroized and falling back clear, Patch Key ID hang time and its various inconsistent implementation across manufacturers, or a variety of other reasons) and the interest is that on what is a normally encrypted talkgroup then any clear traffic that occurs may be of interest to the monitoring community. This is why those talkgroups are not simply locked out permanently and the expectation is the software should utilize the channel grant information to determine whether tuner resources should be allocated or not. On very busy systems like those with TDMA and/or 20+ channels per site this becomes a processing hardware resource concern even if the input SDR hardware is capable of spanning the entire site frequencies comfortably.

[sebbenandsebben]

Have to say the same here, monitoring a P25P1 system with two dongles and still missing calls due to the tuners following encrypted comms around. Even if it managed to detect and cut 50% of the calls that would be a huge improvement for my case.

[marshyonline]

I would love to see this worked in as a main feature - there is no point tuning something I can't hear anyway
It would be great if it still showed in the call log just for reference

[TravisSamren]

I would love to see this worked in as a main feature - there is no point tuning something I can't hear anyway It would be great if it still showed in the call log just for reference

Honestly there's really no point. The tuner must connect with it everytime to see if it is E or not. This has been hashed out. It's a talkgroup. Just ignore it and look away when it keys up, or buy another dongle if it somehow effects your system.

[zpdx]

Honestly there's really no point. The tuner must connect with it everytime to see if it is E or not. This has been hashed out. It's a talkgroup. Just ignore it and look away when it keys up, or buy another dongle if it somehow effects your system.

@TRENT310 's detailed explanation above contradicts the need for sdrtrunk to tune to every E transmission. Currently, sdrtrunk cannot "ignore" or lock out a talkgroup. It tunes to everything and remains tuned to the E talkgroup until the transmission ends. All I can do is mute them, which I've already done to the entire range of talkgroups except the handful of unencrypted TGs I'm interested in. As @TRENT310 explains, in a system like mine with 8 freqs spread across 10Mhz, hundreds of TGs, and a handful of busy LE agencies, all of which are encrypted, it would take an unreasonable number of dongles to guarantee picking up the TGs of interest.

[ustayready]

Mute on aliases doesn't mute anything on LSM modulation for P25 Phase 1. I have tried every combination of playlists, talkgroups, and aliases. If the call is detected on the Channel, it doesnt matter the TG's configured, audio is heard across a few hundred TG's despite only having 3 configured. I have tried on MacOS and Linux, both have the same problem. I am looking to compile this PR in hopes of solving the problem.SDRT works way better than Unitrunker and OP25 but the lack of this feature makes it unusable. Hoping to see this feature merged into the latest.

[ustayready]

Compiled fine and ran with gradlew build and gradlew run after adding the following to the build.gradle file:

application {
    mainClassName = 'com.example.Main'  // Set your main class here
    applicationDefaultJvmArgs = [
        '--add-exports', 'javafx.base/com.sun.javafx.event=ALL-UNNAMED'
    ]
}

After importing all talkgroups into my channel and muting everything that I wanted quiet, the only audio I received was what I wanted to hear. Excellent job with this feature! The log output shows the skipping of muted talkgroups. Super thankful for this PR.