December 2017 - baseband-devel

Engagetted !

by Sébastien Lorquet

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

6 months, 1 week

5
5
0 0

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

6
13
0 0

Fwd: OSMOCOM-BB HandOver

by Muhammad Awais Aslam

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

5 years, 3 months

3
3
0 0

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

6
14
0 0

GSM 04.08 L2 pseudo length in ACCH System Information messages

by Vadim Yanitskiy

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.

6 years, 1 month

2
1
0 0

Use osmocombb and openbsc to do man-in-the-middle attacks

by 西电__张皓

Hello, I would like to use openbsc to do a fake base station and osmocombb to do an attack cell phone, to implement a man-in-the-middle attack. I have two questions: 1. How do I send location updates and authentication information between openbsc and osmocombb, 2. How to use imsi to initiate a location update thank you very much

6 years, 4 months

1
0
0 0

Libre baseband

by Marek Sebera

Hello everyone, Silly idea maybe, but would it be possible to port osmocom-bb for mediatek/intel/qualcomm BBP and replace the current firmware with open one? I presume it will be a tremendous amount of work, no doubts, but apart from that, is it theoretically and technically possible? Given root and/or hardware acces of course, we do not need to preserve the old firmware or exploit the update process (ie. if specific cert signature is needed for bbp-soc firmware update) Note that we do not have to be limited by existing software access to baseband, and we could use jtag/testpoints/wiring to access the BBP in a way that will be necessary, similar to way libreboot is currently being flashed. Thank you Marek Sebera

6 years, 4 months

3
6
0 0

help with burst_gen.py in faketrx

by Snehasish Kar

