gmr

gmr@lists.osmocom.org

3 participants
55 discussions

Does the Galaxy Project offer any specific workflows for analyzing high-frequency financial datasets or integrating real-time market data streams? I am looking to apply computational biological models to large-scale brokerage data.
by maxh65183＠gmail.com 16 Apr '26

16 Apr '26

2 1

[PATCH 0/2] l1/a5: document A5/x family and hardware cipher block
by Dominik Bay 16 Apr '26

16 Apr '26

Two documentation-only patches expanding the Doxygen \defgroup block in the public A5 header. No algorithmic or behavioral change. Patch 1/2 describes the A5/x variant family used by GMR-1 (A5/0, A5/1, n=2..7 reserved), cites the Driessen et al. IEEE S&P 2012 paper as the public algorithm reference, and adds a HYPOTHESIS paragraph noting a conjectured equivalence between gmr1_a5_1() and ETSI TETRA's TEA1 cipher (EN 300 392-7). Motivation: if the equivalence holds, TEA1 reference implementations become an independent cross-validation source for gmr1_a5_1() output on matching (key, fn) inputs. The conjecture is explicitly labelled. Patch 2/2 records the register layout typically observed in deployed GMR-1 hardware cipher peripherals (16-bit MMIO window, four parameter words, selector, auxiliary word, and mode / control word with start / direction / algorithm-family-selector bit fields), plus the observation that the peripheral is usually a multi-cipher accelerator with additional algorithm-family slots beyond A5-GMR-1. The intent is to give capture-side analysis tool builders a concrete interface reference. Independent of the earlier "l1/a5: harden dispatcher default and expand docs" series on the list; both apply on top of master in either order. Dominik Bay (2): l1/a5: document A5/x variants and note TEA1 equivalence hypothesis l1/a5: document hardware cipher-block register layout and mode enum include/osmocom/gmr1/l1/a5.h | 44 ++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) -- 2.53.0

1 2

Auto-Responder to ML - Unsubscribe *@autoshack.com
by Dominik Bay 16 Apr '26

16 Apr '26

Hi, when sending E-Mails to this ML, no-reply(a)autoshack.com sends auto responder e-mails from a ticket system. Please remove them from the ML. Kind regards, Dominik

1 0

[PATCH 0/2] l1/a5: harden dispatcher default and expand docs
by Dominik Bay 16 Apr '26

16 Apr '26

While reading src/l1/a5.c I noticed that gmr1_a5(n, ...) silently falls through its switch default for n >= 2, leaving the caller's dl/ul buffers untouched. The only in-tree caller, at src/gmr1_rx.c:518 (TCH3 decode), passes n as a data-driven value (cd->tch3_state.ciph) into an uninitialized stack buffer ciph[208], which is then fed to gmr1_tch3_decode() as a keystream. For any n outside {0, 1} this means uninitialized stack memory becomes the "keystream" that the decoder XORs against the burst. Patch 1/2 is the defensive fix: zero the output buffers in the default case, matching the n=0 "no ciphering" path so the function's postcondition (buffers are fully written whenever non-NULL) holds for every legal value of n. No algorithmic change to gmr1_a5_1 or the n=0 / n=1 paths. Patch 2/2 is cosmetic: it clarifies the Doxygen block on gmr1_a5() to document the accepted range of n and the behavior per case, and it adds a \see reference on gmr1_a5_1() to the public algorithm description by Driessen, Hund, Willems, Paar, Holz ("Don't Trust Satellite Phones", IEEE S&P 2012) which underpins the existing implementation credit. Both patches apply cleanly on top of master (2b98363, "avoid memory leaks in gsmtap error paths"). Dominik Bay (2): l1/a5: zero output buffers for unsupported A5 variants l1/a5: expand dispatcher doc and cite upstream reference src/l1/a5.c | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) -- 2.50.1 (Apple Git-155)

1 2

Malformed Packet Error in your example data
by 101jordanmichael101＠gmail.com 30 Apr '24

30 Apr '24

Hi, ---> I opened the tnt-call-deciphered.pcap file that you uploaded with wireshark. ---> Then I opened the osmo-gmr code. I got a wireshark output myself using tnt-call-268-93600.cfile , tnt-call-267-93600.cfile and the password. ---> In the resulting wireshark output, the section with (CC) Setup appears as Malformed Packet. a) What is the cause of the Malformed Packet problem? b) How can I fix this problem?

2 1

Can I build my own GMR satellite/base station and core network based on open source software (e.g. Osmo-bts) and SDR?
by 1191595017＠qq.com 07 Sep '23

07 Sep '23

