dsd-fme
dsd-fme copied to clipboard
lwvmobile
EDACS: Improve Standard and EA CC message decoding
I'd like to propose adding support for individual/unit-to-unit calls on EDACS.
The format for EA systems appears to be as follows:
mt1 = 0x10
mt2 = 0x10 for analog, 0x14 for ProVoice
lcn = (fr_4t & 0x1F00000000) >> 32;
dst = (fr_1t & 0xFFFFF000) >> 12;
src = (fr_4t & 0xFFFFF000) >> 12;
I'm not sure of the right way to handle this with allow/blocklist logic for groups - I am having trouble identifying how it works on P25 for individual calls. I have attached a proposed PR #200 and welcome your thoughts!
Okay, thanks for the information and all the pull requests. To be honest, it may take me a while to parse through all the changes you've made and also make sure they all work fine on my local EDACS EA systems. In the meantime, I did make a new branch for this thing, and I do have a request. Can you create a new branch on your fork and just consolidate all your work into one or a couple of commits.
I hate to ask that, but its kind of hard to review changes across three different pull requests all from different branches, and some of the pull requests look like they have overlapping merges, or merge in the same commits from another branch. If you can do that and just send the pull request to the edacs-ea-ilyacodes branch on my end then that'd be great.
Scratch that last request, I was able to figure out how to change the pull request to redirect it to a new branch on my end so we could squash all the commits all at once and I can check it all out together for testing. I may do a few extra updates to it to handle those EA analog calls and tune to them instead of just logging them, since the analog audio works now and there isn't any reason not to tune them, I suppose. I just hope that by pulling all of those in the order that I did there wasn't anything in one pull that might have upset another pull, or if there was, I can probably just go through and figure out the intention and clean it up when I have a good chance to thoroughly test everything out.
BTW, do you have any samples from a system that uses the I-Call and also the analog calls, I don't see that here on SLERS, or if its there, I'll have to let it run for quite some time to catch them.
Hi there,
Sure thing, I can get some samples - they're not used a ton, but I do see both analog calls and i-calls on a system near me.
What's the best way to get a recording that would work for you? I'm using the current release from github on Windows, along with SDR++ as the source, and an RTL-SDR.
Thanks for working on this, I appreciate it! Looking forward to having these improvements tested and in to help my monitoring :)
On Sat, 16 Mar 2024 at 17:20, lwvmobile @.***> wrote:
Scratch that last request, I was able to figure out how to change the pull request to redirect it to a new branch on my end so we could squash all the commits all at once and I can check it all out together for testing. I may do a few extra updates to it to handle those EA analog calls and tune to them instead of just logging them, since the analog audio works now and there isn't any reason not to tune them, I suppose. I just hope that by pulling all of those in the order that I did there wasn't anything in one pull that might have upset another pull, or if there was, I can probably just go through and figure out the intention and clean it up when I have a good chance to thoroughly test everything out.
BTW, do you have any samples from a system that uses the I-Call and also the analog calls, I don't see that here on SLERS, or if its there, I'll have to let it run for quite some time to catch them.
— Reply to this email directly, view it on GitHub https://github.com/lwvmobile/dsd-fme/issues/199#issuecomment-2002136899, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH4QONIPHKNF7URLEP6I2YDYYSZSDAVCNFSM6AAAAABEZHVD3OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBSGEZTMOBZHE . You are receiving this because you authored the thread.Message ID: @.***>
If you use SDR++, you can just use the recorder module in there to make a wav file of the control channel for when it happens, or if you are using dsd-fme, you can just create a .bin file with -c edacs.bin and zip it up and send it to me. I usually just recommend users upload samples to https://ufile.io/ and send the link here.
Are you using another piece of software for comparison on the i-calls, like Unitrunker or something that can decode EDACS, or just looking at the frames and putting it together?
Copy that, I’ll do that and send you some samples – might take a couple days to get everything together.
I’ve been using the debug dumps of FR_1 and FR_4 that FME shows for unrecognised MT1 opcodes, and then piecing it together from there.
Unitrunker doesn’t appear to support i-calls either, at least for EA… and I don’t know of any other EDACS decoding software. Hopefully my research can contribute to unitrunker too, though of course that’s closed-source.
On Sat, 16 Mar 2024 at 18:19, lwvmobile @.***> wrote:
If you use SDR++, you can just use the recorder module in there to make a wav file of the control channel for when it happens, or if you are using dsd-fme, you can just create a .bin file with -c edacs.bin and zip it up and send it to me. I usually just recommend users upload samples to https://ufile.io/ and send the link here.
Are you using another piece of software for comparison on the i-calls, like Unitrunker or something that can decode EDACS, or just looking at the frames and putting it together?
— Reply to this email directly, view it on GitHub https://github.com/lwvmobile/dsd-fme/issues/199#issuecomment-2002158524, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH4QONIZOLL3RT7D6WUNPZDYYTAN3AVCNFSM6AAAAABEZHVD3OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBSGE2TQNJSGQ . You are receiving this because you authored the thread.Message ID: @.***>
Okay, well, there is no rush. I suppose you can confirm though actual listening that analog calls and digital I calls do indeed occur on those LCNs when indicated by your code update then?
Correct - I have verified through monitoring that the calls are taking place at that time.
I'm having trouble building for Windows right now - do you have any advice on how to do that? I will try again on Linux but it would be best if I can verify the code changes directly on Windows if possible.
Yeah, building in Windows is kind of a hassle, no matter which way you go about doing it, that's why I have an cygwin environment on a VM that doesn't get touched and is only used for building and putting together new windows releases.
Here, try this, its an exe file with your code updates, along with one of mine to tune the analog calls. Just copy and paste it into the release folder's dsd-fme folder and point your bat file to the exe by name.
Thanks! I'm testing it right now - the code to allow users to turn groups on/off is working fine, though monitoring when group calls are enabled is pretty laggy. That may just be something on my computer though.
It doesn't seem to trigger my other code for analog calls or i-calls though.
Sorry to do this iterative debugging, but would you please add these 4 lines after L522 in edacs-fme.c, right after we know we're in EA mode, but before the MT1 comparisons start, and send me that built for Windows?
fprintf (stderr, " esk_mask [%010llX]", state->esk_mask);
fprintf (stderr, " FR_1 [%010llX]", fr_1t);
fprintf (stderr, " FR_4 [%010llX]", fr_4t);
fprintf (stderr, " Unknown Command");
I'll be happy to test that, my guess is that the esk_mask on L523 is actually not 0, and that has rendered my MT1 calculations incorrect.
Created #202 to fix this, since I am reasonably sure now that esk_mask is actually A0.
It seems to work now! I was able to follow one digital i-call, still waiting on analog data. I'll let it run and get you some recordings for the other protocol types, they're sporadic but I've seen 1-2 per day most days.
The only thing left is any sort of formatting that may be desired - I have a proposal here #203 which I think would make everything a little more consistent with the other protocols using TGT.
Thanks for all your help and support on these changes!
Yep, no problem. Here is the last run for the day, if you add anything else later on, it'll have to get generated on another day. dsd-fme-aw-edacs3.zip
I can confirm your Login command does seem to show groups with radio ids I am familiar with here locally, so, that seems to be working correctly. I was wondering the the add/kick/login was all apart of the same kind of command structure more akin to how DMR/P25 how unit registration/deregistration/authentication checks, etc. Never really dug very deep into it in the past, I was just happy to make it trunk back int he day when I was working on EA.
Don't forget to push a commit with your name in the credits/thanks of the readme and/or in the header of the edacs c file if you want to.
I think we're getting really close! I did discover that the I-Calls actually have different MT2s for the initial voice grant vs the voice grant update when the call is in progress – #205 sent your way.
Glad to hear that logins are working for you. I'm not familiar with kick, other than your commented out code... is that like a forced deregistration command? I saw that in UniTrunker only once before, so I'm really not familiar.
It would be really nice to figure out the remaining EA CC messages, but most of the others I see here are constants:
FR_1 [FB80AE16EF] FR_4 [0000AE1E2B]
FR_1 [FD8FFFFA19] FR_4 [FD9FFFF8D8]
which does not aid in reverse engineering. I would almost guess that the FD8 one might be an idle CC message, to fill time when there's nothing else to say?
I may go on the hunt for more information in EDACS patents, since there appears to be very little literature on the topic.
While your busy toiling away over there, can you add this conditional check prior to tuning a voice channel to make sure we know what control channel is so we can return there, same place you had lcn > 0 will be good.
state->edacs_cc_lcn != 0 &&
and also for STD/NET calls, you have an errant lcn value that needs to be removed or commented out.
Should be:
The errant line is breaking STM in Montreal on Standard.
I tried to make these changes directly on your branch for the pull, but you had already made another update when I was working on it and I couldn't commit my change.
You working on anything else before I squash merge this and crank out a new exe for you?
Nope, this is all I've got for now - fingers crossed, it should be it for a while, unless I can find more MT1/MT2 decodings (searching through patents now).
Alright, here is the current exe.
And, here is a local log with a bunch of the "KICK" command present, if you really get bored and want to look at that, or just look at what I usually see over here locally. edacs-ea.zip
If you're interested, I'll try to capture a long bin file, see if I can catch any unencrypted traffic. Here, its mostly all encrypted, aside from a few neighbor talkgroups that come over sometimes from the neighboring county when they are affiliated with the local site.
I've had the 5.exe running for a while and it seems to be working well. I've seen a few more unindentified opcodes and am trying to make sense of them now, but they don't appear to be related to i-calls. imho this issue is fine to close, and the changes are ready to merge to whatever your main/master branch is.
If you want to send a long file of your CC, I'm happy to take a look, though it would be hard to analyse much without comparing against other software and also a good knowledge of the system...
Do you happen to know how to tell whether a call is encrypted? Most of the ones on the system here are in the clear - perhaps we can diff the ProVoice data to find the flag that identifies a call as encrypted, then it would be possible to un-tune from encrypted calls when the key is not available.
I'll leave the issue open as well as the branch open for a while longer, you never know when the urge will strike to make more updates, not to mention, I've also been working on some filters for analog audio to clean up those analog calls among other places where its used, and have been merging this branch and the filter branch into a chimera branch for remote testing.
I suppose other than just using Unitrunker or perhaps finding a good patent, there isn't really a way to work out some of those frames unless you have insider knowledge of a system. TIA does still sell documents related to EDACS, however, but they aren't cheap, and who knows what they do or do not include, so I personally wouldn't buy them just to figure out a few random odds and ends if we can trunk well enough as is.
I have never seen an indication on EDACS of when a call is encrypted vs when it is not, however, on the ProVoice frame, you can look at the initial hex values of the frame before the voice payload and tell. What I have determined so far is that if the call is unencrypted, then there is a repeating 0x6969696969696969, and if it is encrypted, then it is a pseudo random initialization vector used for encryption. Other than that, there seem to be some for of opcode on the ProVoice frame that indicates when it is actual voice vs some other signalling, that I haven't worked out, although, there IS a TG value buried in it, but only on EA and not standard.
I had some code to check the IV value, and if not 0x6969 repeating, then to mute it as enc, but I am unaware of any particular method of error correction for the meta data in the provoice frame, so any single bit error would cause random mutes for that frame and it would blip in and out at times on more distant signal. If it were reliable with known FEC, then I could just tune away and lock out repeat tuning, like I do with other system types, but as is, it would trigger tons of false positives.
09:53:26 Sync: +EDACS Group [01123] Source [00197868] LCN[02] Digital Call
Tuning to 851800000 Hz. (Center Frequency: 852052000 Hz.)
09:53:26 Sync: +EDACS Site ID [F3][243] Extended Addressing
09:53:26 Sync: +EDACS BCH FAIL
09:53:26 Sync: +PV VOICE Site: 243 Group: 1123 Source: 197868 LCN: 2
N64: 0EBFAA55A800118D
LID: 41B1 57FFEE72BE4EA800
IMBE F3A595D999DD348B447389 err = [1] [7]
IMBE 0BDA2711AB2895A1C78DB5 err = [3] [B]
BF: AA55
IMBE B2B350A82C337E7780C277 err = [3] [A]
IMBE 260B80126BDC62ED0E369C err = [2] [B]
09:53:26 Sync: +PV VOICE Site: 243 Group: 1123 Source: 197868 LCN: 2
N64: 0EBFAA55A800118D
LID: 41B1 57FFEE72BE4EA800
IMBE F3A595D999DD348B447389 err = [1] [7]
IMBE 0BDA2711AB2895A1C78DB5 err = [3] [B]
BF: AA55
IMBE C757441843396E4B47FEA6 err = [0] [6]
IMBE F7061B0963C761FE47320E err = [3] [8]
09:53:26 Sync: +PV VOICE Site: 243 Group: 1123 Source: 197868 LCN: 2
N64: 0EBF33CC830F94D8
LID: 3523 0EBF33CC641394D8
IMBE 2F3A80FDCEF8EC1CF8F310 err = [1] [9]
IMBE 7EC633551F12B0E3D28A3B err = [2] [9]
BF: FD11
IMBE 10F26A5EBD71D0F899D6E3 err = [2] [7]
IMBE AA0654FE676373A09B73DE err = [2] [9]
09:53:26 Sync: +PV VOICE Site: 243 Group: 1123 Source: 197868 LCN: 2
N64: 0EBF333311578126
LID: 08D0 237A9C00FF83DF17
IMBE 035AA3F7F700E6BAFE3670 err = [0] [0]
IMBE 03E728F1996532819C175C err = [0] [0]
BF: 2175
IMBE 03225A3DC11C64E94EAA65 err = [0] [0]
IMBE 661EDAE01212F3F16807B0 err = [0] [0]
09:53:26 Sync: +PV VOICE Site: 243 Group: 1123 Source: 197868 LCN: 2
N64: 0EBF3333D64BCC75
LID: 3190 68A5FD747E83DF17
IMBE 3F600A943CFBA367B75DFE err = [0] [0]
IMBE 344B856DCE4E93BCA1F532 err = [0] [0]
BF: 2175
IMBE 479C6887DA25F1D8687D5D err = [0] [0]
IMBE 2FD44F264AB207A63EE13A err = [0] [0]
I've actually got a copy of TSB 69.3, but not only is it for EDACS standard, but it also seems to predate digital voice - the CC messages don't match the code in FME at all. I also don't have any standard systems nearby that I know of to try FME on.
I did manage to capture some system all-calls over the last few days, and made some other minor cleanups - #214. I think this is getting close to the limits of what we can find out through simple monitoring...
I did see some emergency calls today, but I didn't have FME running at the time 😠 (was monitoring on an actual radio). Maybe I'll catch one of those at some point too, I'd guess that's probably a different MT1 for an emergency voice group call.
I hope you didn't fork out money for that manual, or maybe its an older edition if you only have Standard in it. The webstie indicated there was a 98th edition, so I wonder if that means they really revised and updated that standard 98 times.
Alright, sounds good, I'll have to test the all-call and other code you wrote over on this end when I have a chance. Next time I send you an update, it might be from the testing branch I'm doing each time I do updates to filtering, I've been merging your branch and the filter branch and letting it run for the day and noting little things and making changes here and there.
I happened to catch an odd phenomina as well this morning on Standard where there was two AFS values indicated on the same LCN at the same time for a call, so guessing that's how patched calls may work on analog. Not sure. I didn't debug the frames to see if anything of interest was happening in them.
https://ufile.io/jdaa43k8
Also, been meaning to ask you. What part of the world are you in where EDACS EA is in use / still in use? Outside of Florida SLERS, I didn't think there were any other EA systems still in the wild and/or still active.
I'm in the greater Boston area - the regional transit agency (MBTA) is still on EDACS EA, though they are allegedly switching to a new Harris P25 system in the next year or two. I've been monitoring them since I got a Harris radio, but wanted to track more of what's going on on it, hence the sudden interest.
If you have a chance to build the PR I sent (with or without your filtering branch) sometime, that would be much appreciated - I'm trying to figure out additional bits in the CC data packets, so the new payload dumping changes I added would be very useful. In particular I'm hoping to run it to catch the next time there's an emergency call.
I've heard the same rhetoric about the SLERS system, its been going to change over to Harris P25p2 'soon' for years now. I honestly don't think its going to come offline anytime soon over here, particularly in the more rural areas.
Here is the latest build, it also has the code for the new_filters branch I've been working on as well, so should be a good test for both code bases at the same time, I guess we will see how it goes.
Well, my first finding here is that the ESK mask code actually does not in fact work fine... there is a bug where if an analog voice grant is seen, any digital voice grants that follow it will be processed incorrectly (MT1 parsed as 17 instead of 03). It's much too late now to make sense of how that logic works, but that seems to be a problem.