Hello I tried using burst_gen.py with grgsmtrx, as I can see in the screen, it shows that it has sent the burst to to grgsm trx, but I dont see any transmission from grgsm trx. Please help. Below are the logs of both burst_send.py and grgsm trx. Please let me know where I am going wrong. burst_gen.py ~/Downgrader/osmocom-bb-fixeria-trx/src/target/fake_trx$ python burst_gen.py -b NB -p 5700 -m TRX Copyright (C) 2017 by Vadim Yanitskiy <axilirator(a)gmail.com> License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. [i] Sending 1/1 NB burst (fn=1001550) to TRX... grgsm trx: ~/grgsmtrx_xenial/gr-gsm/apps$ sudo ./grgsm_trx Copyright (C) 2016-2017 by Vadim Yanitskiy <axilirator(a)gmail.com> License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. [i] Init Radio interface [INFO] [UHDlinux; GNU C++ version 4.8.4; Boost_105400; UHD_3.11.0.git-215-g3b206caa] [INFO] [NIRIO] rpc_client stopping... [INFO] [NIRIO] rpc_client stopped. [INFO] [NIRIO] rpc_client stopping... [INFO] [NIRIO] rpc_client stopped. [INFO] [X300] X300 initialization sequence... [INFO] [X300] Connecting to niusrpriorpc at localhost:5444... [INFO] [NIRIO] rpc_client stopping... [INFO] [NIRIO] rpc_client stopped. [INFO] [X300] Using LVBITX bitfile /usr/local/share/uhd/images/usrp_x310_fpga_HG.lvbitx... [INFO] [NIRIO] rpc_client stopping... [INFO] [NIRIO] rpc_client stopped. [INFO] [X300] Setup basic communication... [INFO] [X300] Loading values from EEPROM... [INFO] [X300] Setup RF frontend clocking... [INFO] [X300] Radio 1x clock:200 [INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 0... [INFO] [DEBUG] [DMA FIFO] Clock rate for BIST calculation: 0 [INFO] [RFNOC] pass (Throughput: 0.0MB/s) [INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 1... [INFO] [DEBUG] [DMA FIFO] Clock rate for BIST calculation: 0 [INFO] [RFNOC] pass (Throughput: 0.0MB/s) [INFO] [RFNOC RADIO] Register loopback test passed [INFO] [RFNOC RADIO] Register loopback test passed [INFO] [RFNOC RADIO] Register loopback test passed [INFO] [RFNOC RADIO] Register loopback test passed [INFO] [CORES] Performing timer loopback test... [INFO] [CORES] Timer loopback test passed [INFO] [CORES] Performing timer loopback test... [INFO] [CORES] Timer loopback test passed [WARNING] [MULTI_USRP] The hardware does not support the requested RX sample rate: Target sample rate: 1.083333 MSps Actual sample rate: 1.086957 MSps [INFO] [NIRIO] rpc_client stopping... [INFO] [NIRIO] rpc_client stopped. [INFO] [NIRIO] rpc_client stopping... [INFO] [NIRIO] rpc_client stopped. [WARNING] [MULTI_USRP] The hardware does not support the requested TX sample rate: Target sample rate: 1.083333 MSps Actual sample rate: 1.086957 MSps [i] Init CTRL interface [i] Init complete BR Snehasish

6 years, 4 months

1
0
0 0

Re: Tx support in MS with a virtual SIM

by Vadim Yanitskiy

Hi Ravi, > Can we make usrp to behave like a normal MS with parameters > of SIM in "test sim" feature from telnet. I am not using any > real SIM or writer. Yes, it's possible to use the virtual SIM-card, and this is exactly what we are doing during the SDR PHY development. Check out this example from FakeTRX: https://osmocom.org/projects/baseband/wiki/FakeTRX#Running-mobile-applicati… > As we pass the make command as " make nofirmware" from osmocombb/src > directory after enabling the " CFLAGS += -DCONFIG_TX_ENABLE " in > osmocom-bb/src/target/firmware, will it still be able to transmit ? No need to change the 'CONFIG_TX_ENABLE'. This affects only the firmware for Calypso based hardware. With best regards, Vadim Yanitskiy.

6 years, 4 months

1
0
0 0

Tx support in MS with a virtual SIM

by Ravi Shankar

Hello Community Can we make usrp to behave like a normal MS with parameters of SIM in "test sim" feature from telnet. I am not using any real SIM or writer. As we pass the make command as " make nofirmware" from osmocombb/src directory after enabling the " CFLAGS += -DCONFIG_TX_ENABLE " in osmocom-bb/src/target/firmware, will it still be able to transmit ? -- Best Regards. Ravi

6 years, 4 months

1
0
0 0

Re: [PATCH] mtk: fix firmware makefile to work with current osmocom-bb makefile system

by Vadim Yanitskiy

Hi Craig, Could you please provide a bit more detailed description of the change you've sent: what was wrong and what this change is intended to fix, so I'll push it to gerrit. Thanks! With best regards, Vadim Yanitskiy.

6 years, 4 months

2
4
0 0

Re: Classmark Testing

by Vadim Yanitskiy

Hi, > While transmitting the classmark or any message from mobile on > SDCCH during a call, does it transmit on the frequency we get > after converting the ARFCN or is there a slight variation ? I don't get this, what do you mean by 'converting the ARFCN'? There are two (as I know) possible types of call assignment: - Early Assignment, when the network allocates TCH/F or TCH/H right after getting RACH-request from a mobile phone. The frequency (or a set of them) is indicated in the Immediate Assignment message. - Late Assignment, when the network allocates an SDCCH channel first, where a mobile phone indicates a connection reason (Paging Response or Service Request) and also indicates the classmark. Then the network eventually sends the Assignment Command message, where just like in Immediate Assignment a new channel data (both FDMA and TDMA) are described. BTW: please choose a proper subject for this thread and don't interfere with the existing one because they are unrelated. With best regards, Vadim Yanitskiy.

6 years, 4 months

1
0
0 0

TX SUPPORT

by Felix Angga

Hi, I already uncomment the tx support in Makefile file. But when I run on phone, it said this firmware was compiled without tx support. How to fix this?

6 years, 4 months

2
2
0 0

OsmoDevCon 2018 schedule planning

by Harald Welte

Dear Osmocom Community, [please respect the Reply-To and post all follow-up discussion to this to openbsc(a)lists.osmocom.org, so we avoid having long threads cross-posted to several mailing lists.] Like every year in early December, it is time to discuss as schedule for OsmoDevCon in the upcoming year. Note: Ths is about OsmoDevCon, the more private meeting of developers, *NOT* about OsmoCon, the public conference. == When, Who, Where == I propose the following date for OsmoDevCon 2018: April 20 - April 23rd, 2018 * Who: Active developers/contributors of Osmocom projects (as usual) * Where: IN-Berlin, Berlin (as usual) Please let me know ASAP if that proposed date works for everyone who'd want to attend. We can still change it now, but I would want to nail down the date pretty soon. == Format == After the experiment of reducing from 4 to 3 days last year (due to OsmoCon), we will again go for *four days* in 2018. However, we should clearly divide the days in a way that e.g. "GSM/3G" topics are on two days, while SDR+Other topics are on the other days, so people not interested in some topics can skip one or two days, as needed. We could even divide it further like: * 1 day 3GPP RAN (osmo-bts, osmo-bsc, osmo-pcu, virt_phy, fake_trx, ...) * 1 day 3GPP CN (osmo-msc, osmo-hlr, osmo-sip-connector, nextepc, etc.) * 2 days misc Regards, and looking forward to meeting you [again] in 2018, 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)

6 years, 4 months

1
1
0 0

Re: Classmark Testing

by Vadim Yanitskiy

Hi Sebastian, > My query is : my test network is supporting A5/1,2,3. Is it feasible to > set A5/1 on MS1 (though it supports A5/2 and A5/3 also) and A5/2 for MS2 > (though it supports A5/1 and A5/3 also) for a call in between them using > "Early Classmark Sending" ??? I think it will work without any problems because the A5/X encryption is not 'end-to-end' (in our case MS-to-MS), but there are two separate encrypted sessions between MS1-BTS and MS2-BTS. With best regards, Vadim Yanitskiy.

6 years, 4 months

2
1
0 0

Classmark Testing

by f12.sebastian

Hi I am trying to test osmocom-bb/fixeria-Trx. After configuring test-sim the functions for receiver side like the " network selection mode " " select ARFCN" do work. But how to test or configure " Early Classmark Sending" for varying set of encryption (A5/1,2,3,4...). Regards. --

6 years, 4 months

4
4
0 0

Re: Classmark Testing

by Vadim Yanitskiy

Hi Max, This work is a part of "GSM and GPRS Security Using OsmocomBB" thesis written by Francois Ponsgen and was published a quite time ago. Moreover, I already have the changes in my local repo, which is mostly used for research purposes. I can push them, if it's really required. BTW: if I remember correctly, this work was done in NTNU ;) With best regards, Vadim Yanitskiy.

6 years, 4 months

2
1
0 0

[PATCH] mtk: fix firmware makefile to work with current osmocom-bb makefile system

by Craig Comstock

--- src/target/firmware/Makefile.mtk | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/src/target/firmware/Makefile.mtk b/src/target/firmware/Makefile.mtk index 30fa2fcf..927e31a0 100644 --- a/src/target/firmware/Makefile.mtk +++ b/src/target/firmware/Makefile.mtk @@ -4,14 +4,16 @@ BOARDS?=mt62xx # List of all applications (meant to be overridden on command line) APPLICATIONS?=loader_mtk -mtkram_LDS=board/mediatek/ram.lds -mtkram_OBJS=board/mediatek/start.ram.o +APP_loader_mtk_ENVIRONMENTS=mtkram + +ENV_mtkram_LDS=board/mediatek/ram.lds +ENV_mtkram_OBJS=board/mediatek/start.ram.o mtk_COMMON_OBJS=board/mediatek/uart.o # Mediatek MT62xx -mt62xx_OBJS=$(mtk_COMMON_OBJS) board/mt62xx/init.o -mt62xx_ENVIRONMENTS=mtkram +BOARD_mt62xx_OBJS=$(mtk_COMMON_OBJS) board/mt62xx/init.o +BOARD_mt62xx_ENVIRONMENTS=mtkram # Global include path INCLUDES=-Iinclude/ -I../../../include -I../../shared/libosmocore/include -- 2.15.0

6 years, 4 months

1
0
0 0

GAPK status update

by Vadim Yanitskiy

Dear Osmocom community, I have been working on GAPK (GSM Audio Packet Knife) for some time, and now I would like to share some achievements. Previously GAPK was represented as a single binary that could be called with some command line arguments in order to perform required operations. This is only handy for humans, but not for other programs, which may also need to perform some format / codec conversations or audio capture / playback. One of such programs is the mobile from OsmocomBB project. Currently, when you're making a voice call, both audio capture and playback are only possible on the L1 side, i.e. on a Calypso based phone. Of course, the audio stream can be redirected via MNCC socket, but this is not what a regular OsmocomBB user would like to do. Moreover, there is a lack of AMR codec support. Also, there is another GNURadio based project named GR-GSM. In short, this is a set of blocks for GSM signal reception, demodulation and further processing. At the moment, one has TCH Full Rate decoding capabilities only. Audio playback is not supported yet. Having these projects in my mind, I have got an idea of creating a shared library from the GAPK source code. And, a few days ago I was managed to get the audio playback working in OsmocomBB. I hope, this library will be also usable for other projects. Brief list of changes were made: - Composed a shared library named libosmogapk - All exposed symbols have got an 'osmo_gapk' prefix - Added a pkg-config manifest and a symbol export map - Integrated the Osmocom logging framework - Benchmarking is now disabled by default - Processing queue now based on the linuxlist - Fixed program exit due to ALSA buffer underrun - Fixed ALSA audio playback from file - Old gapk application was renamed to 'osmo-gapk' and linked against the library - Adjusted verbosity level (normal / debug) - Fixed I/O combinations (ALSA, RTP, file...) check All changes could be found at the fixeria/lib branch of GAPK. I hope to see them merged, and open for discussions ;) With best regards, Vadim Yanitskiy.

6 years, 4 months

2
4
0 0

Osmocon failed to flash

by felangga＠gmail.com

Hello, I'm newbie and want to learn about osmocombb. I already compiled all of the programs, but when I try to upload helloworld program, it stuck on this error $ host/osmocon/osmocon -p /dev/ttyUSB0 -m c123xor target/firmware/board/ compal_e88/hello_world.compalram.bin -c got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: f7 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 72 r got 2 bytes from modem, data looks like: 82 bf .. got 1 bytes from modem, data looks like: 7d } got 1 bytes from modem, data looks like: fd . got 1 bytes from modem, data looks like: 7f . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: a6 . got 1 bytes from modem, data looks like: 51 Q got 1 bytes from modem, data looks like: d2 . got 1 bytes from modem, data looks like: 51 Q got 1 bytes from modem, data looks like: 0a . got 1 bytes from modem, data looks like: 3a : got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 4d M got 1 bytes from modem, data looks like: a3 . got 1 bytes from modem, data looks like: a3 . got 1 bytes from modem, data looks like: da . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . I don't know if it hardware problem, or software problem. When I try to debug using putty to listen to /dev/ttyUSB0 there is no fmttool erro just like this article said http://www.linuxx.eu/2014/09/osmocombb-hardware-and-software-setup.html Regards.

6 years, 4 months

5
6
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel December 2017