Batboard

Anyone out there seen an issue with MCC7500 consoles occasionally not de-crypting or encrypting properly? We have a new 7.14 system, and use AES with CKRs and all keys for consoles & radios are loaded via Key Management Facility and OTAR/OTEK.

We've had a few issues where a console will suddenly start sounding 'garbled' to the field radios...rebooting the VPM seems to fix it.

Just yesterday had a field radio that other field radios could hear fine, but the console only heard the 'garble' as if it were the wrong key. Odd thing was the console heard all the other radios just fine, but not that one in particular, and they were all using the same key.

You can hear a clip of yesterday's conversation here:

https://drive.google.com/file/d/0B9vLYl ... sp=sharing

Other field users had to tell the dispatcher what the affected radio user was saying.

Definitely sounds like a enc/dec problem. I'd start a support ticket with MOT. Very odd that it's just the console, and one subscriber. It's almost like the key and the unit ID are tied together somehow. The ID is failing in the console decoder. So the console gets golly-wobble. But, the ID passes in the system. So, it repeats fine.

Humm,

7.14, conventional or trunking?

Definitely sounds like an issue with the MACE. There is an FSB out on the VPM and MACE shields that can cause "tin wiskers" on the inside which can cause all kinds of issues.

Do you allow key selection or clear/secure on resources?

Does this problem happen on the other consoles at the same time, is this a 1 console system or does it happen independently on each console at separate times?

When you are saying the console does not decode the ID of the user though this brings up another avenue where the subscriber may be in bad shape.

Does the issue occur for multiple subscribers?

I had something similar to this happen before with the radios setup for using last key.

I run all encrypted subscribers strapped to avoid issues with programming and users but this sounds for now console related.

CoM

Are you certain the VPM's are running the latest firmware for your release? These things were plagued with problems when they were first release (just like any other Motorola product), and you may have ended up with one/some that have old firmware in them.

Thanks for the posts guys. We believe we know what happened...I'll summarize how it was explained to me by a Motorola FST.

With OTAR, the field radios hold the current key (I'll call it the 'A' key) in a memory slot. When the KMF gives the radio the new 'B' key, it goes into another slot, and the radio is given a date/time to switch to it. Once the date/time has arrived, the radios *should* automatically switch to using the 'B' key, but sometimes they don't. They will also hold onto the 'A' key until it is over written with the next OTAR key, unless programmed to dump the old key, which ours aren't. So, the field radios will continue to be able to talk to one another regardless of whether they are using the 'A' or 'B' key, since they have both in memory. Apparently, the consoles only hold the latest key, so they do not understand any radio still using the 'A' key. I don't yet know if that's a configurable parameter or not.

It's popped up a few times since, and manually re-keying the field radio via the "rekey" button fixes the issue. The wonderful world of encryption...still learning.

We do have all encrypted radios strapped, as well as all encrypted talkgroups set for 'secure only' in the system, just to answer a few of the questions posed.

Dual keys in the subscribers. Interesting. This is almost worthy to be a sticky. Thanks.

I am also running a MCC 7500. I dial in each month with my KVL4000 to get new keys, running AES with a 7.13 system. I get my keys from NLECC in Orlando. I had long conversation with them about exactly same issue, the subscriber units having two sets of keys, current month and last months keys, and my MCC 7500 having only one set of keys. They set up my KVL to perform "Job's for each of my VPM's, based on each VPM's unique RSI. Each month now when I dial into NLECC's KMF, it sends me 10 jobs (one for each VPM), and all the new keys. I connect the KVL to the VPM, the KVL automatically see's the RSI for the VPM, knows it has a job for that VPM and sends the correct job information to the VPM. The job, tells the VPM to perform exactly like the subscriber units, it holds the two sets of keys. I can't tell you how to set up or program a job in the KVL, NLECC did it all for me.

Bill_G wrote:Dual keys in the subscribers. Interesting. This is almost worthy to be a sticky. Thanks.

This was a gotcha for us before as well, though I hadn't put 2 & 2 together. TAIT & Motorola both advertise I believe 32 slots being available for keys in their top tier radios. What they fail to mention ANYWHERE is that when using OTAR, you need to divide that number in half, since there NEEDS to be an empty slot for the radio to store the "B" key while waiting for the rollover date. If you have customers with a lot of keys (we had one) this can cause big issues!

jpatrou wrote:I am also running a MCC 7500. I dial in each month with my KVL4000 to get new keys, running AES with a 7.13 system. I get my keys from NLECC in Orlando. I had long conversation with them about exactly same issue, the subscriber units having two sets of keys, current month and last months keys, and my MCC 7500 having only one set of keys. They set up my KVL to perform "Job's for each of my VPM's, based on each VPM's unique RSI. Each month now when I dial into NLECC's KMF, it sends me 10 jobs (one for each VPM), and all the new keys. I connect the KVL to the VPM, the KVL automatically see's the RSI for the VPM, knows it has a job for that VPM and sends the correct job information to the VPM. The job, tells the VPM to perform exactly like the subscriber units, it holds the two sets of keys. I can't tell you how to set up or program a job in the KVL, NLECC did it all for me.

Good to know it can be done. I assume we can do the same via OTEK...will need to talk to the KMF administrator. Thanks for the input!