baseband-devel March 2017

baseband-devel@lists.osmocom.org

12 participants
14 discussions

Start a nNew thread

Engagetted !

by Sébastien Lorquet

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

6 months

Calypso BTS

by phreaker1983

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.

4 years, 5 months

OpenBTS OsmocomBB Asterisk

by trixbox.t

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.

5 years, 9 months

Osmocombb as a Zombie

by Duarte

Hey guys, first of all I want to express my deep respect for this project, this is truly amazing project and very well developed. Second, I'm doing a few studies regarding GSM security (no, I'm not hacking.) and I need to develop a feature for osmocombb, which is: the ability to turn the L23 app as a zombie (C unix domain socket) waiting for instructions (e.g.: connect to the network with predefined parameters (IMSI), collect RAND, send sms,...). Is there any documentation or flow regarding the code? It's very hard for a non C coder to follow the flow... Or is there someone that can help me in the Architectural level? Thank you.

6 years, 10 months

Re: Connecting OsmocomBB to OpenBTS

by Vadim Yanitskiy

Hi, > I'm guessing I would need to perform surgery on OSMOCOM-BB code in order to > connect it to another network? Is there any in built feature that would > allow me to do so directly? As I understand, you want to connect the network you running yourself on OpenBTS. There are two modes of network selection: manual and automatic (when MCC/MNC from SIM card are used). Have a look at the 'network-selection-mode' in your config file (~/.osmocom/bb/mobile.cfg). Also, have a look at the 'network' command in VTY. You can also create a virtual SIM card in your ~/.osmocom/bb/mobile.cfg (look at the 'test-sim' section) with desired IMSI and RPLMN (001 / 01 by default). Then you will be able to attach one using the 'sim testcard 1'. With best regards, Vadim Yanitskiy.

7 years

Re: ARM Core and UI

by Vadim Yanitskiy

Hi Anton, Feel free to watch OsmocomBB related talks, such as: https://youtu.be/ihbRtTzc0NI https://youtu.be/H7rNKZdASBE You'll wind a lot of useful information. Good luck! With best regards, Vadim Yanitskiy.

7 years

OsmocomBB MNCC socket implementation without LCR

by Gerard Pinto