Dear Osmocom community, I noticed that the OSMOGMR project is mainly about receiving and decoding downlink GMR data. Can I build my own GMR satellite/base station and core network based on open-source software (e.g. osmo-bts) and SDR? GMR is mentioned in the Osmo-bts user manual, but it doesn't say if it is implemented and how to configure it. If Osmo-bts doesn't work, is there any other project to build my own GMR base station and establish a connection with a GMR device? Best regards, Wei

2 1

Osmocom discourse as alternative to mailing lists
by Harald Welte 27 Jul '23

27 Jul '23

Dear Osmocom community, while many people with a long history in FOSS development have no issues at all with mailing lists as primary form of engaging with their community, they have undoubtedly fallen out of fashion in favor of various chat/messaging systems or web based forums. In Osmocom, we've just launched an installation of the discourse forum software available at https://discourse.osmocom.org/ providing an alternative to our traditional mailing lists at https://lists.osmocom.org/ We're looking forward to see whether this web-based approach will facilitate more and/or other people to engage with the Osmocom developer/contributor community. Feel free to join and get the discussions started. If there's a need for more categories or sub-categories, just let one of the moderators know and we can help with that. The old mailing lists will continue to remain available for those who prefer them. -- - Harald Welte <laforge(a)osmocom.org> https://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

RACH scan
by Johann T. 05 Feb '23

05 Feb '23

Hi, I have made some captures on the L-band uplink channels and tried to decode the RACH messages. All four consecutive TCH channels (according to the spot beam) were recorded and a call was made during the recording. I am using the GRC block gmr_rach_scan.grc. I have removed the IQ swap from the graph, as suggested in the mailing list. The sampling rate and samples-per-symbol values have been set to 93.6k and 4, respectively. It ran fine without any errors, but I couldn't see any results either on the wireshark or under /tmp/rach.txt. Maybe I overlooked something here. Any ideas or remarks? Many thanks, Johann

3 8

MES to Satellite decoding and A5-1-GMR decrypt
by Tiger Yi 24 May '22

24 May '22

Dear all, Right now I am studing on osmGMR code and try to understand how it works. From the code my understanding and concerns are as below: 1.  It looks like osmoGMR gmr1_rx only analyze and decode downlink(Satellite to MES) messages and data,  am I right?  If there any similar application that can decode both downlink and uplink(MES to Satellite)? Or osmoGMR needs input to implement downlink decode? 2.  A plaintext-decrypt is mentioned in osmoGMR wiki but no detail about how to implement it.   Is there a opensource code for A5-1-GMR? Or any other clue that can understand how plaintext decrypt  A5-1-GMR? Does osmoGMR need input to implemen it? Best Regards, Tiger

1 0

Bug (+ patch) for sync_id retrieval code
by Bart Marinissen 15 Mar '22

15 Mar '22

Hi, Whilst working with this code, I came across some inconsistent sync-ids. Diving in deeper, I found a bug. It’s probably best explained by the patch itself, (see below) but I will also try and explain it in plain words. In short, when checking which sync_id has the highest correlation, the relevant bit of of the signal (with wiggle room) is correlated against the sync-id pattern into a buffer. This adds the output correlation to the buffer. Then, at the end, it was decided which sync_id was present by looking for the max correlation. In between sync-ids, the buffer was not reset. Hence when checking the last sync_id, the buffer does not hold the correlation between that sync_id and the signal, but the sum of correlations between the signal and all sync_id. Hence the results were very strongly biased towards the later sync_ids. The fix is easy. Clear the buffer before every correlation. See the patch below. The patch should apply to the master branch, I believe the bug exists in most branches though,. In my mind, the change is too trivial to be copyrighted. But for completeness sake, I give the osmocom-gmr project permission to use this patch. Kind regards, Bart Marinissen diff --git a/src/sdr/pi4cxpsk.c b/src/sdr/pi4cxpsk.c index 1ed40e01989bac05ff915ebd811835a60f95f61e..e8ab843a92d90622b64b5a59fcaff9ef4d01fea0 100644 --- a/src/sdr/pi4cxpsk.c +++ b/src/sdr/pi4cxpsk.c @@ -204,12 +204,12 @@ _gmr1_pi4cxpsk_sync_find(struct gmr1_pi4cxpsk_burst *burst_type, goto err; } - memset(corr->data, 0x00, sizeof(float complex) * corr->max_len); - corr->len = w; - /* Scan all possible training sequences */ for (i=0; (i < GMR1_MAX_SYNC) && (burst_type->sync[i] != NULL); i++) { + memset(corr->data, 0x00, sizeof(float complex) * corr->max_len); + corr->len = w; + struct gmr1_pi4cxpsk_sync *csync; float s_toa, s_pwr; float complex s_peak;

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

gmr