baseband-devel March 2018

baseband-devel@lists.osmocom.org

9 participants
11 discussions

SMS not received in mobile - Virtual layer1 (osmo-nitb + osmo-bts + osmocom-bb/mobile)
by Sebastian Stumpf 05 Jan '26

05 Jan '26

Hi, Some of my sent SMS are not received by my mobile and I try to figure out if this is a problem with my virtual layer 1, configuration or something in the layers 2+. I use: osmo-nitb: 1 subscriber in hlr (id 1, ext 017519191919) osmo-bts: virt-phy, arfcn 666, TS0=CCCH+SDCCH4, TS1=SDCCH8 MS layer23 app mobile: is the subscriber from osmo-nitb MS layer1 virt-phy: virtual gsmtap layer between bts and mobile I want: Send a sms to subscriber 017519191919. osmo-nitb VTY: OpenBSC# subscriber id 1 sms sender id 1 send Test I have 2 outcomes, first one is the failure. See https://www.dropbox.com/s/eunpfioq518t09a/mobile--ms-virt--bts-virt--bsc-ni… for the pcap. Do not wonder about the duplicated gsmtap messages from mobile, the ones to ip 225.0.0.1 are over virt-phy layer, the ones to localhost from the gsmtap logging option from mobile. Filter them out via "gsmtap && (ip.dst != 127.0.0.1)". 602-613: RR channel establishment with RA and IA as reaction to paging in 590 627,631: SABM from BTS to establish async balanced mode on SAPI3 (SMS) and the ACK from MS 656,684,699: I-Data frames on SAPI3 containing the sms 660,688,703: ReceiveReady's from MS (That ACK all I-frames before N(R)-1 as far as I understood) For me, that looks good and I really do not understand why the MS will not answer with the CP-ACK/RP-ACK after receiving the SMS Data in 699. The LAPDM link will stay up for some more time and be used by the network for retransmission of the sms (1149), but MS will never react to it on the SMS layer (CP-ACK, RP-ACK). Here is the console log for the mobile (https://www.dropbox.com/s/6gug5cd4up5qv7y/mobile--ms-virt--bts-virt--bsc-ni…). The paging is answered in line 378: Fri Mar 10 10:42:06 2017 DLLAPD <0012> lapd_core.c:793 SABM(E) received in state LAPD_STATE_IDLE Second outcome is a successfully sent sms from network to ms. See https://www.dropbox.com/s/ghdn7pc0j4vifbe/mobile--ms-virt--bts-virt--bsc-ni… for the pcap. What is different here? There is no paging, but the sms is sent within the dedicated channel used for the location update initiated by the phone started up. Why there is another outcome, I don't know. 169-181: RR channel establishment with RA and IA as part of mibiles startup routine to make location update 188,416: Location udpdate procedure on SAPI0 230,234: SABM from BTS to establish async balanced mode on SAPI3 (SMS) and the ACK from MS 396,444: I-Data frames on SAPI3 containing the sms 400,449: RR's from MS 450: CP-ACK for BTS 482,499: RP-ACK I-Frames for Network (osmo-nitb) Again, the console log of the mobile (https://www.dropbox.com/s/cujsn40d43g6wxk/mobile--ms-virt--bts-virt--bsc-ni…). The SABM on SAPI3 on downlink is received in line 206: Fri Mar 10 11:06:13 2017 DLLAPD <0012> lapd_core.c:793 SABM(E) received in state LAPD_STATE_IDLE The signaling looks quite similar in both cases, but one time the mobiles sms handler responds to CP-DATA msg containing the SMS, the other time not. Can someone find an error in the signaling I did not see? Is there a known Bug? To be honest, I last merged my branch with master some time ago (~ Jan 18 2017) and thus did not update osmo-nitb and the libraries since then to avoid compatibility problems. Have there been recent changes that could cause that behavior? Thank you and Kind Regards, Sebastian