Greetings, I have been working with Layer23 stack of OsmocomBB since a couple of months. I decided to try MNCC socket interface without LCR (I'm aware there is an implementation embedded in LCR gsm-ms). I reverse engineered and wrote a simple C application taking mncc.h. Problem: I'm unable to make a call on live network, although it does channel allocation, ciphering etc. Flow: 1. Create MNCC struct and write on to the osmocomBB socket 2. OsmocomBB parses it well and request for channel, ciphering mode, init MM, sending SETUP etc works great. 3. However, in response to step.2 after sending SETUP it returns with (ms 1) Received 'RELEASE_COMPL' in CC state INITIATED. Why does it release CC? 4. I further debugged, the reason for release is in fn. gsm48_cc_rx_release_compl in (gsm8_cc.c) it says mncc-cause = *GSM48_IE_CAUSE*. with no description. I really don't know whats causing this issue. Any help would be much appreciated. Or It would be very kind if someone could guide me. My mncc socket create code: struct gsm_mncc *mncc; int i = 0; int call_ref = new_callref++; mncc = create_mncc(MNCC_SETUP_REQ, call_ref); if (!strncasecmp(number, "emerg", 5)) { printf("Make emergency call\n"); mncc->emergency = 1; } else { printf("make call to %s\n", number); mncc->fields |= MNCC_F_CALLED; if(number[0] == '+') { number++; mncc->called.type = 1; /*international*/ } else { mncc->called.type = 0; /*auto-unknown -prefix must be used*/ } mncc->called.plan = 1; strncpy(mncc->called.number, number, sizeof(mncc->called.number) - 1); printf("Calling number %s\n", mncc->called.number); /* bearer capability (mandatory) */ mncc->fields |= MNCC_F_BEARER_CAP; mncc->bearer_cap.coding = 0; mncc->bearer_cap.speech_ctm = 0; mncc->bearer_cap.radio = 3; /** Support TCH/H also*/ /** Supported rates **/ mncc->bearer_cap.speech_ver[i++] = 2; /* support full rate v2 */ mncc->bearer_cap.speech_ver[i++] = 0; /* support full rate v1 */ mncc->bearer_cap.speech_ver[i++] = 1; /* support half rate v2 */ mncc->bearer_cap.speech_ver[i] = -1; /* end of list */ /** END **/ mncc->bearer_cap.transfer = 0; mncc->bearer_cap.mode = 0; /* CC capabilities (optional) DTMF */ mncc->fields |= MNCC_F_CCCAP; mncc->cccap.dtmf = 1; mncc->fields |= MNCC_F_CCCAP; mncc->clir.inv = 1; mncc->clir.sup = 1; } return send_and_free_mncc(mncc->msg_type, mncc); Looking forward to the reply, Thanks, Gerard -- View this message in context: http://baseband-devel.722152.n3.nabble.com/OsmocomBB-MNCC-socket-implementa… Sent from the baseband-devel mailing list archive at Nabble.com.

7 years

ARM Core and UI

by Anton Gorbachev

Dear Osmocom members, I am new in OsmocomBB but trying to understand how all the stuff works. And I have a question. As I understood we have DigitalBB Calypso in our Motorola phones which consist of DSP and ARM Cores. If we are talking about "normal" phone firmware, In DSP L1 processing is done, in ARM core L2 and L3 processing of GSM stack is done. But we must also have some "regular" OS somewhere, am I right? So I mean all the menus, applications like "Settings", "Phone book", etc. In modern phones, I believe Adnroid or iOS communicate with some RTOS running in ARM core of DigitalBB. But what is about Motorola phone? Does it have separate ARM processor/RAM for a refular firmware? Did you create some applications for ARM part of DigitalBB and some applications for UI which run outside the RTOS? It's possible that I am confusing with all the terms but I would appreciate if you help me to understand. Kind regards, Anton

7 years

Connecting OSMOCOM to OpenBTS

by Usama Muneeb

I recently set up OpenBTS which is working perfectly. I can make a test call by calling 2600 using an Android phone. However when I try "show subscriber" in OSMOCOM, various BTS are listed, with their MNC and MCC values but OpenBTS is not listed. Any solution to this? P.S. I've determined the MNC and MCC values for OpenBTS which are 001 and 01 respectively.

7 years

git.osmocom.org cgit improvements

by Harald Welte

Hi all, today I've deployed some cgit improvements on https://git.osmocom.org/, in the hope that it makes this tool even more useful: 1) syntax highlighting of source code (requested by Hoernchen) The source code is now highlighted by pygments. I don't really understand why somebody would want to look at source code a lot in a browser, but well, it was as easy as to enable the existing pygments based filter plugin. 2) rendering of "about" page from README.md As you might have noticed, I've introduced a README.md in a number of repositoires, and cgit is now rendering an about page for every repository, e.g. at http://git.osmocom.org/libosmo-abis/about/ 3) gerrit change-ID hyperlink generation All gerrit Change-IDs in commit messages are now automatically converted to hyperlinks to the respective gerrit change, see e.g. the below example: http://git.osmocom.org/openbsc/commit/?id=6dd0fc685b7149f67a5fe17a5bce55c44… Please note that this works for the "Change-Id" line of the actual change, but also for change-ids in the free text (e.g. "this depends on change-id ... in libosmocore") 4) Osmocom ticket/issue hyperlink generation Any Line that matches the "^((Relate|Close|Fixe)[ds]):" prefix is scanned for occurrences of "OS#(\d+)" which are then amended with hyperlinks to the respective issue on osmocom.org Please note the OS# prefix is mandatory, so things like "OS#1614, 1615" will not work, as can be seen at http://git.osmocom.org/osmo-pcu/commit/?id=0a8fae8d141c2cfa4387ffe9b35402d5… Please format your commit messages accordingly. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

7 years

Complexity of emergency-only baseband development

by Denver Gingerich

Hi everyone, I'm building some FOSS tools that let people send/receive calls/SMS without a cell plan (mainly using VoIP carriers that also offer SMS/MMS). Eventually I would like to be able to bundle these tools with a phone that runs only free software. In order to still provide standard emergency calling features (112/999/911 calling/SMS), the phone would require a free baseband (like OsmocomBB), but it would not need to offer any non-emergency phone features, since those would be handled by the aforementioned FOSS tools primarily on wifi. As I understand it, OsmocomBB can currently be run on certain Calypso-based phones, but does require a larger computer be connected to run part of the baseband. If one were to only require emergency calling features in OsmocomBB, would that larger computer still be required? If so, would developing the remaining pieces needed to run directly on the phone be substantially easier for an emergency-only use case than for a complete all-purpose use case? I'm guessing that there are certain parts of OsmocomBB that would not be required for emergency-only operation (perhaps some of the SIM card communication, for example), but I haven't written baseband software before so I don't have a good sense of how large the differences would be. So I'd be curious to know if the emergency-only use case is substantially easier to develop for, or if it's roughly the same complexity as developing for the all-purpose use case, or somewhere in between. My apologies if this isn't the right list for such questions; I'm happy to post elsewhere if that is more appropriate. Thanks for reading! Denver http://soprani.ca/

7 years, 1 month

Quectel modem documentation etc

by Fisher Grubb

