From laforge at osmocom.org Fri Sep 4 19:08:20 2020 From: laforge at osmocom.org (Harald Welte) Date: Fri, 4 Sep 2020 21:08:20 +0200 Subject: OsmoDevCon / COVID-19 Message-ID: <20200904190820.GA609235@nataraja> Dear fellow Osmocom developers, as you all know, we've sadly had to postpone OsmoDevCon 2020 back in April this year. At the time, we discussed to re-visit the situation in October 2020. While legally it is no problem at all to host an event with ~ 20 participants in Berlin/Germany (specific regulations really only start from 50+ participants) - I'm not entirely convinced it would be the smartest move. Legality and public health regulations are only one part of the equation - common sense and profound care for the key members of our community for sure are more relevant considerations to me. I'm not 100% in favour and not 100% against. Hence, I would like to get your input. Should we a) try to get an event organized on-site in Berlin? We'd have to move to a larger venue than IN-Berlin with proper ventilation and sufficient space so we can keep physical distance, but I think that's manageable for sysmocom as organizer. b) simply postpone to 2021? I'm convinced the situation will not change significantly (in a positive way) until late April 2021, so it's not really a "solution" as it will likely mean we have to think of late 2021 or 2022. c) plan some kind of online conference? To be honest, I think this model works fine for events where a single speaker wants to give lectures to hundreds or thousands of participants. But OsmoDevCon is much more interactive. We could record or live-stream some talks or screencasts from home, sure. But that only captures one part of the event. We could also try to set a date for a collaborative mumble, or the like - for the "hallway track". What are your thoughts? Let's avoid cross-posting the discussion to all of the mailing lists and simply have it on openbsc at lists.osmocom.org. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From johann.tzt at gmail.com Tue Sep 22 13:16:44 2020 From: johann.tzt at gmail.com (Johann T.) Date: Tue, 22 Sep 2020 15:16:44 +0200 Subject: Decoding example data with osmo-gmr Message-ID: Hi, I have been looking into the example data provided by Osmocom as shown in the link below. http://osmocom.org/projects/gmr/wiki/Example_Data I could reproduce the first pcap output (up to the Ciphering Mode Command) for the Voice call using the gmr1_rx_live from the live branch. With the provided Kc, I thought I would be able to reproduce the second pcap (including the call setup). I have modified the sa_tch3.c to include the Kc code. However, I am not able to get the results as shown in the second pcap file. I noticed that in the sa_tch3.c code, there is a ciphering part (marked by "Retry with ciphering") which was disabled. This part of code didn't compile as some variables were not defined. Probably my approach was not right. Any pointer here? Which code is needed to produce the second pcap (deciphered) file given the Kc is known? Many thanks in advance. Best regards, Johann -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Tue Sep 22 15:13:23 2020 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 22 Sep 2020 17:13:23 +0200 Subject: Decoding example data with osmo-gmr In-Reply-To: References: Message-ID: Hi, > Probably my approach was not right. Any pointer here? Which code is needed to produce the second pcap (deciphered) file given the Kc is known? > Many thanks in advance. You won't be able to reproduce exactly the same results. I had to redact some private information from the captures. In the .pcap I could just manually overwrite a few bytes, but for the RF captures, I had to zero-out entire bursts to make them non-decodable and that messes with the ability of wireshark to re-assemble the fragments. And decryption support is present in the non-live version : gmr1_rx 4 tnt-locupd-267-93600.cfile tnt-locupd-268-93600.cfile eb9c4d2b0d027131 gmr1_rx 4 tnt-call-267-93600.cfile tnt-call-268-93600.cfile ebc34fcbd572466 Cheers, Sylvain