3 2

Engagetted !
by Sébastien Lorquet 14 Oct '25

14 Oct '25

http://www.engadget.com/2010/12/29/researchers-eavesdrop-on-encrypted-gsm-c… Congrats!

7 7

Calypso BTS
by phreaker1983 16 Nov '19

16 Nov '19

I tried to install CalypsoBTS have libosmocore installed, osmo-bts osmobsc, libosmo-netif, libosmo-abis, ortp, trx, libosmo-dsp everything went without errors, following the instructions I created: touch ~/.osmocom/open-bsc.cfg , then when you run : osmo-nitb -c ~/.osmocom/open-bsc.cfg-l ~/.osmocom/hlr.sqlite3-P-C --debug=DRLL:CC:MM:RR:RSL:NM shows me:<0005> bsc_init.c:498 Failed to parse the config file: '/root/.osmocom/open-bsc.cfg' file tried to create as administrator but without success , pleas help me -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Calypso-BTS-tp4026753.html Sent from the baseband-devel mailing list archive at Nabble.com.

6 13

Fwd: OSMOCOM-BB HandOver
by Muhammad Awais Aslam 12 Jan '19

12 Jan '19

Hi, We have been working on the handover feature in OsmocomBB and have managed to make some progress including SB/BSIC detection in dedicated mode which was not previously being successfully done in firmware. I wanted to share it and seek guidance on the last bit of handover implementation on which we are stuck. I hope someone would be able to help us or make use of our work. We took code related to handover from the osmocom-bb jolly branch by manually adding/deleting stuff in the master branch as updating to the latest copy was giving us issues. We added code from the “Safely change TPU offset on TS change or sync change” commit till the “Use only sel_si for information about the current cell” commit. Using the handover code in the jolly branch and after making the changes explained below we were able to obtain the handover command from the BTS. The synchronized handover case works sometimes though still not every time, however the non-synchronized case doesn't work at all as we are not able to get the physical information command from the new cell. I'll explain the changes/additions we made to achieve this. Firstly, we noted that in dedicated mode SB burst was not being detected. Changes were required at three main places in order to correctly perform FB/SB detection: - It was seen that the results for SB were being read from DSP API location dsp_api.db_r->a_sch which is for the idle mode. The results had to be read from the dsp_api.ndb->a_sch26 location for the dedicated case if TCH_SB_DSP_TASK is used. - After reading the FB we needed to update the quarter-bit offset of the TPU using the TOA of the FB to sync it with the start of frame of the neighbour cell in order to catch the SB (by changing the vaule of l1s.tpu_offset using the TOA of the FB). - Frequency compensation needed to be performed using the afc_correct function before reading the SB. * We actually kind of cheated a bit by adding 3 frames to the original idle frame in order to give us more time to perform FB/SB detection including the synchronizations mentioned above. This was because we weren't that proficient with the code and someone with more understanding could do this better. The call did not get dropped. We used the initial added “idle” frame to perform the quarter-bit and frequency compensation which was reversed in the idle frame with the response function to tune back to the serving cell. These things, when added to the code did the trick and BSIC of the neighbours was obtained. Once the BSICs were decoded the measurement report sent to the BTS became meaningful and the handover command was received. Upon receiving handover command, access bursts needed to be sent on the new channel which again was not currently being implemented properly as in order to tune to the new cell we needed to know its quarter-bit offset for start of frame, frequency compensation and absolute frame number which were not previously being obtained. Now that we were able to detect FB and SB these values were stored for the neighbours following detection of these bursts and were used to tune to a neighbour cell in case of a handover to it before the sending of access bursts. However, here is where we are stuck. We were expecting a physical information message following the access bursts but were not able to receive it due to which the handover failed. If only that could be achieved we believe handover should be successful. Either we are not syncing properly to the new cell or we might not be following GSM protocol properly. We also might not be reading the FACCH properly for physical information message after tuning to the new cell as we couldn't really understand that bit very well. We wanted someone expertise on this matter and were hoping our work could be of use. We were more interested in getting the work done first up. Best Regards, M. Awais Aslam