Hi all, I know of some publicly available documentation and tools. I assume you have it, let me know if you don't and I'll post links. I downloaded it last year for UC20 (124MB zip file),and EC21 (60MB zip file). Fisher

7 years, 1 month

SMS not received in mobile - Virtual layer1 (osmo-nitb + osmo-bts + osmocom-bb/mobile)

by Sebastian Stumpf

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

7 years, 1 month

Re: Virtual layer 1 - Questions

by Harald Welte

Hi Sebastian, On Sun, Feb 12, 2017 at 02:29:05PM +0100, Sebastian Stumpf wrote: > The virtual layer 1 is currently in a state where the l23 app can > successfully connect to the bts and most of the signaling messages > will be forwarded and handled. TCH is not yet implemented. this is excellent news! Thanks for sticking with this and pushing it forward. > - Trying to initiate a call via the mobile vty will result in > VTY: > call 1 123 > OsmocomBB# > % (MS 1) > % Call has been rejected > call 1 123 > OsmocomBB# > % (MS 1) > % Call has been released > And no actual call setup message is transfered over the Um interface. > What could be reasons for that? I am using the test-sim option the > mobile app offers. I'm not sure if this is the root cause, but it seems there is some timeslot mis-matches in your traces. The Immediate Assignment contains TS 2 or TS 7, but I see Uplink frames for FACH on TS0, which is impossible (TS0 never has a channel combination with FACCH). Also, The uplink frames don't have the Uplink bit set in the GSMTAP header. This is a bit confusing, and I think it would be a good idea to introduce some consistency/invariant checking on both sides, i.e. the BTS should drop all non-uplink frames received, and the MS should drop all uplink frames received. I'm also surprised to see you're seeing an immediate assignment reject in downlink. This should only happen if all channels are allocated and the BTS is out of resources. Also, in your traces, there are typically several frames that are on the same timeslot in the same GSM frame number. This is not possible (probably related to the wrong TS above?). At maximum, there can be one L2 signalling message for a given TS + FN. Also, on the real radio interface a MAC block takes typically four frames on that channel, so the actual rate is lower. > - Occasionaly the T3210 timer is fired, which causes a new registering > within the network. well, it means that something got lost between MS and MSC for such a long time (between sending the LU REQ and receving a response) that the MS gives up. > LOG: > gsm48_mm.c:336 timer T3210 (loc. upd. timeout) has fired > How can i prevent that? The underlying problem must be resolved. On the simulated L1 you shouldn't loose messages, so this shouldn't happen if all messages arrive as expected on both sides. > - I did not implement a tdma or multiframe scheduler in the mobile > uplink as the logical channel is directly put to the gsmtap-header and > thus known by the bts. As Harald used a multiframe based scheduling > for the bts downlink, i wonder if this might be necessary, though. To > submit msgs with the correct frame number for example. It is primarily a question of how real the simulation should be. By using a multiframe scheduler one can make sure that the actual bandwidth/speed of GSM is maintained even over a virtual L1. Also, on the BTS side it must be present to schedule the BCCH (system information, ...) without which a MS would never even see the cell. I think one can do without on the MS side, but then the BTS must basically queue the incoming frames until the respective frame number indicated in the frame matches the current frame number. > - In my wireshark capture files, the gsmtap messages sent over the > multicast sockets are only recognized as UDP messages. I have to > "cast" them with the wireshark context menu "Decode as...". Why? This seems because you're using a non-standard port for the messages: In the capture I see UDP port 6666 rather than the IANA-registered port for GSMTAP which is 4729. > I would be super happy if someone of you could check out my project > (osmo-bts, branch stumpf/virt-phy + osmocom-bb, branch > stumpf/virt-phy) try to run it with the config files lying within the > project folders and tell me the problems they see :). I'll have a look, but not straight away now, sorry. > Here you can find a wireshark capture file of 2 mobiles connecting to > a virt bts. I also tried to init calls from both of them but the call > setup is not send. Already the LU is not working stable, so I think the first step is to stabilize this. You can see in packet 740 that the MS is sneding a LU Req, which the BTS forwards in frame 741 as RSL message to the NITB. The NITB then responds with an IDENTITY REQUEST which can be seen on RSL but which seems to disappear in the BTS without being ever sent on the virtual Um interface. As a result, the MS never sends the identity response, and the NITB will give up. I also see that the RACH requesets all are sent with a bogus frame number: 42. This will not work. The RACH request needs to be sent with the current frame number at the time being. Also, RACH retransmissions are happening way too quick. See Packets 600...644 where there are 7 RACH requests all within soemething like 10ms. The BTS then allocates 7 channels rather than one, ... So I think those lower-layer issues should be addressed before moving on to voice calls. Keep up the good work! Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

7 years, 1 month

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel March 2017