search

robotastic / trunk-recorder

Records calls from a Trunked Radio System (P25 & SmartNet)
GNU General Public License v3.0
829 stars 191 forks source link

Encrypted flag being incorrectly set on SmartNet systems #407

Open robotastic opened 3 years ago

robotastic commented 3 years ago

Calls which are being received on scanners are being flagged as being encrypted and not recorded in Trunk Recorder. It looks like the problem could be with the SmartNet Parsing.

The encryption flag gets set here: https://github.com/robotastic/trunk-recorder/blob/master/trunk-recorder/systems/smartnet_parser.cc#L242 and here: https://github.com/robotastic/trunk-recorder/blob/master/trunk-recorder/systems/smartnet_parser.cc#L349

@leee the previous SmartNet parser did not set the encrypted flag. Do you have more information on the SmartNet status bits and when a call is encrypted? Could you double check the parsing that leads to the two lines above?

ginomiglio commented 3 years ago

Have you experienced this, or someone else? How often does it occur? I only listen to one SmartNet system, but so far I've only seen encrypted calls on the channels that I expect. Wondering if there's a specific config or system necessary to reproduce the problem.

leee commented 3 years ago

I reviewed this and it LGTM. Is it possible that this is a talkgroup with selectable encryption, or have you only heard it in the clear the entire time before the parser rewrite? If the latter, I may ask you to let me remotely look at things, or have you dump logs, audio, CC data, and mark the tapes whenever it happens to take a closer look.

Right now, the way trunk-recorder works is if after some period of rest, if a talkgroup is keyed up encrypted, then trunk-recorder drops the rest of the conversation, not picking up unencrypted traffic interspersed in between. If a call is started with an unencrypted transmission, and encrypted transmissions are interspersed in between, they'll be recorded and demodulated garbled.

I do think this is behavior that should be fixed and all unencrypted traffic consumed. It could be a simple solution as "just record everything, regardless of encryption", or do that along with "keep a status of encryption and if it was encrypted the entire time, dump the call".

I think a more elegant solution would require a conversation on how calls have been handled up to now. I have a preference and do believe there are benefits to having separate transmissions as separate files, and conventional transmissions as squelched (which will be even better with CTCSS/DCS support eventually) and not time outs, but that could anger those with small disks tight on inodes.