3 3

Approach to system testing for Osmocom stack
by Holger Freyther 20 Aug '18

20 Aug '18

Hi, the lua binding code was added to be able to automate OpenBSC tests. In theory we should be able to do this for SMS and UpdateLocation (call handling with MNCC exposing is left as a todo) but in practice we miss a piece of software to coordinate this and run the test. We miss it because it is an interesting problem but also I lost time on switching countries, learning new tricks at a project... The basic testing structure looks easy as well. We want to define the number of concurrent subscribers (0, 10, 100, 1000, n) and to make it simple a single test (UL, send SMS, t) and execute the same test for each subscriber and call it a success if y% of tests succeed within time T. The way to measure this is easy as well. The lua script would print some data (e.g. the name of the ms) when it starts and completes. For some degrees of freedom I don't have a good idea.. and feedback is welcome. I am not sure if I should spawn, configure, add subscribers, a flavor of Osmocom cellular? I look into having some set of templates for the config, the stack to launch and in concept it looks awfully similar to something the GSM tester is doing. Shall we leave virtbts/cellular to the Osmocom tester and just focus on coordinating mobile? My feeling is to leave this to the Osmo GSM tester. If we have n subscribers I would launch m copies of "mobile" (but run multiple MS in a single binary). So with 4 MS per mobile process and 10k subs we would end with 2.5k processes + many log messages coming from each. Would that scale with python? Should we look into doing this one in Go? Or can some of GSM tester be used (the template part)? I would probably design this concurrently with Go(besides being the first). any ideas/comments? holger

3 14

Proper measurement reporting
by Vadim Yanitskiy 12 Aug '18

12 Aug '18

Hi Sylvain, I am currently working on https://osmocom.org/issues/2988#note-21. And while reading the specifications and looking at the Calypso PHY implementation, I've got a few questions. In short, according to the GSM TS 04.08, section 3.4.1.1 "SACCH procedures", Measurement Report messages are sent at each possible occasion when nothing else has to be sent. In other words, a dummy LAPDm fill frame (0x01, 0x03, 0x01, 0x2b, ...) is not applicable here. The Calypso PHY (i.e. the firmware) is sending self-composed Measurement Reports if there is nothing in transmit queue: > static uint8_t ubMeas[23] = { > /* L1 SAACH pseudo-header */ > 0x0f, 0x00, > > /* lapdm header */ > 0x01, 0x03, 0x49, > > /* Measurement report */ > 0x06, 0x15, 0x36, 0x36, 0x01, 0xC0, 0x00, 0x00, > 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > 0x00, 0x00 > }; > > /** > * Is called every time when when > * a new LAPDm frame received from DSP > */ > void pu_update_rx_level(uint8_t rx_level) > { > ubMeas[7] = ubMeas[8] = rx_level; > } > > const uint8_t *pu_get_meas_frame(void) > { > if (l1s.tx_meas) { > /* There is a Measurement Report in transmit queue */ > return l1s.tx_meas->l3h; > } else { > /* Compose a Measurement Report */ > /* Update L1 SAACH pseudo-header */ > ubMeas[0] = l1s.tx_power; > ubMeas[1] = l1s.ta; > > return ubMeas; > } > } I am not sure if this is the correct way. Why? - The Measurement Reports coming from the higher layers may contain additional information, such as the neighbour measurements. - The higher layers may spoof indicated TA value, while this code uses the actual one. - Measurement Reporting is already implemented in the higher layers, so this duplicates... My current ideas are: 1) Create a separate L1CTL message, that would be used to carry Measurement Reports. This way we wouldn't need to extract them from the L1CTL_DATA_REQ messages manually. 2) Keep a last Measurement Report somewhere, and transmit it until a new one is arrived from the higher layers. But I am still unsure, is this approach correct too. Probably, some parts of the Measurement Reporting implementation should be moved to L1, i.e. to the firmware, trxcon and VIRT-PHY. This way each Measurement Report would always contain the actual measurement results at the moment of transmission... What do you think? Any ideas are welcome! With best regards, Vadim Yanitskiy.

3 3

OpenBTS OsmocomBB Asterisk
by trixbox.t 15 Jul '18

15 Jul '18

Hello! I Need Help I install these three programs OpenBTS, OsmocomBB, Asterisk Then run them, Everything works well OpenBTS sent an SMS to my phones I answered and he checked me I registered into OpenBTS a second phone I tried to transfer SMS between phones - all good but when I try to call from one to another I did not get Asterisk writes ================================================================ *CLI> Retransmission timeout reached on transmission 755803415(a)127.0.0.1 for seqno 179 (Critical Response) -- See wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions Packet timed out after 32001ms with no response ================================================================ Why? What do I do? -- View this message in context: http://baseband-devel.722152.n3.nabble.com/OpenBTS-OsmocomBB-Asterisk-tp402… Sent from the baseband-devel mailing list archive at Nabble.com.

6 14

IMEIs
by Tudor Pop 26 Mar '18

26 Mar '18

Hi. I’m just a GSM enthusiast and pretty new on OsmocomBB project. I have some experience with OpenBTS and Range hardware (lab kit). I would like to know if running OsmoBTS, I can get instead on IMSI/TMSI pairs, only camped phone IMEIs. How can I do that? Thank you very much for helping me. Cheers, Tudor Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

1 0

Re: TRX toolkit - mobile app
by Vadim Yanitskiy 17 Mar '18

17 Mar '18

Hello Victor, > I would like to congratulate and thanking you for the excellent > job you did on the osmocom TRX/gr-gsm project. Thanks. Please note that I am also CCing this message to the Osmocom baseband-development mailing list, because this info could be helpful for someone else. > I'm trying to implement into your fixeria/trx branch the ability > for mobile app to connect to a commercial network using > a SIM card into a PC/SC reader. Great. I also was going to implement this, but happy to see your efforts towards this direction. > I have a working "prototype" of an osmocom-bb (latest version) > using a PC/SC reader. I can sucessfully connect a C139 running > osmocom-bb with a commercial SIM inserted into > a PC/SC reader to its network. Please send your changes for review to gerrit.osmocom.org. I'll be more than happy to facilitate merging this work to master. See: https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit > I'm trying to import my code into osmocom TRX but I can't get mobile > working at all (even without my code) I tried using > "7fd8ef2d3f3d296a6032745396d3af8e8e3d4da2" and the last one > "4ccb2261b1ac2e207303393fe509878f160dd96b" using > "7fd8ef2d3f3d296a6032745396d3af8e8e3d4da2", It looks like mobile app > is sending Location Update Request corectly to GR-GSM but I can't sniff > it (over the air or from wireshark). > > I'm pretty sure the BTS doesn't receive it neither. > using "4ccb2261b1ac2e207303393fe509878f160dd96b", > it doesn't do anything. It's only receiving packets from PCH/AGCH. Would be great to see both logs and PCAP traces attached. I cannot say anything without knowing what is actually happening on your side, > My setup : my B200( or my B210) with GPSDO is connected trough > a commercial duplexer for the appropriate GSM band (E-GSM) > and a omnidirectional antenna. I am also using B200, but without GPSDO. Probably, your device has different delays, which causes out of sync with BTS TDMA. Piotr Krysik was working on this part, and we had an idea to implement a tool for automatical device calibration... But let's look at your logs first. > Are you able to connect the mobile app using osmocom TRX to > a network (even a test network without ciphering) ? especially > using the latest version of libosmocore/ osmocom fixeria/trx branch ? Mostly, I am working in the virtual environment - FakeTRX. Didn't try since 34c3, but it was working. With best regards, Vadim Yanitskiy.

2 1

GSM 04.08 L2 pseudo length in ACCH System Information messages
by Vadim Yanitskiy 12 Mar '18

12 Mar '18

Hi everyone, I few days ago, during some usual R&D process, I noticed the following messages, appearing in the log output of OsmocomBB/mobile application: "ACCH message type 0xXX unknown." The network, a phone was connected to, was may own and based on more or less recent versions of OsmoNiTB, OsmoBTS, and OsmoTRX. Despite I used to see such messages before, I didn't pay too much attention. But this time I've decided to figure out, what's wrong there... The source of such messages is the gsm48_rr.c / gsm48_rr_rx_acch(): static int gsm48_rr_rx_acch(struct osmocom_ms *ms, struct msgb *msg) { // ... struct gsm48_system_information_type_header *sih = msgb_l3(msg); // ... switch (sih->system_information) { case GSM48_MT_RR_SYSINFO_5: return gsm48_rr_rx_sysinfo5(ms, msg); case GSM48_MT_RR_SYSINFO_5bis: return gsm48_rr_rx_sysinfo5bis(ms, msg); case GSM48_MT_RR_SYSINFO_5ter: return gsm48_rr_rx_sysinfo5ter(ms, msg); case GSM48_MT_RR_SYSINFO_6: return gsm48_rr_rx_sysinfo6(ms, msg); default: LOGP(DRR, LOGL_NOTICE, "ACCH message type 0x%02x unknown.\n", sih->system_information); return -EINVAL; } } To get I bit more details, I modified this function to print the whole L3 payload, and got some interesting results. As it turned out, the payloads were shifted one byte left - there was no 'l2_plen', which is assumed by: /* Section 9.1.3x System information Type header */ struct gsm48_system_information_type_header { uint8_t l2_plen; uint8_t rr_protocol_discriminator :4, skip_indicator:4; uint8_t system_information; } __attribute__ ((packed)); So, my first idea was that this is a bug of OsmocomBB, that would be fairly easy to fix, so after a quick look at the GSM 04.08 specification I wrote (and merged :/) this: https://gerrit.osmocom.org/#/c/5204/ And everything was great, until I connected a 'patched' mobile to a commercial mobile network... And all SI messages during a dedicated connection were false-identified as SI5ter. This seemed strange to me, so I decided to compare a SI message from commercial network with a message captured in my own one: https://habrastorage.org/webt/t8/zs/vv/t8zsvvjjglzfisnjqlnnsy4kgas.png And this confused me even more, then I've expected. Why there is 0x49? Wireshark false-identified this message as something related to SMS... What if this is exactly the 'l2_plen' assumed in OsmocomBB before? I looked at the specifications again, and found out that initially I refered an outdated 5.3.0 version, which was the first link in Google: http://www.etsi.org/deliver/etsi_gts/04/0408/05.03.00_60/gsmts_0408v050300p… while the latest one is 7.21.0: http://www.etsi.org/deliver/etsi_ts/100900_100999/100940/07.21.00_60/ts_100… So, I compared the 9.1.37-40 sections of both versions, and bingo! In the higher version ACCH System Information messages do have the 'L2 Pseudo Length' (10.5.2.19) field. Finally, what I've learned: - OsmocomBB / mobile follows the new version here (with l2_plen); - OsmoNiTB generates the ACCH SI messages without the l2_plen; - Recent Wireshark versions fail to decode the ACCH SI messages with l2_plen, while older ones are able to do that; - I should not merge the changes so quick. My questions are: - Which way of composing the SI messages is correct? - If both are correct, how to parse them correctly? - Should we change OsmoNiTB / OsmoBSC to follow the latest specs? And of course, I have to revert the change I've merged. With best regards, Vadim Yanitskiy.

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel March 2018