- baseband-devel - lists.osmocom.org

Anyone interested in broken C118s?
by Holger Hans Peter Freyther 24 Feb '13

24 Feb '13

Hi, I have about 8 broken C118 and wonder if someone would be interested to save them from the recycling system. The defects vary but in some cases it is a broken buzzer, issues with the SIM card holder, missing or broken audio socket. This will just be the phone, no battery, no charger. I would like to get rid of them in batches of two. Is anyone interested? The postage should be paid by the receiver. cheers holger

1 0

is the Viterbi decode for the AFS provided by Sylvain right?
by bob 23 Feb '13

23 Feb '13

Hi ,List: search some materials, find that the decode method of AFS convolutional code is different from the EFS`, it use RSC, and need SOVA(soft output viterbi algorithm). am i right? -- View this message in context: http://baseband-devel.722152.n3.nabble.com/is-the-Viterbi-decode-for-the-AF… Sent from the baseband-devel mailing list archive at Nabble.com.

4 7

Trouble in making CALL
by cris crazy 21 Feb '13

21 Feb '13

Hi all, I am facing an error while trying to make a call from vty here is my mobile.cfg output ! ! OsmocomBB () configuration saved from vty !! ! line vty no login ! gps device /dev/ttyACM0 gps baudrate default gps enable ! no hide-default ! ms 1 layer2-socket /tmp/osmocom_l2 sap-socket /tmp/osmocom_sap sim reader network-selection-mode auto imei 415239521974659 0 imei-random 15 no emergency-imsi no sms-service-center no call-waiting no auto-answer no force-rekey clip no clir tx-power auto no simulated-delay no stick location-updating neighbour-measurement codec full-speed prefer codec half-speed no abbrev support sms a5/1 a5/2 p-gsm e-gsm r-gsm no gsm-850 dcs no pcs class-900 4 class-850 4 class-dcs 1 class-pcs 1 channel-capability sdcch+tchf+tchh full-speech-v1 full-speech-v2 half-speech-v1 min-rxlev -100 dsc-max 90 no skip-max-per-band exit test-sim imsi 001010000000000 ki xor 00 00 00 00 00 00 00 00 00 00 00 00 no barred-access no rplmn hplmn-search foreign-country exit no shutdown exit ! the debbuging output is <0009> mnccms.c:570 Make call to 123456789 <0009> mnccms.c:150 support TCH/H also <0009> mnccms.c:174 support full rate v2 <0009> mnccms.c:178 support full rate v1 <0009> mnccms.c:187 support half rate v1 <0006> transaction.c:76 ms 1 allocates transaction (proto 3 trans_id 255 callref 1 mem 0xf408d0) <0006> gsm48_cc.c:243 new state NULL -> MM_CONNECTION_PEND <0006> gsm48_cc.c:507 Sending MMCC_EST_REQ <0005> gsm48_mm.c:3783 (ms 1) Received 'MMCC_EST_REQ' event in state MM idle <0005> gsm48_mm.c:3786 -> substate PLMN search <0005> gsm48_mm.c:3788 -> callref 1, transaction_id 255 <0005> gsm48_mm.c:3051 Init MM Connection, not in normal state. <0006> gsm48_cc.c:2161 (ms 1) Received 'MMCC_REL_IND' in CC state MM_CONNECTION_PEND <0006> gsm48_cc.c:196 (ms 1 ti ff) Sending 'MNCC_REL_IND' to MNCC. <0006> gsm48_cc.c:243 new state MM_CONNECTION_PEND -> NULL <0006> transaction.c:104 ms 1 frees transaction (mem 0xf408d0) <0009> mnccms.c:372 Call has been released (cause 21) <0009> mnccms.c:71 (call 1) Call removed. and also my ms output from vty OsmocomBB> enable OsmocomBB# show ms MS '1' is up, service is limited IMEI: 418873812577882 IMEISV: 4188738125778820 IMEI generation: random (15 trailing digits) automatic network selection state: A0 null cell selection state: C0 null radio ressource layer state: idle mobility management layer state: MM idle, PLMN search OsmocomBB# show subsccriber 1 % Unknown command. OsmocomBB# show sub OsmocomBB# show subscriber 1 OsmocomBB# show subscriber 1 Mobile Subscriber of MS '1': IMSI: 405025012498239 ICCID: 89910255110124982391 Status: U1_UPDATED IMSI detached TMSI 0x1d315a07 LAI: MCC 405 MNC 025 LAC 0x42d8 (405, TATA DOCOMO) Key: sequence 2 a6 78 30 12 22 45 0b 03 Access barred cells: no Access classes: Kindly assist me with some suggestions. Regards, Cris

3 4

Can't get arm toolchain
by Alexander Schwankner 21 Feb '13

21 Feb '13

*Dear folks,* Recently I tried to compile osmocomBB on ubuntu 120.10 and arch linux. I always run into problems trying to get the arm toolchain. I can't reach gnuarch.com because it is down, nor get the paket from the ubuntu ppa because it is also down or corrupted. Is there any other source where I can get the arm toolchain or any howto wich could help me? Thanks :)

3 4

osmocombb and raspberry pi
by tom jerry 20 Feb '13

20 Feb '13

hi everyone.is it possible to connect motorola c118 to the raspberry GPIO pins,since they are 3v3 logic? What is the current limitation as the GPIO pins can provide only 8mA? Is it possible to use the lcd of the c118 or the RTC on the raspberry pi via the GPIO pins? Can i use the connection via the GPIO Instead of the pl2303 based cable. Thanks.

4 8

Can't get arm toolchain
by Alexander Schwankner 18 Feb '13

18 Feb '13

*Dear folks,* Recently I tried to compile osmocomBB on ubuntu 120.10 and arch linux. I always run into problems trying to get the arm toolchain. I can't reach gnuarch.com because it is down, nor get the paket from the ubuntu ppa because it is also down or corrupted. Is there any other source where I can get the arm toolchain or any howto wich could help me? Thanks :)

1 0

reference to TS 08.05
by Bhaskar11 16 Feb '13

16 Feb '13

The code for rxlev2dbm refers to TS 08.05 Chapter 8.1.4, but TS 08.05 is now marked as "withdrawn". Can you please point me to the correct reference for this? Thx.

2 1

OsmocomBB Mobile Call Setup Weird behaviour
by dagar 15 Feb '13

15 Feb '13

OK am testing the mobile app with C123 using real sim but getting some odd behaviour (have tested with main branch & sylvian testing branch and results have been similar to this) The results below are from using sylvian testing branch build as described here http://bb.osmocom.org/trac/wiki/SIMReader <http://bb.osmocom.org/trac/wiki/SIMReader> config tx is enabled etc I can download the layer1 firmware to the phone ok - mobile app seems to run ok aswell but when I try to make a call or sms this is where there's some odd behaviour . On my first attempt to make a call I can hear the call trying to be made but an automated message is played saying I have dialed an incorrect number (this normally happens if the number is dialed in an incorrect format) In previous attempts I have tried all the formats I can think of but have never been able to get a successful call to go through as of yet but if I dial it through the phone (without osmocom) normally everything works fine.. 07780000000 +447780000000 447780000000 00447780000000 Usually after the first call the phone then mysteriously deregisters from the network there is no service and when I restart osmocon/mobile etc I still cannot register on the network it just keeps scannning frequenceies and failing to connect with the network. On my first osmocon log when i managed to connect to the network after the call was released there were alot of DSP Error Status: 32 messages and then no service. I have gone through the logs but I still can't figure out why a) the call is failing to go through correctly b) why it seems like I get kicked of the network if I try to make a call Here are my full outputs 1ST ATTEMPT - MANAGED TO PLACE CALL THEN CONNECTION DROPPED Osmocon output - https://www.box.com/s/xdqi7azezprf4g7erz9h <https://www.box.com/s/xdqi7azezprf4g7erz9h> Mobile output - https://www.box.com/s/gqcdas9eqso0nchat011 <https://www.box.com/s/gqcdas9eqso0nchat011> Telnet output - https://www.box.com/s/lcazgabtmous0xheklmc <https://www.box.com/s/lcazgabtmous0xheklmc> 2ND ATTEMPT - FAILED TO CONNECT Osmocon output - https://www.box.com/s/c42vi7ows8p14h0hr45m <https://www.box.com/s/c42vi7ows8p14h0hr45m> Mobile output - https://www.box.com/s/eqygysqommur46ywgqrs <https://www.box.com/s/eqygysqommur46ywgqrs> Telnet output - https://www.box.com/s/kmympl0g0l8zb3xjyu8d <https://www.box.com/s/kmympl0g0l8zb3xjyu8d> 3RD ATTEMPT - FAILED TO CONNECT Osmocon output - https://www.box.com/s/gb9aw9p05pqy1v5fpxke <https://www.box.com/s/gb9aw9p05pqy1v5fpxke> Mobile output - https://www.box.com/s/llo751tuvvu1p5v31eur <https://www.box.com/s/llo751tuvvu1p5v31eur> Telnet output - https://www.box.com/s/t8e63lqrad87f35uylge <https://www.box.com/s/t8e63lqrad87f35uylge> Extract from telnet OsmocomBB# % (MS 1) % Trying to registering with network... % (MS 1) % On Network, normal service: Guernsey, T-Mobile show ms MS '1' is up, service is normal IMEI: 35972800609#### IMEISV: 359728006093#### IMEI generation: fixed automatic network selection state: A2 on PLMN MCC=234 MNC=30 (Guernsey, T-Mobile) cell selection state: C3 camped normally ARFCN=628(DCS) MCC=234 MNC=30 LAC=0x084f CELLID=0xf65d (Guernsey, T-Mobile) radio ressource layer state: idle mobility management layer state: MM idle, normal service OsmocomBB# call 1 +44772228#### OsmocomBB# % (MS 1) % Call has been released % (MS 1) % On Network, normal service: Guernsey, T-Mobile call 1 +44772228#### % (MS 1) % Searching network... show ms % (MS 1) % On Network, normal service: Guernsey, T-Mobile call 1 44772228#### OsmocomBB# % (MS 1) % Call is proceeding % (MS 1) % Call is alerting % (MS 1) % Call: Remote hangs up % (MS 1) % Trying to registering with network... % (MS 1) % Trying to registering with network... % (MS 1) % Searching network... % (MS 1) % No service. % (MS 1) % Power off! CALL SETUP EXTRACT FROM 1ST MOBILE APP OUTPUT -- View this message in context: http://baseband-devel.722152.n3.nabble.com/OsmocomBB-Mobile-Call-Setup-Weir… Sent from the baseband-devel mailing list archive at Nabble.com.

2 2

Sniffing to RACH
by Akib Sayyed 14 Feb '13

14 Feb '13

Hello list I am trying to sniff TS0 of BTS for purpose of sniffing RACH. but i am bit confused in this. i attached my code in mail. short description: 1. changed IMM_ASS to single RF and allow to jump as per IMM_ASS only once and no Hoppoing 2. while jumping to single RF imm ass used chan_nr=40 (40 & 7 =0) 3. added own function for decoding ccch. current problem able to decode PCH and AGCH properly but its slow in action. but if i use following modification in mframe_sched.c static const struct mframe_sched_item mf_ccch[] = { { .sched_set = SNIFF_QUAD_DL, .modulo = 51, .frame_nr = 6 }, { .sched_set = SNIFF_QUAD_UL, .modulo = 51, .frame_nr = 6 +15 }, { .sched_set = SNIFF_QUAD_DL, .modulo = 51, .frame_nr = 12}, { .sched_set = SNIFF_QUAD_UL, .modulo = 51, .frame_nr = 12 +15}, { .sched_set = SNIFF_QUAD_DL, .modulo = 51, .frame_nr = 16 }, { .sched_set = SNIFF_QUAD_UL, .modulo = 51, .frame_nr = 16 +15}, { .sched_set = SNIFF_QUAD_DL, .modulo = 51, .frame_nr = 22 }, { .sched_set = SNIFF_QUAD_UL, .modulo = 51, .frame_nr = 22 +15}, { .sched_set = SNIFF_QUAD_DL, .modulo = 51, .frame_nr = 26 }, { .sched_set = SNIFF_QUAD_UL, .modulo = 51, .frame_nr = 26+15 }, { .sched_set = SNIFF_QUAD_DL, .modulo = 51, .frame_nr = 32 }, { .sched_set = SNIFF_QUAD_UL, .modulo = 51, .frame_nr = 32 +15}, { .sched_set = SNIFF_QUAD_DL, .modulo = 51, .frame_nr = 36 }, { .sched_set = SNIFF_QUAD_UL, .modulo = 51, .frame_nr = 36 +15}, { .sched_set = SNIFF_QUAD_DL, .modulo = 51, .frame_nr = 42 }, { .sched_set = SNIFF_QUAD_UL, .modulo = 51, .frame_nr = 42 +15}, { .sched_set = SNIFF_QUAD_DL, .modulo = 51, .frame_nr = 46 }, { .sched_set = SNIFF_QUAD_UL, .modulo = 51, .frame_nr = 46 +15}, { .sched_set = NULL } }; it becomes very faster but I am not sure whether its correct or will give me correct out put. -- Akib Sayyed Matrix-Shell akibsayyed(a)gmail.com akibsayyed(a)matrixshell.com Mob:- +91-966-514-2243

1 0

Structure of traffic data in burst_ind messages
by Bhaskar11 12 Feb '13

12 Feb '13

I'm experimenting with burst-ind branch and am able to track control messages in ccch_scan. I then send an Assignment Command to change to a traffic channel. I can see the bursts come in, but cannot make out the format of the data. If I understand right, the burst_ind structure holds 15 bytes of data, but the traffic data should be 33 bytes. I assume the traffic data is spread across several burst-ind messages. Can you please clarify how to re-assemble the full 33-byte traffic data structure from the burst_ind messages? Thanks. B.

3 13

Problem with softbits in osmo_ubit2pbit()
by Bhaskar11 12 Feb '13

12 Feb '13

While playing with ccch_scan, I came across a strange problem. At some point the code uses: /* Convert to softbits */ for (i=0; i<116; i++) bursts[(116*bid)+i] = bt[i] ? - (bi->snr >> 1) : (bi->snr >> 1); After this, "xcch_decode()" works ok and "osmo_ubit2pbit_ext()" also works ok. But "osmo_ubit2pbit()" fails as it converts almost all softbits to 0xFF. Is this a bug or a "feature"? Do we need to recode "osmo_ubit2pbit" so that its bit-checking is more robust as in "osmo_ubit2pbit_ext"? Sylvain, can you explain the idea of using softbits instead of hard binary? Is it for GSMTAP to represent signal strength? Thanks in advance for your help. B

1 1

Interleave coding for TCH FS and HS
by Bhaskar11 12 Feb '13

12 Feb '13

While studying FS coding, I created the attached drawing. The code used for de-interleaving is: void tch_fr_deinterleave313(ubit_t *mC, int blockoffset) //see 3GPP TS 05.03 / 3.1.3 { for (int k = 0; k < 456; k++) { int B = ( k + blockoffset ) % 8; int j = 2 * ((49 * k) % 57) + ((k % 8) / 4); mC[k] = mI[B][j]; } } Now I want to study HS coding and de-interleaving. The GSM specs 05.03 / 3.2.3 only mentions a table for interleave coding and not a formula for matching j with k. Why is that? I tried to find a formula by looking a the table pattern, but it looks quite inconsistent. If there is no formula for coding/decoding HS, then do we have to use table lookup for each bit? Sounds very inefficient. Or am I missing something? B

1 0

C123 can't send DOWNLOAD ACK
by jet-lee 11 Feb '13

11 Feb '13

Hi, my problem is, that I can download the firmware on the motorola c123, but I can't send a DOWNLOAD ACK. The Firmware is on the Phone, because I see the "HELLO WORLD" example on the phone screen. I build my own "RS232-to-2.5mm"-Cable and I think it works.... Another thing is, at the end of the download I become permanently the INFO " got 1 bytes ...". Can anybody help me? (Sorry my english is very sad :( ) Here is the output: root@debian:./osmocon -p /dev/ttyS0 -d t -m c123xor ../../target/firmware/board/compal_e88/hello_world.compalram.bin got 2 bytes from modem, data looks like: 06 c1 .. got 5 bytes from modem, data looks like: 1b f6 02 00 41 ....A got 1 bytes from modem, data looks like: 01 . got 1 bytes from modem, data looks like: 40 @ Received PROMPT1 from phone, responding with CMD read_file(../../target/firmware/board/compal_e88/hello_world.compalram.bin): file_size=25108, hdr_len=4, dnload_len=25115 got 1 bytes from modem, data looks like: 1b . got 1 bytes from modem, data looks like: f6 . got 1 bytes from modem, data looks like: 02 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 41 A got 1 bytes from modem, data looks like: 02 . got 1 bytes from modem, data looks like: 43 C Received PROMPT2 from phone, starting download handle_write(): 4095 bytes (4095/25115) handle_write(): 3840 bytes (7935/25115) handle_write(): 3840 bytes (11775/25115) handle_write(): 3840 bytes (15615/25115) handle_write(): 3840 bytes (19455/25115) handle_write(): 3840 bytes (23295/25115) handle_write(): 1820 bytes (25115/25115) handle_write(): finished got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: ff . got 1 bytes from modem, data looks like: bf . got 1 bytes from modem, data looks like: ff . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: ff . got 1 bytes from modem, data looks like: ff . got 1 bytes from modem, data looks like: ff . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: dc . got 1 bytes from modem, data looks like: 98 . got 1 bytes from modem, data looks like: 9f . got 1 bytes from modem, data looks like: ff . got 1 bytes from modem, data looks like: 9f . ..... -- View this message in context: http://baseband-devel.722152.n3.nabble.com/C123-can-t-send-DOWNLOAD-ACK-tp4… Sent from the baseband-devel mailing list archive at Nabble.com.

2 1

Content of burst data in burst_ind branch
by Bhaskar11 05 Feb '13

05 Feb '13

Can you please clarify what kind of preprocessing has been done for bursts in burst_ind data? Does TCH/F data come through with block-diagonal de-interleaved? Or does come as 8 interleaved bursts? I think all the intra-burst de-interleaving has already been done at DSP level. Is this correct? B

3 2

Osmocom-BB compilation problem
by bharath seelam 05 Feb '13

05 Feb '13

Hi Everyone, When i tried to install the osmocombb for the first time which was a couple of days back i encountered with a problem and did some minor modification in the code. >gsm411_sms.c: In function ‘gsm411_tx_sms_submit’:>gsm411_sms.c:657: warning: passing argument 4 of ‘gsm411_smc_init’ from incompatible pointer type>/usr/local/include/osmocom/gsm/gsm0411_smc.h:46: note: expected ‘int (*)(struct gsm411_smc_inst *, int, struct msgb *, int)’ but argument is of type ‘int (*)(struct gsm411_smc_inst *, int, struct msgb *)’>gsm411_sms.c:657: error: too many arguments to function ‘gsm411_smc_init’>gsm411_sms.c:659: error: too many arguments to function ‘gsm411_smr_init’>gsm411_sms.c: In function ‘gsm411_rcv_sms’:>gsm411_sms.c:911: warning: passing argument 4 of ‘gsm411_smc_init’ from incompatible pointer type>/usr/local/include/osmocom/gsm/gsm0411_smc.h:46: note: expected ‘int (*)(struct gsm411_smc_inst *, int, struct msgb *, int)’ but argument is of type ‘int (*)(struct gsm411_smc_inst *, int, struct msgb *)’ by seeing this error i opened the respective file(gsm411_sms.c) in my local pc and i observed that the lines which was mentioned as error and find the below . gsm411_smc_init(&trans->sms.smc_inst, transaction_id, 0, gsm411_mn_recv, gsm411_mm_send); but in the header file (gsm0411_smc.h) only four arguments are defined void gsm411_smc_init(struct gsm411_smc_inst *inst, int network, int (*mn_recv) (struct gsm411_smc_inst *inst, int msg_type, struct msgb *msg), so i removed the extra argument transaction_id in the function(gsm411_smc_init) and also did the same with the respective lines where i was getting an error (from the file gsm411_sms.c). i have done a change like the below by assuming thatevery msg is a mobile originated mesage gsm411_smc_init(&trans->sms.smc_inst, transaction_id, 0, gsm411_mn_recv, gsm411_mm_send); Kindly assist me if i was doing wrong. Thanks in advance and Apologies if my observation was wrong. Regards,Bharath

2 1

Osmocom-BB compilation Problem
by bharath seelam 05 Feb '13

05 Feb '13

Hi Everyone, When i tried to install the osmocombb for the first time which was a couple of days back i encountered with a problem and did some minor modification in the code. >gsm411_sms.c: In function ‘gsm411_tx_sms_submit’: >gsm411_sms.c:657: warning: passing argument 4 of ‘gsm411_smc_init’ from incompatible pointer type >/usr/local/include/osmocom/gsm/gsm0411_smc.h:46: note: expected ‘int (*)(struct gsm411_smc_inst *, int, struct msgb *, int)’ but argument is of type ‘int (*)(struct gsm411_smc_inst *, int, struct msgb *)’ >gsm411_sms.c:657: error: too many arguments to function ‘gsm411_smc_init’ >gsm411_sms.c:659: error: too many arguments to function ‘gsm411_smr_init’ >gsm411_sms.c: In function ‘gsm411_rcv_sms’: >gsm411_sms.c:911: warning: passing argument 4 of ‘gsm411_smc_init’ from incompatible pointer type >/usr/local/include/osmocom/gsm/gsm0411_smc.h:46: note: expected ‘int (*)(struct gsm411_smc_inst *, int, struct msgb *, int)’ but argument is of type ‘int (*)(struct gsm411_smc_inst *, int, struct msgb *)’ by seeing this error i opened the respective file(gsm411_sms.c) in my local pc and i observed that the lines which was mentioned as error and find the below . gsm411_smc_init(&trans->sms.smc_inst, transaction_id, 0, gsm411_mn_recv, gsm411_mm_send); but in the header file (gsm0411_smc.h) only four arguments are defined void gsm411_smc_init(struct gsm411_smc_inst *inst, int network, int (*mn_recv) (struct gsm411_smc_inst *inst, int msg_type, struct msgb *msg), so i removed the extra argument transaction_id in the function(gsm411_smc_init) and also did the same with the respective lines where i was getting an error (from the file gsm411_sms.c). i have done a change like the below by assuming thatevery msg is a mobile originated mesage gsm411_smc_init(&trans->sms.smc_inst, transaction_id, 0, gsm411_mn_recv, gsm411_mm_send); Kindly assist me if i was doing wrong. Thanks in advance and Apologies if my observation was wrong. Regards, Bharath

1 0

Anyone tried this board
by ty 04 Feb '13

04 Feb '13

Came across this neat implementation. Havent had a chance to use it. Wanted to know if anyone has given it a try http://www.kickstarter.com/projects/1085541682/bladerf-usb-30-software-defi… -tyrus

1 0

windows pc tool
by shrek wu 02 Feb '13

02 Feb '13

hi burney help me to see ot best regards shrek wu

2 1

Problems about analysis of content in memory
by qiuhan1989 01 Feb '13

01 Feb '13

I tried to dump some parts of memory using osmoload. Here is my problem, When I tried to dump from 0x0, there is a piece of memory filled up with "f". I guess maybe it's ROM and when I call the memcpy in RAM, I actually cannot read things in ROM. Can anyone confirm my guess? Then I found there is a memory protection unit (ti-calypso2.pdf). Then I dumped the values from FFFF FF00 (registers of MPU), I got all zeros... Does this mean there is no memory protection active? Or maybe because actually the phone is not turned on. So there would be some flash which don't have electricity on... Anyone can help me? Thank you in advance. -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Problems-about-analysis-of-conte… Sent from the baseband-devel mailing list archive at Nabble.com.

1 0

Hardware replacement for uplink sniffing
by Roddy Ernest 31 Jan '13

31 Jan '13

Hello, I know that there is a hardware replacement kit that is available for Osmocombb phones that help make the phones be used as uplink sniffers, but unfortunately the kit uses components that operate in the European GSM bands. Are there any hardware replacement kits for Osmocombb phones that operate in the U.S. GSM frequency bands? Sincerely, Roderick Ernest

2 1

Decoding AMR
by Bhaskar11 31 Jan '13

31 Jan '13

I've been experimenting with decoding AMR in burst_ind with the following steps: 1. Ignore SACCH and UL frames 2. check for FACCH 3. check for CMI/CMR (only on specific frame numbers) and change codec if necessary after 12 frames 4. check for RATSCCH, if necessary change codec after 12 frames Can anyone confirm that this is the proper process? I've looked at Bob's code of July 2012. It does not use the above checks which may be the reason for its failure. B. ===================== From: bob <avwiseav <at> gmail.com> Subject: is my patch for capturing TCH frame correctly?<http://news.gmane.org/find-root.php?message_id=%3c1342688308441%2d4025199.p…> Newsgroups: gmane.comp.mobile.osmocom.baseband.devel<http://news.gmane.org/gmane.comp.mobile.osmocom.baseband.devel> Date: 2012-07-19 08:58:28 GMT (27 weeks, 6 days, 20 hours and 14 minutes ago) Hi, everyone interesting the topic, this is my latest patch for TCH decode, fix few bug; but it not work well for TCH AMR decode, welcome everyone interesting it to review it and modify it! the most problem now I think is the capture of the Correct TCH frame, at the last ,there is some output for analysis --- app_ccch_scan.c 2012-03-14 16:08:11.305112000 +0800 +++ new_app_ccch_scan.c 2012-07-19 15:32:31.945314000 +0800 <at> <at> -50,20 +50,80 <at> <at> #include <l1ctl_proto.h> #include <osmocom/bb/misc/xcch.h> +#include <codec.h> +#include "conv_tch_afs.h" +//#include "../openbtsstuff/GSML1FEC.h" +//extern bool TCHFACCHL1Decoder::processBurst( const RxBurst& inBurst); +//const struct osmo_conv_code conv_tch_afs_12_2; +extern FILE *log_tmsi; extern struct gsmtap_inst *gsmtap_inst; +FILE *d_speech_file; +const unsigned char amr_nb_magic[6] = { 0x23, 0x21, 0x41, 0x4d, 0x52, 0x0a }; +

1 0

Help with JTAG
by teslarode＠yahoo.com 31 Jan '13

31 Jan '13

Hello, I've found a very interesting article about SciphoneDream G2 published on your webpage at http://bb.osmocom.org/trac/wiki/SciphoneDreamG2 that covers pretty detailed information about MT6235 SoC, bootstrapping as well as JTAG. This is the only article I have ever found on internet about MTK SoC and JTAG. What I am trying to accomplish is to access NAND flash and write to it over JTAG (in order to recover from corruption after bad flash) on MTK8555 SoC which according to my in-depth research and analysis has very similar architecture to MT6235. If I can't write to NAND over JTAG but would be able to launch u-boot that would be a solution too. I am very good at ARM assembly and debugging, however I am not very experienced with JTAG. Do you think you (or anyone else) could help me out, by giving me guidance what hardware, software, config files should I use to make JTAG work on this SoC ? Any help or advise would be more then appreciated! If you are a wrong person I contacted, I apologize for the inconvenience. Many thanks in advance! Dwayne

2 1

Mistake in gsm_04_08.h channel mode definition
by Bhaskar11 30 Jan '13

30 Jan '13

In enum gsm48_chan_mode definitions we have: GSM48_CMODE_DATA_3k6 = 0x23, It should be 0x13 as in 3GPP TS 04.08 / 10.5.2.6. Please update in repository.

2 1

thanks for osmocom, my goals, available to test c139 & c115
by Craig Comstock 29 Jan '13

29 Jan '13

Hi, I have bought two phones... Motorola C139 and Motorola C115. I'm using the raspberry PI UART instead of a dedicated cable and got the hello world example working just fine on the C115. My goal is to have a usable open source phone which I see there is a bit of a start at in the source code. I've been working on getting debian on my Motorola Defy for a while and am making some progress. Since I have two phones... I am certainly willing to help in testing things. I can't promise a lot of time but I can hope to help a little. Thanks for your efforts, Craig Comstock Lawrence, KS

2 1

another method for filter rework
by Akib Sayyed 25 Jan '13

25 Jan '13

Dear sylvain I checked on your website you gave some other way of doing filter rework. I checked tried to check problem n checked possible shorts. but multi meter shows all part are shorted. also checked each components but it shows that there is direct connection in between all points of baluns. i would like to try other way for same -- Akib Sayyed Matrix-Shell akibsayyed(a)gmail.com akibsayyed(a)matrixshell.com Mob:- +91-966-514-2243

2 3

Dumping DSP
by Akib Sayyed 25 Jan '13

25 Jan '13

Dear list i see there is target_dsp firmware. as per readme found inside it dumps dsp data on console. but i am unable to compile. it needs tic54x-coff but couldnt find it. can any one guide me through this. -- Akib Sayyed Matrix-Shell akibsayyed(a)gmail.com akibsayyed(a)matrixshell.com Mob:- +91-966-514-2243

1 0

Implementing AMR Codec for Mobile App
by Akib Sayyed 25 Jan '13

25 Jan '13

Dear All Currently i am trying to implement AMR codec for Mobile App. Please guide me for same. I am not that good in channel decoding. if anyone have given a try or have partial code implementation please help me in that. -- Akib Sayyed Matrix-Shell akibsayyed(a)gmail.com akibsayyed(a)matrixshell.com Mob:- +91-966-514-2243

2 4

Some beginner questions and comments
by Klaus Darilion 25 Jan '13

25 Jan '13

Hi! First I do not know if this is the proper mailing lists, as I am not a developer but a user. But I couldn't find a user list. So please advice if there is a better list. I started playing with Osmocom and my "brand new" C118 :-) and meanwhile I made my first open source GSM phone call. Following is my list of questions and suggestions I experienced so far: - Build System: since the "Use the system wide libosmocore for host applications" commit it is required that libosmocore is built separately. But the documentation is still confusing. Thus I think it would be good to: - remove the libosmocore subtree git from osmocom-bb git - remove this line of text from http://bb.osmocom.org/trac/wiki/libosmocore: "When you download and build OsmocomBB, then libosmocore is automatically part of the package, no special action is required." - osmocom: some wiki pages refer to an "osmocom" application. Is there an osmocom binary? (I think most times it is a typo for osmocon) - I use Wireshark to capture the GSMTAP packets of "monitor". How do I find out in the Wireshark trace if a message is sent from the MS or is received by the MS? - I want to study the high layer messages (e.g. not cell selection but call setup, registering to the network) but I am lost in the debug flags: DCS:DNB:DPLMN:DRR:DMM:DSIM:DCC:DMNCC:DSS:DLSMS:DPAG:DSUM. Which ones are needed in my case? Is there somewhere a description of the flags? - Some tools (e.g. cell_log) give 'SAP' log messages, e.g: Failed to connect to '/tmp/osmocom_sap'. Failed during sap_open(), no SIM reader I suspect this is for communcation with SIM cards. How it is supposed to work? - Is this 'SAP' stuff only needed/useful for softSIMs? - Which application should create the /tmp/osmocom_sap socket? (osmocon only creates /tmp/osmocom_l2 and /tmp/osmocom_loader) - Would it be possible to remove the SIM card from my C118 and put it in an external SIM reader, and then let "mobile" use the SIM card in the external reader instead? Thanks Klaus PS: I'm willing to improve the documentation in the wiki with your answers ;-)

5 9

Need instructions
by Akib Sayyed 23 Jan '13

23 Jan '13

Dear All I need instructions for flashing c155 with custom firmware. also i need to build linker script too.what all changes need to be done in flash.lds for e88 hw. will changes in only address and size part will work ?? can any one help me ?? -- Akib Sayyed Matrix-Shell akibsayyed(a)gmail.com akibsayyed(a)matrixshell.com Mob:- +91-966-514-2243

1 0

slow osmocom website
by Klaus Darilion 22 Jan '13

22 Jan '13

Hi! The last days I experienced the website is sometimes very slow. Requests takes up to 30 seconds to be answered by the server. http://bb.osmocom.org/ is fast, but http://bb.osmocom.org/trac/ is slow. Thus I suspect a Trac or database problem. regards Klaus

8 11

strange crashes in current main branch
by Tim Ehlers 22 Jan '13

22 Jan '13

Hi, I already mentioned a strange behavior, sometimes when running osmocom for a few days. I think this is a different issue, because it happens more frequently and the situation is a bit different. This problem does not occur with a binary from june 2012. So it has to be some change between june and now. But now the problem: When running a phone with the main branch (only tested), it sometime come to the situation that the phone says "connection pending" and is not reacting anymore. osmocon only logs periodically this line: TOA AVG is not 16 qbits, correcting (got 15) And mobile says: <0003> gsm322.c:474 Sync to ARFCN=694(DCS) rxlev=-80 (No sysinfo yet, ccch mode NONE) <000e> gsm48_mm.c:353 Periodic location update <0005> gsm48_mm.c:355 timer T3212 (periodic loc. upd. delay) has fired <0005> gsm48_mm.c:4338 (ms 1) Received 'MM_EVENT_TIMEOUT_T3212' event in state MM IDLE, normal service <000e> gsm48_mm.c:2222 Perform location update (MCC 262, MNC 07 LAC 0x27e9) <0005> gsm48_mm.c:2356 LOCATION UPDATING REQUEST <0005> gsm48_mm.c:2378 using LAI (mcc 262 mnc 07 lac 0x27e9) <0005> gsm48_mm.c:2386 using TMSI 0xXXXXXXXX <0005> gsm48_mm.c:917 new state MM IDLE, normal service -> wait for RR connection (location updating) <0001> gsm48_rr.c:5575 (ms 1) Message 'RR_EST_REQ' received in state idle (sapi 0) <000e> gsm48_rr.c:1352 Establish radio link due to mobility management request <0003> gsm322.c:4049 (ms 1) Event 'EVENT_LEAVE_IDLE' for Cell selection in state 'C3 camped normally' <0003> gsm322.c:829 new state 'C3 camped normally' -> 'connected mode 1' <0003> gsm322.c:3665 Going to camping (normal) ARFCN 664(DCS). <0003> gsm322.c:452 Sync to ARFCN=664(DCS), but there is a sync already pending <0001> gsm48_rr.c:355 new state idle -> connection pending <0001> gsm48_rr.c:1504 CHANNEL REQUEST: 00 (Location Update no NECI) Mobile says nothing when shutting the phone off or on: OsmocomBB(ms)#shutdown OsmocomBB(ms)# OsmocomBB(ms)#no shutdown OsmocomBB(ms)# Only logs: <0005> gsm48_mm.c:4342 (ms 1) Received 'MM_EVENT_IMSI_DETACH' event in state wait for RR connection (location updating) <0005> gsm48_mm.c:1992 IMSI detach delayed. Killing and restarting mobile leads to: eeepc:~ # mobile -i 127.0.0.1 Copyright (C) 2008-2010 ... Contributions by ... 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. <000f> sim.c:1223 init SIM client <0006> gsm48_cc.c:63 init Call Control <0007> gsm480_ss.c:231 init SS <0017> gsm411_sms.c:63 init SMS <0001> gsm48_rr.c:5626 init Radio Ressource process <0005> gsm48_mm.c:1327 init Mobility Management process <0005> gsm48_mm.c:1040 Selecting PLMN SEARCH state, because no SIM. <0002> gsm322.c:5037 init PLMN process <0003> gsm322.c:5038 init Cell Selection process <0003> gsm322.c:5095 Read stored BA list (mcc=262 mnc=01 Germany, T-Mobile) <0003> gsm322.c:5095 Read stored BA list (mcc=262 mnc=07 Germany, O2) Mobile '1' initialized, please start phone now! VTY available on port 4247. And layer1 still logs some: TOA AVG is not 16 qbits, correcting (got 15) TOA AVG is not 16 qbits, correcting (got 15) TOA AVG is not 16 qbits, correcting (got 15) Has anybody a clue how this could happen from time to time? Cheers Tim

1 1

What's the difference between the hello_world.e88flash.bin and hello_world.compalram.bin
by qiuhan1989 21 Jan '13

21 Jan '13

As said in the topic, I don't know what is the difference between the two .bin file. And when I try the osmocon app, only the hello_world.compalram.bin works, why? Thanks in advance. -- View this message in context: http://baseband-devel.722152.n3.nabble.com/What-s-the-difference-between-th… Sent from the baseband-devel mailing list archive at Nabble.com.

3 3

sylvain/testing: apps/trx/trx.c: inttypes.h:No such file or directory
by Erich Dachleger 21 Jan '13

21 Jan '13

Hi list, Yesterday when I tried to to make a new build of sylvain/testing I encountered following errors when running make(and also when running make HOST_layer23_CONFARGS=--enable-transceiver): -------------------------------------- make -C target/firmware CROSS_COMPILE=arm-elf- make[1]: Entering directory `/root/osmocom-bb/src/target/firmware' apps/trx/trx.c:22:22: inttypes.h: No such file or directory make[1]: Leaving directory `/root/osmocom-bb/src/target/firmware' make[1]: Entering directory `/root/osmocom-bb/src/target/firmware' apps/trx/trx.c:22:22: inttypes.h: No such file or directory make[1]: *** No rule to make target `apps/trx/trx.p', needed by `all'. Stop. make[1]: Leaving directory `/root/osmocom-bb/src/target/firmware' make: *** [firmware] Error 2 ------------------------------------------- Master branch builds fine on backtrack 5 r2 and so did also Sylvain/testing earlier. Searching mailing-list gives some info that removing inttypes.h can be done as that "is taken care of by upstrean libosmocore".However I have read that inntypes.h should exist. I tested and removed inttypes.h in trx/trx.c. Recompiling gives an error message about parse error before debug-message PRIu32 on line 69 in trx/trx.c. Commenting out that line makes it build, but as info obtained earlier I now guess I have also removed some key-functionality and my approach is wrong? Further searching gave some unclear/vague(mostly for other situations) hints that the line #include <inttypes.h> could be replaced by: #ifdef HAVE_STDINT_H #include <stdint.h> #else #include <include <inttypes.h> #endif I tested replacing #include <inttypes.h> by the abovein trx.c also but it didn't work. Any ideas or hints what migh be wrong? Enclosed is the full build-error-log from running without making any changes to inttypes.h. Regards erich

2 4

Jan 23, 8pm / Osmocom Berlin User Group meeting
by Harald Welte 21 Jan '13

21 Jan '13

Hi all! This is the announcement for the latest incarnation of our bi-weekly Osmocom Berlin meeting. January 23, 8pm @ CCC Berlin, Marienstr. 11, 10113 Berlin There is no formal presentation scheduled for this meeting. However, we'll have a progress report + demonstration of current osmo-pcu. If you are interested to show up, feel free to do so. The meeting is free as in "free beer", despite no actual free beer being around ;) 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)

1 0

gsm450 in belgium
by g.roelant＠telenet.be 21 Jan '13

21 Jan '13

Hi, Does anyone know if gsm450 is encrypted with A5/1? and who is using gsm450 in belgium I can see signals on my ettus + external ant. there... kind regards

3 2

Filter Modification
by Akib Sayyed 18 Jan '13

18 Jan '13

Dear List I tried to modify filter of osmocom c118 but i found that its not getting signals. loosing all signalls and showing all on 115dbm to 120dbm. what could have gone wrong ?? -- Akib Sayyed Matrix-Shell akibsayyed(a)gmail.com akibsayyed(a)matrixshell.com Mob:- +91-966-514-2243

2 1

tranceiver support for osmo-bts
by Andreas Eversberg 18 Jan '13

18 Jan '13

hi, i would like to start implementing the trx manager interface support to osmo-bts. before going to work, i'm writing this mail, because i like to read some pros and cons for my approach. as already stated, thomas a. cooper already implemented an interface between sysmo-bts's dsp device and trx manager interface by using code from openbts, running in an own process [1]. i would like to follow a different approach by writing a scheduler and adding the udp interface for the trx(s). some benefits are in my oppinion: - not having an extra process running with additional latency and overhead - smaller code, because only a small multiframe scheduler + udp interface for the trx is required (coding scheme and forward error correction code can be used from libosmocore.) - no running after dsp's api changes, (caused by newer firmware of sysmobts) - trx specific features and limitations can be considered. (vty options for setting special features, limitations can affect oml ack/nack responses to be considered by bsc) - no use of multithreading, use of talloc. the code is easier to debug and so becomes more stable. - easy to add initial support for BCCH(+SDCCH4), SDCCH8, TCH/F, TCH/H, PDCH (gprs) for a whide range of applications. comments are welcome. regards, andreas [1] http://scholar.lib.vt.edu/theses/available/etd-05082012-141540/unrestricted…

3 4

drawing of state machines
by Andreas Eversberg 18 Jan '13

18 Jan '13

hi, while reading about SMS state machines, i found some drawings that are not in the specs, but quite useful to understand some processes. they are: - MM idle process (MS side) - additions to CC (MS side) - SMC process (MS and network side) see http://home.eversberg.eu/gsm they might be useful and so i think they should be placed in the wiki. i would suggest to put them to OsmocomBB wiki in the "GSM Documentation" section. but i don't know if it is ok to publish the CC process, because it contains a scan of the original spec. any suggestions? regards, andreas

5 8

[PATCH] Improve hex parser
by ☎ 15 Jan '13

15 Jan '13

Hello. Current implementation of osmo_hexparse have couple of limitations (which are undocumented btw): * it refuses to parse odd-length numbers (e. g. 7abdf) * it fails while parsing 0x prefix (e. g. 0xdead) Both could be worked around by upper-layer code of course but since both cases above are perfectly valid hexadecimal numbers I think they should be handled by osmo_hexparse internally without complicating life of library users. Attached patch does just that. Please review and merge if it feels OK. -- best regards, Max, http://fairwaves.ru

3 6

osmocombb: TS 3 -> TS failed
by jolly 14 Jan '13

14 Jan '13

hi, i just encountered the following problem: the network assigns me from TS 1 to TS 3 it worked, but not when it did another assigment from TS 3 to TS4. i just got noise instead of valid SACCH frames. TS Chg forth: 1 -> 3 | 1856 ... TS Chg forth: 3 -> 4 | 1875 this is the wireshark trace of both assignments. they only differ in the assigned slot: Frame 3225: 81 bytes on wire (648 bits), 81 bytes captured (648 bits) Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00) Internet Protocol Version 4, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1 (127.0.0.1) User Datagram Protocol, Src Port: 52261 (52261), Dst Port: gsmtap (4729) GSM TAP Header, ARFCN: 34 (Downlink), TS: 1, Channel: SDCCH/8 (0) Link Access Procedure, Channel Dm (LAPDm) GSM A-I/F DTAP - Assignment Command Protocol Discriminator: Radio Resources Management messages DTAP Radio Resources Management Message Type: Assignment Command (0x2e) Channel Description 2 - Description of the First Channel, after time 0000 1... = TCH/F + FACCH/F and SACCH/F .... .011 = Timeslot: 3 000. .... = Training Sequence: 0 ...1 .... = Hopping channel: Yes Hopping channel: MAIO 0 Hopping channel: HSN 0 Power Command 0... .... = Spare: 0 .0.. .... = EPC_mode: Channel(s) not in EPC mode ..0. .... = FPC_EPC: FPC not in use/C not in use for uplink power control ...0 0101 = POWER LEVEL: 5 Frequency List - Frequency List, after time Element ID: 5 Length: 16 00.. 000. = Format Identifier: bit map 0 (0x00) List of ARFCNs = 99 34 Channel Mode - Mode of the First Channel(Channel Set 1) Element ID: 99 Channel Mode: speech full rate or half rate version 2(GSM EFR) (33) No. Time Source Destination Protocol Info 3243 464.672890 127.0.0.1 127.0.0.1 LAPDm I, N(R)=1, N(S)=2(DTAP) (RR) Assignment Command Frame 3243: 81 bytes on wire (648 bits), 81 bytes captured (648 bits) Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00) Internet Protocol Version 4, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1 (127.0.0.1) User Datagram Protocol, Src Port: 52261 (52261), Dst Port: gsmtap (4729) GSM TAP Header, ARFCN: 99 (Downlink), TS: 3, Channel: FACCH/F (0) Link Access Procedure, Channel Dm (LAPDm) GSM A-I/F DTAP - Assignment Command Protocol Discriminator: Radio Resources Management messages DTAP Radio Resources Management Message Type: Assignment Command (0x2e) Channel Description 2 - Description of the First Channel, after time 0000 1... = TCH/F + FACCH/F and SACCH/F .... .100 = Timeslot: 4 000. .... = Training Sequence: 0 ...1 .... = Hopping channel: Yes Hopping channel: MAIO 0 Hopping channel: HSN 0 Power Command 0... .... = Spare: 0 .0.. .... = EPC_mode: Channel(s) not in EPC mode ..0. .... = FPC_EPC: FPC not in use/C not in use for uplink power control ...0 0101 = POWER LEVEL: 5 Frequency List - Frequency List, after time Element ID: 5 Length: 16 00.. 000. = Format Identifier: bit map 0 (0x00) List of ARFCNs = 99 34 Channel Mode - Mode of the First Channel(Channel Set 1) Element ID: 99 Channel Mode: speech full rate or half rate version 2(GSM EFR) (33) any idea why this does not work? i used the "[WIP] Ugly hack to compensate lost time on TS change (high TS -> low TS)" path. regards, andreas

3 2

[PATCH] Improve hex parser robustness.
by Max 14 Jan '13

14 Jan '13

--- src/utils.c | 26 ++++++++++++++++++++++---- 1 file changed, 22 insertions(+), 4 deletions(-) diff --git a/src/utils.c b/src/utils.c index c36979c..525bff1 100644 --- a/src/utils.c +++ b/src/utils.c @@ -73,7 +73,7 @@ uint8_t osmo_char2bcd(char c) return c - 0x30; } -/*! \brief Parse a string ocntaining hexadecimal digits +/*! \brief Parse a string ocntaining hexadecimal digits, optionally prefixed with 0x * \param[in] str string containing ASCII encoded hexadecimal digits * \param[out] b output buffer * \param[in] max_len maximum space in output buffer @@ -81,10 +81,28 @@ uint8_t osmo_char2bcd(char c) int osmo_hexparse(const char *str, uint8_t *b, int max_len) { - int i, l, v; + int v; + size_t i, l = strlen(str); + + if (l > 2) { /* remove 0x prefix if any */ + if ('0' == str[0] && 'x' == str[1]) { + l -= 2; + str += 2; + } + } + + if (l & 1) i = l + 1; + else i = l; + char hs[i]; /* enough space to store additional leading 0 if str length is odd */ + + if (l & 1) { + memcpy(hs + 1, str, l); + hs[0] = '0'; + } else { + memcpy(hs, str, l); + } - l = strlen(str); - if ((l&1) || ((l>>1) > max_len)) + if ((l>>1) > max_len) return -1; memset(b, 0x00, max_len); -- 1.7.10.4 --------------040904080202060501050607--

1 0

[PATCH] Improve hex parser robustness.
by Max 14 Jan '13

14 Jan '13

--- include/osmocom/core/utils.h | 2 ++ src/utils.c | 48 ++++++++++++++++++++++++++++++++++++------ 2 files changed, 44 insertions(+), 6 deletions(-) diff --git a/include/osmocom/core/utils.h b/include/osmocom/core/utils.h index 03861d7..05cb2a4 100644 --- a/include/osmocom/core/utils.h +++ b/include/osmocom/core/utils.h @@ -15,6 +15,7 @@ #define OSMO_MIN(a, b) ((a) >= (b) ? (b) : (a)) #include <stdint.h> +#include <stdbool.h> /*! \brief A mapping between human-readable string and numeric value */ struct value_string { @@ -30,6 +31,7 @@ char osmo_bcd2char(uint8_t bcd); /* only works for numbers in ascci */ uint8_t osmo_char2bcd(char c); +int osmo_hexparse_adv(const char *str, uint8_t *b, int max_len, bool allow_odd); int osmo_hexparse(const char *str, uint8_t *b, int max_len); char *osmo_ubit_dump(const uint8_t *bits, unsigned int len); diff --git a/src/utils.c b/src/utils.c index c36979c..8c1849e 100644 --- a/src/utils.c +++ b/src/utils.c @@ -3,7 +3,7 @@ #include <stdint.h> #include <errno.h> #include <stdio.h> - +#include <stdbool.h> #include <osmocom/core/utils.h> /*! \addtogroup utils @@ -73,24 +73,60 @@ uint8_t osmo_char2bcd(char c) return c - 0x30; } -/*! \brief Parse a string ocntaining hexadecimal digits +/*! \brief Parse a string ocntaining hexadecimal digits, optionally prefixed with 0x * \param[in] str string containing ASCII encoded hexadecimal digits * \param[out] b output buffer * \param[in] max_len maximum space in output buffer */ int osmo_hexparse(const char *str, uint8_t *b, int max_len) +{ + return osmo_hexparse_adv(str, b, max_len, false); +} +/*! \brief Parse a string ocntaining hexadecimal digits, optionally prefixed with 0x + * \param[in] str string containing ASCII encoded hexadecimal digits + * \param[out] b output buffer + * \param[in] max_len maximum space in output buffer + * \param[in] allow_odd allow odd length (prefix with 0 on the left side) + */ +int osmo_hexparse_adv(const char *str, uint8_t *b, int max_len, bool allow_odd) { - int i, l, v; + int v; + size_t i, l = strlen(str); + const char * src; + + if (l > 2) { /* remove 0x prefix if any */ + if ('0' == str[0] && 'x' == str[1]) { + l -= 2; + str += 2; + } + } + + if (allow_odd) { + if (l & 1) i = l + 1; + else i = l; + char hs[i]; /* enough space to store additional leading 0 if str length is odd */ + + if (l & 1) { + memcpy(hs + 1, str, l); + hs[0] = '0'; + } else { + memcpy(hs, str, l); + } + src = hs; + } else { + if (l & 1) + return -1; + src = str; + } - l = strlen(str); - if ((l&1) || ((l>>1) > max_len)) + if ((l>>1) > max_len) return -1; memset(b, 0x00, max_len); for (i=0; i<l; i++) { - char c = str[i]; + char c = src[i]; if (c >= '0' && c <= '9') v = c - '0'; else if (c >= 'a' && c <= 'f') -- 1.7.10.4 --------------070900070504060905060402--

1 0

[PATCH] Improve hex parser robustness.
by Max 14 Jan '13

14 Jan '13

--- .gitignore | 1 + include/osmocom/core/utils.h | 5 ++++ src/utils.c | 68 ++++++++++++++++++++++++++++++++---------- tests/Makefile.am | 7 +++-- tests/hex/hex_test.c | 52 ++++++++++++++++++++++++++++++++ tests/hex/hex_test.ok | 18 +++++++++++ tests/testsuite.at | 6 ++++ 7 files changed, 140 insertions(+), 17 deletions(-) create mode 100644 tests/hex/hex_test.c create mode 100644 tests/hex/hex_test.ok diff --git a/.gitignore b/.gitignore index ac19b23..67d9196 100644 --- a/.gitignore +++ b/.gitignore @@ -58,6 +58,7 @@ tests/sms/sms_test tests/timer/timer_test tests/msgfile/msgfile_test tests/ussd/ussd_test +tests/hex/hex_test tests/smscb/smscb_test tests/bits/bitrev_test tests/a5/a5_test diff --git a/include/osmocom/core/utils.h b/include/osmocom/core/utils.h index 03861d7..5250094 100644 --- a/include/osmocom/core/utils.h +++ b/include/osmocom/core/utils.h @@ -30,6 +30,11 @@ char osmo_bcd2char(uint8_t bcd); /* only works for numbers in ascci */ uint8_t osmo_char2bcd(char c); +enum hex_len_policy { /* define how to deal with odd length during hex string parsing */ + HEX_ODD_NONE, HEX_ODD_LEFT, HEX_ODD_RIGHT +}; + +int osmo_hexparse_ext(const char *str, uint8_t *b, int max_len, enum hex_len_policy pol); int osmo_hexparse(const char *str, uint8_t *b, int max_len); char *osmo_ubit_dump(const uint8_t *bits, unsigned int len); diff --git a/src/utils.c b/src/utils.c index c36979c..cd11618 100644 --- a/src/utils.c +++ b/src/utils.c @@ -73,36 +73,74 @@ uint8_t osmo_char2bcd(char c) return c - 0x30; } -/*! \brief Parse a string ocntaining hexadecimal digits +/*! \brief Parse a string ocntaining hexadecimal digits, optionally prefixed with 0x * \param[in] str string containing ASCII encoded hexadecimal digits * \param[out] b output buffer * \param[in] max_len maximum space in output buffer */ int osmo_hexparse(const char *str, uint8_t *b, int max_len) +{ + return osmo_hexparse_ext(str, b, max_len, HEX_ODD_NONE); +} +inline int _osmo_hexval(char c) { - int i, l, v; + if (c >= '0' && c <= '9') + return c - '0'; + if (c >= 'a' && c <= 'f') + return 10 + (c - 'a'); + if (c >= 'A' && c <= 'F') + return 10 + (c - 'A'); + return -1; +} - l = strlen(str); - if ((l&1) || ((l>>1) > max_len)) +/*! \brief Parse a string ocntaining hexadecimal digits, optionally prefixed with 0x + * \param[in] str string containing ASCII encoded hexadecimal digits + * \param[out] b output buffer + * \param[in] max_len maximum space in output buffer + * \param[in] pol defines how to treat odd length case + */ +int osmo_hexparse_ext(const char *str, uint8_t *b, int max_len, enum hex_len_policy pol) +{ + int v; + size_t i, left_adj = 0, right_adj = 0, l = strlen(str); + const char * src; + + if (l > 2) { /* remove 0x prefix if any */ + if (!strncmp(str, "0x", 2)) { + l -= 2; + str += 2; + } + } + + if (l & 1) { + switch (pol) { + case HEX_ODD_LEFT: + left_adj = 1; + break; + case HEX_ODD_NONE: + return -1; + case HEX_ODD_RIGHT: + right_adj = 1; + break; + default: + return -1; + } + } + /* left_adj and right_adj are mutually exclusive so left_adj + right_adj is either 1 or 0 */ + if ((l>>1) > max_len + left_adj + right_adj) return -1; - memset(b, 0x00, max_len); + memset(b, 0x00, max_len + left_adj + right_adj); for (i=0; i<l; i++) { - char c = str[i]; - if (c >= '0' && c <= '9') - v = c - '0'; - else if (c >= 'a' && c <= 'f') - v = 10 + (c - 'a'); - else if (c >= 'A' && c <= 'F') - v = 10 + (c - 'A'); - else + v = _osmo_hexval(str[i]); + if (-1 == v) return -1; - b[i>>1] |= v << (i&1 ? 0 : 4); + b[(i + left_adj) >> 1] |= v << ( (i + left_adj) & 1 ? 0 : 4); } - return i>>1; + return (l + left_adj + right_adj)/2; } static char hexd_buff[4096]; diff --git a/tests/Makefile.am b/tests/Makefile.am index b60f675..fbefab1 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -4,7 +4,7 @@ check_PROGRAMS = timer/timer_test sms/sms_test ussd/ussd_test \ smscb/smscb_test bits/bitrev_test a5/a5_test \ conv/conv_test auth/milenage_test lapd/lapd_test \ gsm0808/gsm0808_test gsm0408/gsm0408_test \ - gb/bssgp_fc_test logging/logging_test + gb/bssgp_fc_test hex/hex_test logging/logging_test if ENABLE_MSGFILE check_PROGRAMS += msgfile/msgfile_test endif @@ -21,6 +21,9 @@ bits_bitrev_test_LDADD = $(top_builddir)/src/libosmocore.la conv_conv_test_SOURCES = conv/conv_test.c conv_conv_test_LDADD = $(top_builddir)/src/libosmocore.la +hex_hex_test_SOURCES = hex/hex_test.c +hex_hex_test_LDADD = $(top_builddir)/src/libosmocore.la + gsm0808_gsm0808_test_SOURCES = gsm0808/gsm0808_test.c gsm0808_gsm0808_test_LDADD = $(top_builddir)/src/libosmocore.la $(top_builddir)/src/gsm/libosmogsm.la @@ -77,7 +80,7 @@ EXTRA_DIST = testsuite.at $(srcdir)/package.m4 $(TESTSUITE) \ gsm0808/gsm0808_test.ok gb/bssgp_fc_tests.err \ gb/bssgp_fc_tests.ok gb/bssgp_fc_tests.sh \ msgfile/msgfile_test.ok msgfile/msgconfig.cfg \ - logging/logging_test.ok logging/logging_test.err + logging/logging_test.ok hex/hex_test.ok logging/logging_test.err DISTCLEANFILES = atconfig diff --git a/tests/hex/hex_test.c b/tests/hex/hex_test.c new file mode 100644 index 0000000..fa85065 --- /dev/null +++ b/tests/hex/hex_test.c @@ -0,0 +1,52 @@ +#include <stdio.h> +#include <stdlib.h> +#include <time.h> + +#include <osmocom/core/utils.h> + +/* ------------------------------------------------------------------------ */ +/* Test vectors */ +/* ------------------------------------------------------------------------ */ + +char * long_rand_x = "0xa63c3b465eb79b3e06ae66eb816eace"; +char * long_rand = "39ea2e536e6a2c0d3e59110df20e4bf"; +char * small_even_x = "0xDEAD"; +char * small_even = "FACE"; +char * small_odd_x = "0xFFACE"; +char * small_odd = "bee"; + +/* ------------------------------------------------------------------------ */ +/* Main */ +/* ------------------------------------------------------------------------ */ + +inline void _run_tests(char * vec, size_t len) +{ + uint8_t test[len]; + + int parsed = osmo_hexparse_ext(vec, test, len, HEX_ODD_NONE); + printf("NONE parsed %s: %d", vec, parsed); + if (-1 != parsed) printf(", dumped: %s\n", osmo_hexdump_nospc(test, len)); + else printf("\n"); + + parsed = osmo_hexparse_ext(vec, test, len, HEX_ODD_LEFT); + printf("LEFT parsed %s: %d", vec, parsed); + if (-1 != parsed) printf(", dumped: %s\n", osmo_hexdump_nospc(test, len)); + else printf("\n"); + + parsed = osmo_hexparse_ext(vec, test, len, HEX_ODD_RIGHT); + printf("RIGHT parsed %s: %d", vec, parsed); + if (-1 != parsed) printf(", dumped: %s\n", osmo_hexdump_nospc(test, len)); + else printf("\n"); +} + +int main(int argc, char argv[]) +{ + _run_tests(long_rand_x, 16); + _run_tests(long_rand, 16); + _run_tests(small_even_x, 2); + _run_tests(small_even, 2); + _run_tests(small_odd_x, 3); + _run_tests(small_odd, 2); + + return 0; +} diff --git a/tests/hex/hex_test.ok b/tests/hex/hex_test.ok new file mode 100644 index 0000000..1419b8c --- /dev/null +++ b/tests/hex/hex_test.ok @@ -0,0 +1,18 @@ +NONE parsed 0xa63c3b465eb79b3e06ae66eb816eace: -1 +LEFT parsed 0xa63c3b465eb79b3e06ae66eb816eace: 16, dumped: 0a63c3b465eb79b3e06ae66eb816eace +RIGHT parsed 0xa63c3b465eb79b3e06ae66eb816eace: 16, dumped: a63c3b465eb79b3e06ae66eb816eace0 +NONE parsed 39ea2e536e6a2c0d3e59110df20e4bf: -1 +LEFT parsed 39ea2e536e6a2c0d3e59110df20e4bf: 16, dumped: 039ea2e536e6a2c0d3e59110df20e4bf +RIGHT parsed 39ea2e536e6a2c0d3e59110df20e4bf: 16, dumped: 39ea2e536e6a2c0d3e59110df20e4bf0 +NONE parsed 0xDEAD: 2, dumped: dead +LEFT parsed 0xDEAD: 2, dumped: dead +RIGHT parsed 0xDEAD: 2, dumped: dead +NONE parsed FACE: 2, dumped: face +LEFT parsed FACE: 2, dumped: face +RIGHT parsed FACE: 2, dumped: face +NONE parsed 0xFFACE: -1 +LEFT parsed 0xFFACE: 3, dumped: 0fface +RIGHT parsed 0xFFACE: 3, dumped: fface0 +NONE parsed bee: -1 +LEFT parsed bee: 2, dumped: 0bee +RIGHT parsed bee: 2, dumped: bee0 diff --git a/tests/testsuite.at b/tests/testsuite.at index 1cfae03..cfbcf78 100644 --- a/tests/testsuite.at +++ b/tests/testsuite.at @@ -28,6 +28,12 @@ cat $abs_srcdir/conv/conv_test.ok > expout AT_CHECK([$abs_top_builddir/tests/conv/conv_test], [], [expout]) AT_CLEANUP +AT_SETUP([hex]) +AT_KEYWORDS([hex]) +cat $abs_srcdir/hex/hex_test.ok > expout +AT_CHECK([$abs_top_builddir/tests/hex/hex_test], [], [expout]) +AT_CLEANUP + if ENABLE_MSGFILE AT_SETUP([msgfile]) AT_KEYWORDS([msgfile]) -- 1.7.10.4 --------------040406000709000102010704--

1 0

[PATCH] Improve hex parser robustness.
by Max 14 Jan '13

14 Jan '13

--- .gitignore | 1 + include/osmocom/core/utils.h | 5 ++++ src/utils.c | 68 ++++++++++++++++++++++++++++++++---------- tests/Makefile.am | 7 +++-- tests/hex/hex_test.c | 57 +++++++++++++++++++++++++++++++++++ tests/hex/hex_test.ok | 18 +++++++++++ tests/testsuite.at | 6 ++++ 7 files changed, 145 insertions(+), 17 deletions(-) create mode 100644 tests/hex/hex_test.c create mode 100644 tests/hex/hex_test.ok diff --git a/.gitignore b/.gitignore index ac19b23..67d9196 100644 --- a/.gitignore +++ b/.gitignore @@ -58,6 +58,7 @@ tests/sms/sms_test tests/timer/timer_test tests/msgfile/msgfile_test tests/ussd/ussd_test +tests/hex/hex_test tests/smscb/smscb_test tests/bits/bitrev_test tests/a5/a5_test diff --git a/include/osmocom/core/utils.h b/include/osmocom/core/utils.h index 03861d7..5250094 100644 --- a/include/osmocom/core/utils.h +++ b/include/osmocom/core/utils.h @@ -30,6 +30,11 @@ char osmo_bcd2char(uint8_t bcd); /* only works for numbers in ascci */ uint8_t osmo_char2bcd(char c); +enum hex_len_policy { /* define how to deal with odd length during hex string parsing */ + HEX_ODD_NONE, HEX_ODD_LEFT, HEX_ODD_RIGHT +}; + +int osmo_hexparse_ext(const char *str, uint8_t *b, int max_len, enum hex_len_policy pol); int osmo_hexparse(const char *str, uint8_t *b, int max_len); char *osmo_ubit_dump(const uint8_t *bits, unsigned int len); diff --git a/src/utils.c b/src/utils.c index c36979c..a93d72c 100644 --- a/src/utils.c +++ b/src/utils.c @@ -73,36 +73,74 @@ uint8_t osmo_char2bcd(char c) return c - 0x30; } -/*! \brief Parse a string ocntaining hexadecimal digits +/*! \brief Parse a string ocntaining hexadecimal digits, optionally prefixed with 0x * \param[in] str string containing ASCII encoded hexadecimal digits * \param[out] b output buffer * \param[in] max_len maximum space in output buffer */ int osmo_hexparse(const char *str, uint8_t *b, int max_len) +{ + return osmo_hexparse_ext(str, b, max_len, HEX_ODD_NONE); +} +static inline int _osmo_hexval(char c) { - int i, l, v; + if (c >= '0' && c <= '9') + return c - '0'; + if (c >= 'a' && c <= 'f') + return 10 + (c - 'a'); + if (c >= 'A' && c <= 'F') + return 10 + (c - 'A'); + return -1; +} - l = strlen(str); - if ((l&1) || ((l>>1) > max_len)) +/*! \brief Parse a string ocntaining hexadecimal digits, optionally prefixed with 0x + * \param[in] str string containing ASCII encoded hexadecimal digits + * \param[out] b output buffer + * \param[in] max_len maximum space in output buffer + * \param[in] pol defines how to treat odd length case + */ +int osmo_hexparse_ext(const char *str, uint8_t *b, int max_len, enum hex_len_policy pol) +{ + int v; + size_t i, left_adj = 0, right_adj = 0, l = strlen(str); + const char *src; + + if (l > 2) { /* remove 0x prefix if any */ + if (!strncmp(str, "0x", 2)) { + l -= 2; + str += 2; + } + } + + if (l & 1) { + switch (pol) { + case HEX_ODD_LEFT: + left_adj = 1; + break; + case HEX_ODD_NONE: + return -1; + case HEX_ODD_RIGHT: + right_adj = 1; + break; + default: + return -1; + } + } +/* left_adj and right_adj are mutually exclusive so left_adj + right_adj is either 1 or 0 */ + if ((l>>1) + left_adj + right_adj > max_len) return -1; memset(b, 0x00, max_len); - for (i=0; i<l; i++) { - char c = str[i]; - if (c >= '0' && c <= '9') - v = c - '0'; - else if (c >= 'a' && c <= 'f') - v = 10 + (c - 'a'); - else if (c >= 'A' && c <= 'F') - v = 10 + (c - 'A'); - else + for (i = 0; i < l; i++) { + v = _osmo_hexval(str[i]); + if (-1 == v) return -1; - b[i>>1] |= v << (i&1 ? 0 : 4); + b[(i + left_adj) >> 1] |= v << ((i + left_adj) & 1 ? 0 : 4); } - return i>>1; + return (l + left_adj + right_adj)/2; } static char hexd_buff[4096]; diff --git a/tests/Makefile.am b/tests/Makefile.am index b60f675..fbefab1 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -4,7 +4,7 @@ check_PROGRAMS = timer/timer_test sms/sms_test ussd/ussd_test \ smscb/smscb_test bits/bitrev_test a5/a5_test \ conv/conv_test auth/milenage_test lapd/lapd_test \ gsm0808/gsm0808_test gsm0408/gsm0408_test \ - gb/bssgp_fc_test logging/logging_test + gb/bssgp_fc_test hex/hex_test logging/logging_test if ENABLE_MSGFILE check_PROGRAMS += msgfile/msgfile_test endif @@ -21,6 +21,9 @@ bits_bitrev_test_LDADD = $(top_builddir)/src/libosmocore.la conv_conv_test_SOURCES = conv/conv_test.c conv_conv_test_LDADD = $(top_builddir)/src/libosmocore.la +hex_hex_test_SOURCES = hex/hex_test.c +hex_hex_test_LDADD = $(top_builddir)/src/libosmocore.la + gsm0808_gsm0808_test_SOURCES = gsm0808/gsm0808_test.c gsm0808_gsm0808_test_LDADD = $(top_builddir)/src/libosmocore.la $(top_builddir)/src/gsm/libosmogsm.la @@ -77,7 +80,7 @@ EXTRA_DIST = testsuite.at $(srcdir)/package.m4 $(TESTSUITE) \ gsm0808/gsm0808_test.ok gb/bssgp_fc_tests.err \ gb/bssgp_fc_tests.ok gb/bssgp_fc_tests.sh \ msgfile/msgfile_test.ok msgfile/msgconfig.cfg \ - logging/logging_test.ok logging/logging_test.err + logging/logging_test.ok hex/hex_test.ok logging/logging_test.err DISTCLEANFILES = atconfig diff --git a/tests/hex/hex_test.c b/tests/hex/hex_test.c new file mode 100644 index 0000000..5c060c4 --- /dev/null +++ b/tests/hex/hex_test.c @@ -0,0 +1,57 @@ +#include <stdio.h> +#include <stdlib.h> +#include <time.h> + +#include <osmocom/core/utils.h> + +/* ------------------------------------------------------------------------ */ +/* Test vectors */ +/* ------------------------------------------------------------------------ */ + +char * long_rand_x = "0xa63c3b465eb79b3e06ae66eb816eace"; +char * long_rand = "39ea2e536e6a2c0d3e59110df20e4bf"; +char * small_even_x = "0xDEAD"; +char * small_even = "FACE"; +char * small_odd_x = "0xFFACE"; +char * small_odd = "bee"; + +/* ------------------------------------------------------------------------ */ +/* Main */ +/* ------------------------------------------------------------------------ */ + +inline void _single_test(char * vec, size_t len, uint8_t * test, enum hex_len_policy pol) +{ + int r = osmo_hexparse_ext(vec, test, len, pol); + printf(" parsed %s (%u): %d", vec, len, r); + if (-1 != r) printf(", dumped: %s, check %x,%d,%d\n", osmo_hexdump_nospc(test, len), test[len - 1], test[len], test[len + 1]); + else printf("\n"); +} + +inline void _run_tests(char * vec, size_t len) +{ + uint8_t test[len + 4]; + int r; + + for (r = 0; r < len + 4; r++) test[r] = r; + + printf("NONE"); + _single_test(vec, len, test, HEX_ODD_NONE); + + printf("LEFT"); + _single_test(vec, len, test, HEX_ODD_LEFT); + + printf("RIGHT"); + _single_test(vec, len, test, HEX_ODD_RIGHT); +} + +int main(int argc, char **argv) +{ + _run_tests(long_rand_x, 16); + _run_tests(long_rand, 16); + _run_tests(small_even_x, 2); + _run_tests(small_even, 2); + _run_tests(small_odd_x, 3); + _run_tests(small_odd, 2); + + return 0; +} diff --git a/tests/hex/hex_test.ok b/tests/hex/hex_test.ok new file mode 100644 index 0000000..44e89d2 --- /dev/null +++ b/tests/hex/hex_test.ok @@ -0,0 +1,18 @@ +NONE parsed 0xa63c3b465eb79b3e06ae66eb816eace (16): -1 +LEFT parsed 0xa63c3b465eb79b3e06ae66eb816eace (16): 16, dumped: 0a63c3b465eb79b3e06ae66eb816eace, check ce,16,17 +RIGHT parsed 0xa63c3b465eb79b3e06ae66eb816eace (16): 16, dumped: a63c3b465eb79b3e06ae66eb816eace0, check e0,16,17 +NONE parsed 39ea2e536e6a2c0d3e59110df20e4bf (16): -1 +LEFT parsed 39ea2e536e6a2c0d3e59110df20e4bf (16): 16, dumped: 039ea2e536e6a2c0d3e59110df20e4bf, check bf,16,17 +RIGHT parsed 39ea2e536e6a2c0d3e59110df20e4bf (16): 16, dumped: 39ea2e536e6a2c0d3e59110df20e4bf0, check f0,16,17 +NONE parsed 0xDEAD (2): 2, dumped: dead, check ad,2,3 +LEFT parsed 0xDEAD (2): 2, dumped: dead, check ad,2,3 +RIGHT parsed 0xDEAD (2): 2, dumped: dead, check ad,2,3 +NONE parsed FACE (2): 2, dumped: face, check ce,2,3 +LEFT parsed FACE (2): 2, dumped: face, check ce,2,3 +RIGHT parsed FACE (2): 2, dumped: face, check ce,2,3 +NONE parsed 0xFFACE (3): -1 +LEFT parsed 0xFFACE (3): 3, dumped: 0fface, check ce,3,4 +RIGHT parsed 0xFFACE (3): 3, dumped: fface0, check e0,3,4 +NONE parsed bee (2): -1 +LEFT parsed bee (2): 2, dumped: 0bee, check ee,2,3 +RIGHT parsed bee (2): 2, dumped: bee0, check e0,2,3 diff --git a/tests/testsuite.at b/tests/testsuite.at index 1cfae03..cfbcf78 100644 --- a/tests/testsuite.at +++ b/tests/testsuite.at @@ -28,6 +28,12 @@ cat $abs_srcdir/conv/conv_test.ok > expout AT_CHECK([$abs_top_builddir/tests/conv/conv_test], [], [expout]) AT_CLEANUP +AT_SETUP([hex]) +AT_KEYWORDS([hex]) +cat $abs_srcdir/hex/hex_test.ok > expout +AT_CHECK([$abs_top_builddir/tests/hex/hex_test], [], [expout]) +AT_CLEANUP + if ENABLE_MSGFILE AT_SETUP([msgfile]) AT_KEYWORDS([msgfile]) -- 1.7.10.4 --------------080702070805090503080203--

1 0

sylvains talk from 29c3
by Vic Delorge 12 Jan '13

12 Jan '13

Speaker: Sylvain Munaut or how to turn a phone into a BTS The calypso baseband and its companion chips are used on the Motorola C123 among other and are now well known for being supported by the Osmocom-BB open source GSM baseband implementation. A couple years ago, it was hacked a little further by using it as a raw bits capture device allowing the interception of GSM traffic very cheaply. This talk will present some further work on that platform, showing that just because a device wasn't design for a given task doesn't mean it can't do it. More specifically how you can hack this phone to act as a GSM basestation and broadcast your own network. http://youtu.be/xFjVcxMpA6c

3 3

calypso-talk 29c3
by Erich Dachleger 12 Jan '13

12 Jan '13

Hi list, I saw the interesting talk about turning the osmocombb-phone into a proof of concept bts using openbts. During the talk:When OpenBts was configured(before using sipauthserve) was it the option --with-uhd (as is for umtrx )that was used? Does anybody know when the code will be released? [I built sylvain/testing branch as well as branch jolly/meas branch some days ago, but I couldn't find that code anywhere, so I guess it is not available anywhere yet] regards erich

1 0

Re: GTA02 Burst_ind baudrate
by Alex Badea 11 Jan '13

11 Jan '13

On Thu, Jan 10, 2013 at 11:33 PM, Heiko Besemann <heiko(a)noordsee.de> wrote: > > Hello Alex, You should send mail to the mailing list, instead of specific individuals. This way, i) you may get a responder quicker, and ii) information can reach other interested people. > > I read on Osmocom-BB mailing-list that you are using a GTA02 with > cross-compiled tools. Well, I did cross-compiling of the sylvain/burst_ind > branch for the OpenMoko, but starting osmocon I get an error that the > higher non-standard baudrate can not be set to /dev/ttySAC0. On the GTA02 the calypso is wired to one internal UART of the application processor SoC. AFAIR the SoC only supports up to 115200 bps so it won't be usable with burst_ind. Cheers, Alex

3 2

Re: MDL-Error in case of OsmocomBB+OpenBTS
by Pavel Baturko 11 Jan '13

11 Jan '13

Hi, Erich, I'm using OpenBTS with USRP B100 & SBX. I encountered new problem, maybe it's similar to initial problem. Calls and MO SMS works fine (not in 100%, but it's ok). But MT SMS does not work (actually I received only 1 SMS from many attempts). Mobile log (error part, from line 454): <0001> gsm48_rr.c:429 new SAPI 3 link state idle -> established <000e> gsm48_rr.c:5042 Radio link SAPI3 is established <0005> gsm48_mm.c:3911 (ms 1) Received 'RR_EST_IND' from RR in state wait for network command (sapi 3) <0001> gsm48_rr.c:662 MON: f=50 lev=>=-47 snr= 0 ber= 0 LAI=001 01 0001 ID=0001 TA=3 pwr=19 TS=0/0 <0001> gsm48_rr.c:2864 MEAS REP: pwr=19 TA=3 meas-invalid=0 rxlev-full=-47 rxlev-sub=-47 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 <0001> gsm48_rr.c:4767 Indicated ta 3 (actual ta 3) <0001> gsm48_rr.c:4769 Indicated tx_power 19 <0001> gsm48_rr.c:4767 Indicated ta 3 (actual ta 3) <0001> gsm48_rr.c:4769 Indicated tx_power 19 <0001> gsm48_rr.c:4984 MDL-Error (cause 4) ignoring Dropping frame with 71 bit errors <0001> gsm48_rr.c:4767 Indicated ta 3 (actual ta 3) <0001> gsm48_rr.c:4769 Indicated tx_power 19 <0001> gsm48_rr.c:662 MON: f=50 lev=>=-47 snr=10 ber= 42 LAI=001 01 0001 ID=0001 TA=3 pwr=19 TS=0/0 <0001> gsm48_rr.c:2864 MEAS REP: pwr=19 TA=3 meas-invalid=0 rxlev-full=-47 rxlev-sub=-47 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 <0001> gsm48_rr.c:3389 channel release request with cause 0x62 <0001> gsm48_rr.c:355 new state dedicated -> release pending In trace (from packet 5509): BTS send SABM MS receive SABM MS respond with UA BTS receive UA BTS send I frame MS receive SABM (extra message?) MS respond with UA BTS receive UA BTS send DM (disconnect request? because of extra UA respond from MS?) BTS send Channel Release after that MS receive I frame and send RR with ack but as I understand this does not matter because of Chan Release.. Thanks, Pavel On Thu, Jan 10, 2013 at 6:02 PM, Erich Dachleger <edachleger(a)yahoo.com> wrote: > What do you use to generate the network? > The osmocombb-phone or other bts? > cheers > Erich > > ________________________________ > Fra: Pavel Baturko <pabftk(a)gmail.com> > Til: baseband-devel(a)lists.osmocom.org > Sendt: Mandag, 7. januar 2013 21.04 > Emne: MDL-Error in case of OsmocomBB+OpenBTS > > Hi list, > > I'm trying to connect my OsmocomBB phone to OpenBTS and I always got > MDL-Error in mobile app log when MS trying to perform LU. > Part of log (full mobile log in attach): > <0001> gsm48_rr.c:355 new state connection pending -> dedicated > <0005> gsm48_mm.c:3911 (ms 1) Received 'RR_EST_CNF' from RR in state wait > for RR connection (location updating) (sapi 0) > <0005> gsm48_mm.c:404 starting T3210 (loc. upd. timeout) with 20.0 seconds > <0005> gsm48_mm.c:924 new state wait for RR connection (location updating) > -> location updating initiated > <0001> gsm48_rr.c:4984 MDL-Error (cause 3) ignoring > <0001> gsm48_rr.c:4987 MDL-Error (cause 3) aborting > <0001> gsm48_rr.c:355 new state dedicated -> idle > > In wireshark trace (from OpenBTS, attached) I see that MS sends LURequest > (packet 359) and BTS responds with LUAccept (packet 440) but MS never > receive this message because of error. > > As I understand this is "unsolicited UA response" from 08.58 (9.3.22) but I > do not know how to fix that or properly debug. > I'm using latest sylvain/testing and official OpenBTS 2.8. "Usual" (not with > OsmocomBB) phones works with OpenBTS fine and OsmocomBB phones works fine > with "usual" (not OpenBTS) networks. > > Thanks, > Pavel > >

1 0

Unencrypted MT
by Dario Lombardo 10 Jan '13

10 Jan '13

Hi list! As described in Nico Golde's talk at 29c3, mobile operators can deactivate encryption on MT SMSes. To check if a MT is encrypted I've started 'mobile' with GSMTAP, and I've sent an sms to the mobile. Encryption seems to be requested by the network. Now the question is: how can I be sure that encryption is always activated? Should I exaustively send messages to the mobile in order to look for unecrypted messages? Or is there some other way? People who give stats about MNO do exaustive tests, or simply generate a bunch of events and campute stats on those results? Thanks for your answers/opinions. Dario.

3 3

Cleaning up stuff
by Dario Lombardo 09 Jan '13

09 Jan '13

Hi guys This is a question related to the compilation system of osmocom-bb. For an unknown reason, something has gone wrong with my compiled binaries, so now I would like to clean up everything as it was freshly checked out, before restarting the compilation. How can I do it? Make clean and make distclean seem not to be enough, since my compilation now fails with: cd ./doc && tar cf html.tar */html make[3]: Leaving directory `/home/dario/Projects/mobile/osmocom-bb/src/shared/libosmocore/build-target' make[2]: Leaving directory `/home/dario/Projects/mobile/osmocom-bb/src/shared/libosmocore/build-target' make[1]: Leaving directory `/home/dario/Projects/mobile/osmocom-bb/src/shared/libosmocore/build-target' cd host/layer23 && ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether make sets $(MAKE)... (cached) yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for ranlib... ranlib checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for LIBOSMOCORE... no configure: error: Package requirements (libosmocore) were not met: No package 'libosmocore' found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables LIBOSMOCORE_CFLAGS and LIBOSMOCORE_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. make: *** [host/layer23/Makefile] Error 1 How can I clean up everything? Any help appreciated. Thanks Dario.

3 3

[PATCH] Typos
by Dario Lombardo 08 Jan '13

08 Jan '13

Attached a small patch that fixes a couple of typos. Have a nice day. Dario.

2 1

MDL-Error in case of OsmocomBB+OpenBTS
by Pavel Baturko 08 Jan '13

08 Jan '13

Hi list, I'm trying to connect my OsmocomBB phone to OpenBTS and I always got MDL-Error in mobile app log when MS trying to perform LU. Part of log (full mobile log in attach): <0001> gsm48_rr.c:355 new state connection pending -> dedicated <0005> gsm48_mm.c:3911 (ms 1) Received 'RR_EST_CNF' from RR in state wait for RR connection (location updating) (sapi 0) <0005> gsm48_mm.c:404 starting T3210 (loc. upd. timeout) with 20.0 seconds <0005> gsm48_mm.c:924 new state wait for RR connection (location updating) -> location updating initiated <0001> gsm48_rr.c:4984 MDL-Error (cause 3) ignoring <0001> gsm48_rr.c:4987 MDL-Error (cause 3) aborting <0001> gsm48_rr.c:355 new state dedicated -> idle In wireshark trace (from OpenBTS, attached) I see that MS sends LURequest (packet 359) and BTS responds with LUAccept (packet 440) but MS never receive this message because of error. As I understand this is "unsolicited UA response" from 08.58 (9.3.22) but I do not know how to fix that or properly debug. I'm using latest sylvain/testing and official OpenBTS 2.8. "Usual" (not with OsmocomBB) phones works with OpenBTS fine and OsmocomBB phones works fine with "usual" (not OpenBTS) networks. Thanks, Pavel

7 11

Re: Cleaning up stuff
by Dario Lombardo 08 Jan '13

08 Jan '13

I've done it and now everything works, thanks. But I've noticed that this requirement is not documented anywhere. Wiki should be updated or new users will stuck at this point. On Mon, Jan 7, 2013 at 7:00 PM, Erich Dachleger <edachleger(a)yahoo.com>wrote: > Did you install libosmocore first?One must do that now > regards > erich > >

1 0

Sylvain/testing branch compile error in gsm411
by Karsten Krummeich 07 Jan '13

07 Jan '13

Hi list, I want to play with the mobile_app with TX and SIM-card support, so I checkout the sylvain/testing branch described in the wiki but the following error message occurs. The master branch work's very fine on my HW (C123). Can someone give me a hint, what should I do to get a working testset with SIM support? Here the shell-output by makeing sylvain/testing branch ...... CC gsm411_sms.o gsm411_sms.c: In Funktion »gsm340_rx_tpdu«: gsm411_sms.c:228:19: Warnung: Variable »sms_mms« gesetzt, aber nicht verwendet [-Wunused-but-set-variable] gsm411_sms.c: In Funktion »gsm411_rx_rp_ud«: gsm411_sms.c:375:2: Warnung: Format »%li« erwartet Argumenttyp »long int«, aber Argument 7 hat Typ »int« [-Wformat] gsm411_sms.c: In Funktion »gsm411_tx_sms_submit«: gsm411_sms.c:657:3: Warnung: Übergabe des Arguments 4 von »gsm411_smc_init« von inkompatiblem Zeigertyp [standardmäßig aktiviert] /home/kasio/osmocom-bb/src/shared/libosmocore/include/osmocom/gsm/gsm0411_smc.h:46:6: Anmerkung: »int (*)(struct gsm411_smc_inst *, int, struct msgb *, int)« erwartet, aber Argument hat Typ »int (*)(struct gsm411_smc_inst *, int, struct msgb *)« gsm411_sms.c:657:3: Fehler: zu viele Argumente für Funktion »gsm411_smc_init« /home/kasio/osmocom-bb/src/shared/libosmocore/include/osmocom/gsm/gsm0411_smc.h:46:6: Anmerkung: hier deklariert gsm411_sms.c:659:3: Fehler: zu viele Argumente für Funktion »gsm411_smr_init« /home/kasio/osmocom-bb/src/shared/libosmocore/include/osmocom/gsm/gsm0411_smr.h:27:6: Anmerkung: hier deklariert gsm411_sms.c: In Funktion »gsm411_rcv_sms«: gsm411_sms.c:911:4: Warnung: Übergabe des Arguments 4 von »gsm411_smc_init« von inkompatiblem Zeigertyp [standardmäßig aktiviert] /home/kasio/osmocom-bb/src/shared/libosmocore/include/osmocom/gsm/gsm0411_smc.h:46:6: Anmerkung: »int (*)(struct gsm411_smc_inst *, int, struct msgb *, int)« erwartet, aber Argument hat Typ »int (*)(struct gsm411_smc_inst *, int, struct msgb *)« gsm411_sms.c:911:4: Fehler: zu viele Argumente für Funktion »gsm411_smc_init« /home/kasio/osmocom-bb/src/shared/libosmocore/include/osmocom/gsm/gsm0411_smc.h:46:6: Anmerkung: hier deklariert gsm411_sms.c:913:4: Fehler: zu viele Argumente für Funktion »gsm411_smr_init« /home/kasio/osmocom-bb/src/shared/libosmocore/include/osmocom/gsm/gsm0411_smr.h:27:6: Anmerkung: hier deklariert make[3]: *** [gsm411_sms.o] Fehler 1 make[3]: Verlasse Verzeichnis '/home/kasio/osmocom-bb/src/host/layer23/src/mobile' make[2]: *** [all-recursive] Fehler 1 make[2]: Verlasse Verzeichnis '/home/kasio/osmocom-bb/src/host/layer23/src' make[1]: *** [all-recursive] Fehler 1 make[1]: Verlasse Verzeichnis '/home/kasio/osmocom-bb/src/host/layer23' make: *** [host/layer23/layer23] Fehler 2 kasio@T60:~/osmocom-bb/src$ Thanks a lot for your help. kasio

4 7

PySIM write SMSC
by Kurtis Heimerl 07 Jan '13

07 Jan '13

Hey Baseband, I've got a stock of SIMs I bought and programmed already, but I unfortunately (and stupidly) forgot to set the SMSC. This is causing me heaps of issues, as each phone now has to have the SMSC set manually. I was hoping to hack up a quick script which just inserts the SMSC onto the SIM without needing to regenerate the ki or IMSI. Lining those up with my database is rife with hazard. Looking at the pySim-prog, it looks like this probably isn't possible; all of the data seems to get bundled together and so changing the SMSC length will cause other data to be corrupted. Is that right? I just wanted to see what ya'll think would be the best way for me to remedy my particular stupidity. Thanks!

3 4

layer23 on GTA02 AP and ARM unaligned memory access
by Alex Badea 06 Jan '13

06 Jan '13

Hi list, I'm running layer23 apps on the Application Processor of the OpenMoko GTA02, which is also an ARM. I noticed that some parts of code try to access words in memory which are not naturally aligned. [ The first symptom was "Err from socket: Bad address" given by osmocon. This is because a bogus length header read from the L2 unix socket was overflowing a static 4K buffer. The bogus length was due to an unaligned uint16_t write in osmo_send_l1() -- for an L1CTL_DATA_REQ I think. ] The easy and inefficient workaround for this is to ask the kernel[1] to fix up these accesses: echo 3 > /proc/cpu/alignment Cheers, Alex [1] http://lxr.linux.no/#linux+v3.7.1/Documentation/arm/mem_alignment

2 1

[PATCH] l1: add CBCH flag to dedicated mode
by Alex Badea 06 Jan '13

06 Jan '13

Add a .cbch_mode member to struct l1ctl_dm_est_req. If set, this instructs L1 to use the CBCH variant of SDCCH for dedicated mode (no uplink, no SACCH). Add the new cbch_mode flag to l1ctl_tx_dm_est_req* API calls. Clear it everywhere, except for app_cbch_sniff. Signed-off-by: Alex Badea <vamposdecampos(a)gmail.com> --- The extra struct member might be a bit excessive; an alternative would be to abuse audio_mode, which is not used for signalling channels. include/l1ctl_proto.h | 1 + src/host/layer23/include/osmocom/bb/common/l1ctl.h | 5 +++-- src/host/layer23/src/common/l1ctl.c | 6 ++++-- src/host/layer23/src/misc/app_cbch_sniff.c | 4 ++-- src/host/layer23/src/mobile/gsm48_rr.c | 4 ++-- src/target/firmware/include/layer1/mframe_sched.h | 3 +++ src/target/firmware/layer1/l23_api.c | 12 +++++++----- src/target/firmware/layer1/mframe_sched.c | 14 ++++++++++++++ 8 files changed, 36 insertions(+), 13 deletions(-) diff --git a/include/l1ctl_proto.h b/include/l1ctl_proto.h index 771bf1c..55f0ffc 100644 --- a/include/l1ctl_proto.h +++ b/include/l1ctl_proto.h @@ -233,6 +233,7 @@ struct l1ctl_dm_est_req { }; uint8_t tch_mode; uint8_t audio_mode; + uint8_t cbch_mode; } __attribute__((packed)); struct l1ctl_dm_freq_req { diff --git a/src/host/layer23/include/osmocom/bb/common/l1ctl.h b/src/host/layer23/include/osmocom/bb/common/l1ctl.h index 46a333e..f25a516 100644 --- a/src/host/layer23/include/osmocom/bb/common/l1ctl.h +++ b/src/host/layer23/include/osmocom/bb/common/l1ctl.h @@ -25,10 +25,11 @@ int l1ctl_tx_rach_req(struct osmocom_ms *ms, uint8_t ra, uint16_t offset, /* Transmit L1CTL_DM_EST_REQ */ int l1ctl_tx_dm_est_req_h0(struct osmocom_ms *ms, uint16_t band_arfcn, - uint8_t chan_nr, uint8_t tsc, uint8_t tch_mode, uint8_t audio_mode); + uint8_t chan_nr, uint8_t tsc, uint8_t tch_mode, uint8_t audio_mode, + uint8_t cbch_mode); int l1ctl_tx_dm_est_req_h1(struct osmocom_ms *ms, uint8_t maio, uint8_t hsn, uint16_t *ma, uint8_t ma_len, uint8_t chan_nr, uint8_t tsc, - uint8_t tch_mode, uint8_t audio_mode); + uint8_t tch_mode, uint8_t audio_mode, uint8_t cbch_mode); /* Transmit L1CTL_DM_FREQ_REQ */ int l1ctl_tx_dm_freq_req_h0(struct osmocom_ms *ms, uint16_t band_arfcn, diff --git a/src/host/layer23/src/common/l1ctl.c b/src/host/layer23/src/common/l1ctl.c index 5898b22..57003af 100644 --- a/src/host/layer23/src/common/l1ctl.c +++ b/src/host/layer23/src/common/l1ctl.c @@ -461,7 +461,7 @@ int l1ctl_tx_rach_req(struct osmocom_ms *ms, uint8_t ra, uint16_t offset, /* Transmit L1CTL_DM_EST_REQ */ int l1ctl_tx_dm_est_req_h0(struct osmocom_ms *ms, uint16_t band_arfcn, uint8_t chan_nr, uint8_t tsc, uint8_t tch_mode, - uint8_t audio_mode) + uint8_t audio_mode, uint8_t cbch_mode) { struct msgb *msg; struct l1ctl_info_ul *ul; @@ -484,6 +484,7 @@ int l1ctl_tx_dm_est_req_h0(struct osmocom_ms *ms, uint16_t band_arfcn, req->h0.band_arfcn = htons(band_arfcn); req->tch_mode = tch_mode; req->audio_mode = audio_mode; + req->cbch_mode = cbch_mode; return osmo_send_l1(ms, msg); } @@ -491,7 +492,7 @@ int l1ctl_tx_dm_est_req_h0(struct osmocom_ms *ms, uint16_t band_arfcn, int l1ctl_tx_dm_est_req_h1(struct osmocom_ms *ms, uint8_t maio, uint8_t hsn, uint16_t *ma, uint8_t ma_len, uint8_t chan_nr, uint8_t tsc, uint8_t tch_mode, - uint8_t audio_mode) + uint8_t audio_mode, uint8_t cbch_mode) { struct msgb *msg; struct l1ctl_info_ul *ul; @@ -519,6 +520,7 @@ int l1ctl_tx_dm_est_req_h1(struct osmocom_ms *ms, uint8_t maio, uint8_t hsn, req->h1.ma[i] = htons(ma[i]); req->tch_mode = tch_mode; req->audio_mode = audio_mode; + req->cbch_mode = cbch_mode; return osmo_send_l1(ms, msg); } diff --git a/src/host/layer23/src/misc/app_cbch_sniff.c b/src/host/layer23/src/misc/app_cbch_sniff.c index 8256eaf..6df2f11 100644 --- a/src/host/layer23/src/misc/app_cbch_sniff.c +++ b/src/host/layer23/src/misc/app_cbch_sniff.c @@ -57,12 +57,12 @@ static int try_cbch(struct osmocom_ms *ms, struct gsm48_sysinfo *s) return l1ctl_tx_dm_est_req_h1(ms, s->maio, s->hsn, s->hopping, s->hopp_len, s->chan_nr, s->tsc, - GSM48_CMODE_SIGN, 0); + GSM48_CMODE_SIGN, 0, 1); } else { LOGP(DRR, LOGL_INFO, "chan_nr = 0x%02x TSC = %d ARFCN = %d\n", s->chan_nr, s->tsc, s->arfcn); return l1ctl_tx_dm_est_req_h0(ms, s->arfcn, - s->chan_nr, s->tsc, GSM48_CMODE_SIGN, 0); + s->chan_nr, s->tsc, GSM48_CMODE_SIGN, 0, 1); } } diff --git a/src/host/layer23/src/mobile/gsm48_rr.c b/src/host/layer23/src/mobile/gsm48_rr.c index 3d15494..a21758c 100644 --- a/src/host/layer23/src/mobile/gsm48_rr.c +++ b/src/host/layer23/src/mobile/gsm48_rr.c @@ -3002,10 +3002,10 @@ static int gsm48_rr_activate_channel(struct osmocom_ms *ms, if (cd->h) l1ctl_tx_dm_est_req_h1(ms, cd->maio, cd->hsn, ma, ma_len, cd->chan_nr, cd->tsc, cd->mode, - rr->audio_mode); + rr->audio_mode, 0); else l1ctl_tx_dm_est_req_h0(ms, cd->arfcn, cd->chan_nr, cd->tsc, - cd->mode, rr->audio_mode); + cd->mode, rr->audio_mode, 0); rr->dm_est = 1; /* old SI 5/6 are not valid on a new dedicated channel */ diff --git a/src/target/firmware/include/layer1/mframe_sched.h b/src/target/firmware/include/layer1/mframe_sched.h index ecdb1ec..74e2d27 100644 --- a/src/target/firmware/include/layer1/mframe_sched.h +++ b/src/target/firmware/include/layer1/mframe_sched.h @@ -23,6 +23,9 @@ enum mframe_task { MF_TASK_SDCCH8_6, MF_TASK_SDCCH8_7, + MF_TASK_SDCCH4_CBCH, + MF_TASK_SDCCH8_CBCH, + MF_TASK_TCH_F_EVEN, MF_TASK_TCH_F_ODD, MF_TASK_TCH_H_0, diff --git a/src/target/firmware/layer1/l23_api.c b/src/target/firmware/layer1/l23_api.c index ae39e63..215fc00 100644 --- a/src/target/firmware/layer1/l23_api.c +++ b/src/target/firmware/layer1/l23_api.c @@ -72,7 +72,7 @@ enum mf_type { MF26ODD, MF26EVEN }; -static uint32_t chan_nr2mf_task_mask(uint8_t chan_nr, uint8_t neigh_mode) +static uint32_t chan_nr2mf_task_mask(uint8_t chan_nr, uint8_t neigh_mode, uint8_t cbch) { uint8_t cbits = chan_nr >> 3; uint8_t tn = chan_nr & 0x7; @@ -90,11 +90,11 @@ static uint32_t chan_nr2mf_task_mask(uint8_t chan_nr, uint8_t neigh_mode) master_task = MF_TASK_TCH_H_0 + lch_idx; } else if ((cbits & 0x1c) == 0x04) { lch_idx = cbits & 0x3; - master_task = MF_TASK_SDCCH4_0 + lch_idx; + master_task = cbch ? MF_TASK_SDCCH4_CBCH : (MF_TASK_SDCCH4_0 + lch_idx); multiframe = MF51; } else if ((cbits & 0x18) == 0x08) { lch_idx = cbits & 0x7; - master_task = MF_TASK_SDCCH8_0 + lch_idx; + master_task = cbch ? MF_TASK_SDCCH8_CBCH : (MF_TASK_SDCCH8_0 + lch_idx); multiframe = MF51; #if 0 } else if (cbits == 0x10) { @@ -225,7 +225,8 @@ static void l1ctl_rx_dm_est_req(struct msgb *msg) struct l1ctl_info_ul *ul = (struct l1ctl_info_ul *) l1h->data; struct l1ctl_dm_est_req *est_req = (struct l1ctl_dm_est_req *) ul->payload; - printd("L1CTL_DM_EST_REQ (arfcn=%u, chan_nr=0x%02x, tsc=%u)\n", + printd("L1CTL_DM_EST_REQ %s(arfcn=%u, chan_nr=0x%02x, tsc=%u)\n", + est_req->cbch_mode ? "CBCH " : "", ntohs(est_req->h0.band_arfcn), ul->chan_nr, est_req->tsc); /* disable neighbour cell measurement of C0 TS 0 */ @@ -262,7 +263,8 @@ static void l1ctl_rx_dm_est_req(struct msgb *msg) } /* figure out which MF tasks to enable */ - l1a_mftask_set(chan_nr2mf_task_mask(ul->chan_nr, NEIGH_MODE_PM)); + l1a_mftask_set(chan_nr2mf_task_mask(ul->chan_nr, NEIGH_MODE_PM, + est_req->cbch_mode)); } /* receive a L1CTL_DM_FREQ_REQ from L23 */ diff --git a/src/target/firmware/layer1/mframe_sched.c b/src/target/firmware/layer1/mframe_sched.c index f3a6b43..0a9ff1e 100644 --- a/src/target/firmware/layer1/mframe_sched.c +++ b/src/target/firmware/layer1/mframe_sched.c @@ -198,6 +198,15 @@ static const struct mframe_sched_item mf_sdcch8_7[] = { { .sched_set = NULL } }; +static const struct mframe_sched_item mf_sdcch8_cbch[] = { + { .sched_set = NB_QUAD_FH_DL, .modulo = 51, .frame_nr = 8 }, + { .sched_set = NULL } +}; +static const struct mframe_sched_item mf_sdcch4_cbch[] = { + { .sched_set = NB_QUAD_DL, .modulo = 51, .frame_nr = 32 }, + { .sched_set = NULL } +}; + /* Measurement for MF 51 C0 */ static const struct mframe_sched_item mf_neigh_pm51_c0t0[] = { { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 0 }, @@ -327,6 +336,9 @@ static const struct mframe_sched_item *sched_set_for_task[32] = { [MF_TASK_SDCCH8_6] = mf_sdcch8_6, [MF_TASK_SDCCH8_7] = mf_sdcch8_7, + [MF_TASK_SDCCH4_CBCH] = mf_sdcch4_cbch, + [MF_TASK_SDCCH8_CBCH] = mf_sdcch8_cbch, + [MF_TASK_TCH_F_EVEN] = mf_tch_f_even, [MF_TASK_TCH_F_ODD] = mf_tch_f_odd, [MF_TASK_TCH_H_0] = mf_tch_h_0, @@ -361,6 +373,7 @@ uint8_t mframe_task2chan_nr(enum mframe_task mft, uint8_t ts) cbits = 0x04 + 1; break; case MF_TASK_SDCCH4_2: + case MF_TASK_SDCCH4_CBCH: cbits = 0x04 + 2; break; case MF_TASK_SDCCH4_3: @@ -373,6 +386,7 @@ uint8_t mframe_task2chan_nr(enum mframe_task mft, uint8_t ts) cbits = 0x08 + 1; break; case MF_TASK_SDCCH8_2: + case MF_TASK_SDCCH8_CBCH: cbits = 0x08 + 2; break; case MF_TASK_SDCCH8_3: -- 1.7.0.4

3 6

[PATCH libosmocore 0/8] Cell Broadcast (SMSCB) MS support
by Alex Badea 06 Jan '13

06 Jan '13

Hi, This a respin of my old series of patches[1], to add decoding of SMSCB messages on the MS side. The series defines a new smscb_entity, which can be fed L1 messages from a CBCH, performs reassembly, and constructs equivalent SMS Broadcast Command (RSL_MT_SMS_BC_CMD) messages for L3. I also have a follow-up patch for bb/cell_log which makes use of this functionality. Please review and consider for merging, thanks. [1] http://lists.osmocom.org/pipermail/baseband-devel/2010-November/000834.html Alex Badea (8): gsm: add skeleton smscb module smscb: add unit test for smscb_entity smscb: process Null messages smscb test: support a list of L1 messages to test smscb: add test-case for reassembling a normal message smscb: add test-case for reassembling a Schedule message smscb: implement reassembly smscb: hook into LAPDm include/Makefile.am | 1 + include/osmocom/gsm/lapdm.h | 3 + include/osmocom/gsm/smscb.h | 37 ++++++++ src/gsm/Makefile.am | 1 + src/gsm/lapdm.c | 13 +++ src/gsm/libosmogsm.map | 5 + src/gsm/smscb.c | 209 +++++++++++++++++++++++++++++++++++++++++++ tests/smscb/smscb_test.c | 118 ++++++++++++++++++++++++ tests/smscb/smscb_test.ok | 9 ++ tests/testsuite.at | 2 +- 10 files changed, 397 insertions(+), 1 deletions(-) create mode 100644 include/osmocom/gsm/smscb.h create mode 100644 src/gsm/smscb.c

3 13

[PATCH libosmocore] doxyfiles: refer paths to @srcdir@
by Alex Badea 06 Jan '13

06 Jan '13

When building out-of-srcdir, paths such as "src/gsm" will not find any source files. Since the Doxyfiles are preprocessed, we can prepend @srcdir@ to fix that. Signed-off-by: Alex Badea <vamposdecampos(a)gmail.com> --- Doxyfile.codec.in | 2 +- Doxyfile.core.in | 2 +- Doxyfile.gsm.in | 2 +- Doxyfile.vty.in | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/Doxyfile.codec.in b/Doxyfile.codec.in index fcd5122..1b0df5e 100644 --- a/Doxyfile.codec.in +++ b/Doxyfile.codec.in @@ -610,7 +610,7 @@ WARN_LOGFILE = # directories like "/usr/src/myproject". Separate the files or directories # with spaces. -INPUT = include/osmocom/codec src/codec +INPUT = @srcdir@/include/osmocom/codec @srcdir@/src/codec # This tag can be used to specify the character encoding of the source files # that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is diff --git a/Doxyfile.core.in b/Doxyfile.core.in index 18eb226..ee58f80 100644 --- a/Doxyfile.core.in +++ b/Doxyfile.core.in @@ -610,7 +610,7 @@ WARN_LOGFILE = # directories like "/usr/src/myproject". Separate the files or directories # with spaces. -INPUT = include/osmocom/core src +INPUT = @srcdir@/include/osmocom/core @srcdir/@src # This tag can be used to specify the character encoding of the source files # that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is diff --git a/Doxyfile.gsm.in b/Doxyfile.gsm.in index ab25b22..36a6ae2 100644 --- a/Doxyfile.gsm.in +++ b/Doxyfile.gsm.in @@ -610,7 +610,7 @@ WARN_LOGFILE = # directories like "/usr/src/myproject". Separate the files or directories # with spaces. -INPUT = include/osmocom/gsm include/osmocom/gsm/protocol src/gsm +INPUT = @srcdir@/include/osmocom/gsm @srcdir@/include/osmocom/gsm/protocol @srcdir@/src/gsm # This tag can be used to specify the character encoding of the source files # that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is diff --git a/Doxyfile.vty.in b/Doxyfile.vty.in index 57f19ad..527cdb2 100644 --- a/Doxyfile.vty.in +++ b/Doxyfile.vty.in @@ -610,7 +610,7 @@ WARN_LOGFILE = # directories like "/usr/src/myproject". Separate the files or directories # with spaces. -INPUT = include/osmocom/vty src/vty +INPUT = @srcdir@/include/osmocom/vty @srcdir@/src/vty # This tag can be used to specify the character encoding of the source files # that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is -- 1.7.0.4

3 2

[PATCH libosmocore] timer_test: tweak path to config.h
by Alex Badea 06 Jan '13

06 Jan '13

When building out-of-srcdir, "../../config.h" fails to reach config.h because the compiler is invoked in $builddir/tests/, not $builddir/tests/timer/. Use "../config.h" instead; this also works for in-srcdir builds. Signed-off-by: Alex Badea <vamposdecampos(a)gmail.com> --- tests/timer/timer_test.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tests/timer/timer_test.c b/tests/timer/timer_test.c index ba3127d..bb9a177 100644 --- a/tests/timer/timer_test.c +++ b/tests/timer/timer_test.c @@ -33,7 +33,7 @@ #include <osmocom/core/select.h> #include <osmocom/core/linuxlist.h> -#include "../../config.h" +#include "../config.h" static void main_timer_fired(void *data); static void secondary_timer_fired(void *data); -- 1.7.0.4

2 1

libosmocore: [PATCH] Replace obsolete automake AM_CONFIG_HEADER.
by Christian Vogel 06 Jan '13

06 Jan '13

Hi, I just setup a machine running ArchLinux which has a pretty recent automake/autoconf. libosmocore fails to build. Attached (trivial) patch fixes that. Someone with a really old toolchain/automake should check if it breaks setups we consider supported. Chris

2 1

[PATCH] Replace obsolete automake AM_CONFIG_HEADER.
by Christian Vogel 05 Jan '13

05 Jan '13

This fixes the following complaint by autoconf 2.69-1, automake 1.13.1-1. : configure.ac:80: error: 'AM_CONFIG_HEADER': this macro is obsolete. : You should use the 'AC_CONFIG_HEADERS' macro instead. : /usr/share/aclocal-1.13/obsolete-err.m4:12: AM_CONFIG_HEADER is expan : configure.ac:80: the top level Automake 1:1.11.3-1ubuntu2, autoconf 2.68-1ubuntu2 don't even emit a warning without, and work just fine with this patch. Signed-off-by: Christian Vogel <vogelchr(a)vogel.cx> --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 24ddd0c..fbc83f3 100644 --- a/configure.ac +++ b/configure.ac @@ -77,7 +77,7 @@ AC_DEFUN([CHECK_TM_INCLUDES_TM_GMTOFF], [ CHECK_TM_INCLUDES_TM_GMTOFF dnl Generate the output -AM_CONFIG_HEADER(config.h) +AC_CONFIG_HEADER(config.h) AC_ARG_ENABLE(talloc, [AS_HELP_STRING( -- 1.8.1 --VS++wcV0S1rZb1Fb--

1 0

[PATCH] layer23 cell_log: log CBCH cell info
by Alex Badea 05 Jan '13

05 Jan '13

If System Information contained CBCH channel description, tune to it and log SMSCB messages with a Geographical Scope of Cell Wide (Immediate) -- these are typically used for "Cell Info Display". The CBCH timeout is set to a generous 8 seconds; this is because we need 4 frames for reassembly, we usually miss the first, and we might hit a burst of Null SMSCB messages. By default this feature is disabled; it can be enabled via a new '-B' or '--cbch' commandline argument. Signed-off-by: Alex Badea <vamposdecampos(a)gmail.com> --- This patch requires the CBCH DM flag patch[1], and the libosmocore patch series[2] for SMSCB reassembly. [1] http://lists.osmocom.org/pipermail/baseband-devel/2013-January/003612.html [2] http://lists.osmocom.org/pipermail/baseband-devel/2013-January/003642.html src/host/layer23/src/misc/app_cell_log.c | 11 +++- src/host/layer23/src/misc/cell_log.c | 114 +++++++++++++++++++++++++++++- 2 files changed, 121 insertions(+), 4 deletions(-) diff --git a/src/host/layer23/src/misc/app_cell_log.c b/src/host/layer23/src/misc/app_cell_log.c index a7f42c3..5ed1d6b 100644 --- a/src/host/layer23/src/misc/app_cell_log.c +++ b/src/host/layer23/src/misc/app_cell_log.c @@ -45,6 +45,7 @@ extern uint16_t (*band_range)[][2]; char *logname = "/var/log/osmocom.log"; int RACH_MAX = 2; +int do_cbch = 0; int _scan_work(struct osmocom_ms *ms) { @@ -103,7 +104,8 @@ static int l23_getopt_options(struct option **options) #endif {"gps", 1, 0, 'g'}, {"baud", 1, 0, 'b'}, - {"arfcns", 1, 0, 'A'} + {"arfcns", 1, 0, 'A'}, + {"cbch", 1, 0, 'B'}, }; *options = opts; @@ -162,6 +164,8 @@ static int l23_cfg_print_help() printf(" -f --gps DEVICE /dev/ttyACM0. GPS serial device.\n"); printf(" -b --baud BAUDRAT The baud rate of the GPS device\n"); printf(" -A --arfcns ARFCNS The list of arfcns to be monitored\n"); + printf(" -B --cbch Scan and log info from the CBCH\n"); + return 0; } @@ -224,6 +228,9 @@ static int l23_cfg_handle(int c, const char *optarg) parse_band_range((char*)optarg); printf("New frequencies range: %s\n", print_band_range(*band_range, buf, sizeof(buf))); break; + case 'B': + do_cbch = 1; + break; } return 0; @@ -234,7 +241,7 @@ cmd_line_error: static struct l23_app_info info = { .copyright = "Copyright (C) 2010 Andreas Eversberg\n", - .getopt_string = "g:p:l:r:nf:b:A:", + .getopt_string = "g:p:l:r:nf:b:A:B", .cfg_supported = l23_cfg_supported, .cfg_getopt_opt = l23_getopt_options, .cfg_handle_opt = l23_cfg_handle, diff --git a/src/host/layer23/src/misc/cell_log.c b/src/host/layer23/src/misc/cell_log.c index 7340dcb..41a34fd 100644 --- a/src/host/layer23/src/misc/cell_log.c +++ b/src/host/layer23/src/misc/cell_log.c @@ -26,6 +26,8 @@ #include <stdlib.h> #include <time.h> #include <errno.h> +#include <ctype.h> +#include <arpa/inet.h> #include <l1ctl_proto.h> @@ -35,6 +37,7 @@ #include <osmocom/core/msgb.h> #include <osmocom/gsm/gsm_utils.h> #include <osmocom/gsm/protocol/gsm_04_08.h> +#include <osmocom/gsm/protocol/gsm_03_41.h> #include <osmocom/gsm/rsl.h> #include <osmocom/bb/common/l1ctl.h> @@ -47,6 +50,7 @@ #define READ_WAIT 2, 0 #define RACH_WAIT 0, 900000 +#define CBCH_WAIT 8, 0 #define MIN_RXLEV_DBM -106 #define MAX_DIST 2000 @@ -55,6 +59,7 @@ enum { SCAN_STATE_SYNC, SCAN_STATE_READ, SCAN_STATE_RACH, + SCAN_STATE_CBCH, }; /* ranges of bands */ @@ -89,6 +94,7 @@ static int rach_count; static FILE *logfp = NULL; extern char *logname; extern int RACH_MAX; +extern int do_cbch; static struct gsm48_sysinfo sysinfo; @@ -115,6 +121,7 @@ struct rach_ref { static void start_sync(void); static void start_rach(void); +static void start_cbch(void); static void start_pm(void); static void log_gps(void) @@ -228,6 +235,11 @@ static void timeout_cb(void *arg) rach_count++; start_rach(); break; + case SCAN_STATE_CBCH: + LOGP(DRR, LOGL_INFO, "Timeout on CBCH\n"); + l1ctl_tx_dm_rel_req(ms); + start_sync(); + break; } } @@ -245,6 +257,35 @@ static void start_timer(int sec, int micro) osmo_timer_schedule(&timer, sec, micro); } +static void start_cbch(void) +{ + struct gsm48_sysinfo *s = &sysinfo; + int res; + + if (!do_cbch) { + res = -1; + } else if (!s->chan_nr) { + LOGP(DRR, LOGL_DEBUG, "No CBCH description in sysinfo\n"); + res = -1; + } else if (s->h) { + res = l1ctl_tx_dm_est_req_h1(ms, + s->maio, s->hsn, s->hopping, s->hopp_len, + s->chan_nr, s->tsc, + GSM48_CMODE_SIGN, 0, L1CTL_DM_F_CBCH); + } else { + res = l1ctl_tx_dm_est_req_h0(ms, s->arfcn, s->chan_nr, s->tsc, + GSM48_CMODE_SIGN, 0, L1CTL_DM_F_CBCH); + } + + if (res < 0) { + start_sync(); + return; + } + + state = SCAN_STATE_CBCH; + start_timer(CBCH_WAIT); +} + static void start_rach(void) { struct gsm48_sysinfo *s = &sysinfo; @@ -254,7 +295,7 @@ static void start_rach(void) if (rach_count == RACH_MAX) { log_sysinfo(); - start_sync(); + start_cbch(); return; } @@ -433,7 +474,7 @@ static int ta_result(uint8_t ta) } log_sysinfo(); - start_sync(); + start_cbch(); return 0; } @@ -737,6 +778,70 @@ int chan_conf(struct osmocom_ms *ms, struct msgb *msg) return 0; } +static int sms_bc_cmd(struct osmocom_ms *ms, struct msgb *msg) +{ + struct abis_rsl_cchan_hdr *ch = msgb_l2(msg); + struct tlv_parsed tv; + struct rsl_ie_cb_cmd_type *cmd_type; + struct gsm341_ms_message *cbmsg; + unsigned int cbmsglen; + char buf[256], *p; + + DEBUGP(DRSL, "RSLms SMS BC CMD chan_nr=0x%02x\n", + ch->chan_nr); + + rsl_tlv_parse(&tv, ch->data, msgb_l2len(msg) - sizeof(*ch)); + if (!TLVP_PRESENT(&tv, RSL_IE_SMSCB_MSG) || + !TLVP_PRESENT(&tv, RSL_IE_CB_CMD_TYPE)) { + LOGP(DRR, LOGL_ERROR, "SMS_BC_CMD missing mandatory IEs\n"); + return -EINVAL; + } + + cmd_type = (struct rsl_ie_cb_cmd_type *) TLVP_VAL(&tv, RSL_IE_CB_CMD_TYPE); + cbmsg = (struct gsm341_ms_message *) TLVP_VAL(&tv, RSL_IE_SMSCB_MSG); + cbmsglen = TLVP_LEN(&tv, RSL_IE_SMSCB_MSG); + if (cbmsglen < sizeof(*cbmsg)) { + LOGP(DRR, LOGL_ERROR, "RSL_IE_SMSCB_MSG too short\n"); + return -EINVAL; + } + + if (cmd_type->command != RSL_CB_CMD_TYPE_NORMAL) + return 0; + + gsm_7bit_decode(buf, cbmsg->data, cbmsglen - sizeof(*cbmsg)); + for (p = buf; *p; p++) + if (!isprint(*p)) + *p = '_'; + + LOGP(DSUM, LOGL_INFO, "Cell info: gs=%d code=%d update=%d id=%d text=\"%s\"\n", + cbmsg->serial.gs, + GSM341_MSG_CODE(cbmsg), + cbmsg->serial.update, + ntohs(cbmsg->msg_id), + buf); + + if (cbmsg->serial.gs != GSM341_GS_CELL_WIDE_IMMED) + return 0; + + LOGFILE("[cbch]\n"); + LOGFILE("arfcn %d\n", sysinfo.arfcn); + LOGFILE("gs %d code %d update %d msg_id %d page %d numpages %d\n", + cbmsg->serial.gs, + GSM341_MSG_CODE(cbmsg), + cbmsg->serial.update, + ntohs(cbmsg->msg_id), + cbmsg->page.current, cbmsg->page.total); + LOGFILE("text \"%s\"\n", buf); + LOGFILE("\n"); + LOGFLUSH(); + + l1ctl_tx_dm_rel_req(ms); + stop_timer(); + + start_sync(); + return 0; +} + static int rcv_cch(struct osmocom_ms *ms, struct msgb *msg) { struct abis_rsl_cchan_hdr *ch = msgb_l2(msg); @@ -751,6 +856,11 @@ static int rcv_cch(struct osmocom_ms *ms, struct msgb *msg) msgb_free(msg); return rc; } + if (state == SCAN_STATE_CBCH && msg_type == RSL_MT_SMS_BC_CMD) { + rc = sms_bc_cmd(ms, msg); + msgb_free(msg); + return rc; + } LOGP(DRSL, LOGL_NOTICE, "RSLms message unhandled\n"); msgb_free(msg); -- 1.7.0.4

1 0

[PATCH] core/msgb: Change return value of msgb_pull to the start of pulled header
by Sylvain Munaut 05 Jan '13

05 Jan '13

From: Sylvain Munaut <tnt(a)246tNt.com> Currently msgb_pull returns a pointer to the new start of msgb, which is pretty counter intuitive and when using msgb_pull is often annoying. For eg, the msgb_pull_u{8,16,32} were previously "fixed" for this quirk in a previous commit. The msgb_pull_l2h in lapdm is also wrong because of this, same for code in osmocom-bb loader. AFAICT, the current users of msgb_pull either don't care about the return value, or expect it to be a pointer to the pulled header and not the new start of msgb (and so are currently buggy). Without this patch, you have things like: struct foo *bar = msgb_pull(msg, sizeof(struct foo)) - sizeof(struct foo) With the patch, you have: struct foo *bar = msgb_pull(msg, sizeof(struct foo)); which is IMHO a much better style. Signed-off-by: Sylvain Munaut <tnt(a)246tNt.com> --- include/osmocom/core/msgb.h | 14 ++++++++------ 1 files changed, 8 insertions(+), 6 deletions(-) diff --git a/include/osmocom/core/msgb.h b/include/osmocom/core/msgb.h index a1939ab..4a72f2d 100644 --- a/include/osmocom/core/msgb.h +++ b/include/osmocom/core/msgb.h @@ -287,16 +287,18 @@ static inline unsigned char *msgb_push(struct msgb *msgb, unsigned int len) /*! \brief remove (pull) a header from the front of the message buffer * \param[in] msgb message buffer * \param[in] len number of octets to be pulled - * \returns pointer to new start of msgb + * \returns pointer to header that's been pulled (i.e. previous start of msgb) * * This function moves the \a data pointer of the \ref msgb further back * in the message, thereby shrinking the size of the message by \a len * bytes. */ static inline unsigned char *msgb_pull(struct msgb *msgb, unsigned int len) -{ +{ + unsigned char *tmp = msgb->data; msgb->len -= len; - return msgb->data += len; + msgb->data += len; + return tmp; } /*! \brief remove uint8 from front of message @@ -305,7 +307,7 @@ static inline unsigned char *msgb_pull(struct msgb *msgb, unsigned int len) */ static inline uint8_t msgb_pull_u8(struct msgb *msgb) { - uint8_t *space = msgb_pull(msgb, 1) - 1; + uint8_t *space = msgb_pull(msgb, 1); return space[0]; } /*! \brief remove uint16 from front of message @@ -314,7 +316,7 @@ static inline uint8_t msgb_pull_u8(struct msgb *msgb) */ static inline uint16_t msgb_pull_u16(struct msgb *msgb) { - uint8_t *space = msgb_pull(msgb, 2) - 2; + uint8_t *space = msgb_pull(msgb, 2); return space[0] << 8 | space[1]; } /*! \brief remove uint32 from front of message @@ -323,7 +325,7 @@ static inline uint16_t msgb_pull_u16(struct msgb *msgb) */ static inline uint32_t msgb_pull_u32(struct msgb *msgb) { - uint8_t *space = msgb_pull(msgb, 4) - 4; + uint8_t *space = msgb_pull(msgb, 4); return space[0] << 24 | space[1] << 16 | space[2] << 8 | space[3]; } -- 1.7.8.6

1 0

fix of osmoload, flashing c155 works
by jolly 05 Jan '13

05 Jan '13

hi, just fixed the issue from 29c3, where flashing of phones did not work anymore. if no one complains, i will apply it. it is also possible to flash c155 phones. the original compal boot loader will start firmware at 0x20000 instead of 0x2000 (c123), so i modified the linker scripts for compal_e99. i am not sure, if all c155 phones behave the same. to check this, i dumped some pages of the flash memory: run the loader: $ host/osmocon/osmocon -p /dev/ttyUSB0 -m c155 target/firmware/board/compal_e99/loader.compalram.bin start the phone and dump some flash: $ host/osmocon/osmoload memdump 0x000000 0x30000 dump a hexdump of that dump showed me where the actual firmware starts: ... 0000800 4f42 544f 392e 2e30 3530 0000 0000 0000 0000810 3031 3330 0101 0000 ffff ffff ffff ffff 0000820 ffff ffff ffff ffff ffff ffff ffff ffff * 0020000 4f43 4544 392e 2e30 3130 0000 0000 0000 0020010 4c46 5845 392e 2e30 3130 302e 0031 0000 0020020 5352 4b50 392e 2e30 3130 302e 0031 0000 ... i would like to know, if this is true for other c155 phones. regards, andreas

3 6

No r-gsm cell shown in mobile app
by Karsten Krummeich 05 Jan '13

05 Jan '13

Hi, I'm thinking about why the mobile app don't show me the German GSM-R (MCC: 262, MNC: 10) cells they are around me. The rssi app shows me the cells (e. g. ARFCN: 957 and 961). I'm using the sylvain/testing branch and I am searching for more details in the source code and found in settings.c that the r gsm band are enabled and in the freq_list. Can someone tell me another point for searching in source? Thanks in advance. Best regards. kasio

3 4

[PATCH] Generate Compal E99 binaries for loader and flash locations
by Andreas Eversberg 05 Jan '13

05 Jan '13

Loader binaries start at 0x20000 at flash memory. This is where the Compal loader jumps to. Flash binaries start at 0x30000 at flash memory. --- src/target/firmware/Makefile | 12 +- src/target/firmware/board/compal_e99/flash.lds | 134 +++++++++++++++++++++ src/target/firmware/board/compal_e99/loader.lds | 147 +++++++++++++++++++++++ 3 files changed, 288 insertions(+), 5 deletions(-) create mode 100644 src/target/firmware/board/compal_e99/flash.lds create mode 100644 src/target/firmware/board/compal_e99/loader.lds diff --git a/src/target/firmware/Makefile b/src/target/firmware/Makefile index a71eef6..c76bcd0 100644 --- a/src/target/firmware/Makefile +++ b/src/target/firmware/Makefile @@ -66,11 +66,13 @@ compal_e86_ENVIRONMENTS=$(compal_COMMON_ENVIRONMENTS) # Compal E99 compal_e99_OBJS=$(compal_COMMON_OBJS) board/compal_e99/init.o battery/dummy.o $(FB_e99_OBJS) -compal_e99_ENVIRONMENTS=$(compal_COMMON_ENVIRONMENTS) +compal_e99_ENVIRONMENTS=$(compal_COMMON_ENVIRONMENTS) e99loader e99flash e99loader_LDS=board/compal_e99/loader.lds -e99loader_OBJS=board/compal/header.o +e99loader_OBJS=board/compal/start.rom.o board/compal/header.o board/compal/exceptions_redirect.o + e99flash_LDS=board/compal_e99/flash.lds +e99flash_OBJS=board/compal/start.rom.o board/compal/header.o board/compal/exceptions_redirected.o board/compal/handlers.o # Sony Ericsson J100 (made by Compal) @@ -99,10 +101,10 @@ ANY_APP_LIBS+=calypso/libcalypso.a layer1/liblayer1.a lib/libmini.a comm/libcomm -include Makefile.inc # Uncomment this line if you want to enable Tx (Transmit) Support. -#CFLAGS += -DCONFIG_TX_ENABLE +CFLAGS += -DCONFIG_TX_ENABLE # Uncomment this line if you want to write to flash. -#CFLAGS += -DCONFIG_FLASH_WRITE +CFLAGS += -DCONFIG_FLASH_WRITE # Uncomment this line if you want to write to flash, including the bootloader. -#CFLAGS += -DCONFIG_FLASH_WRITE_LOADER +CFLAGS += -DCONFIG_FLASH_WRITE_LOADER diff --git a/src/target/firmware/board/compal_e99/flash.lds b/src/target/firmware/board/compal_e99/flash.lds new file mode 100644 index 0000000..1cf189f --- /dev/null +++ b/src/target/firmware/board/compal_e99/flash.lds @@ -0,0 +1,134 @@ +/* + * Linker script for flashed applications on the Compal E99 + * + * This script creates a binary that can be linked at 0xFFFF, starting + * with the second flash page. This is what a phone application or + * pure layer1 device uses. + * + * XXX: interrupts? + * + */ +OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm") +OUTPUT_ARCH(arm) +ENTRY(_start) +MEMORY +{ + LOADR (rx) : ORIGIN = 0x00000000, LENGTH = 0x30000 + /* 2 MBytes of external flash memory (minus loader) */ + FLASH (rx) : ORIGIN = 0x00030000, LENGTH = 0x1F0000 + /* 256 kBytes of internal zero-waitstate sram */ + IRAM (rw) : ORIGIN = 0x00800000, LENGTH = 0x040000 + /* 256 kBytes of external slow sram */ + ERAM (rw) : ORIGIN = 0x01000000, LENGTH = 0x040000 +} +SECTIONS +{ + /* entrypoint */ + .text.start : { + PROVIDE(_start = .); + KEEP(*(.text.start)) + *(.text.start) + } > FLASH + + /* exception vectors from 0x80001c to 0x800034 */ + .text.exceptions 0x80001c : { + KEEP(*(.text.exceptions)) + * (.text.exceptions) + . = ALIGN(4); + } > IRAM AT> FLASH + PROVIDE(_exceptions = LOADADDR(.text.exceptions)); + + /* code */ + .text : { + /* regular code */ + *(.text*) + /* gcc voodoo */ + *(.glue_7t) *(.glue_7) *(.vfp11_veneer) *(.v4_bx) + } > FLASH + PROVIDE(_text_start = ADDR(.text)); + PROVIDE(_text_end = ADDR(.text) + SIZEOF(.text)); + + /* constructor pointers */ + .ctors : { + /* ctor count */ + LONG(SIZEOF(.ctors) / 4 - 2) + /* ctor pointers */ + KEEP(*(SORT(.ctors))) + /* end of list */ + LONG(0) + } > FLASH + PROVIDE(_ctor_start = LOADADDR(.ctors)); + PROVIDE(_ctor_end = LOADADDR(.ctors) + SIZEOF(.ctors)); + + /* destructor pointers */ + .dtors : { + /* dtor count */ + LONG(SIZEOF(.dtors) / 4 - 2) + /* dtor pointers */ + KEEP(*(SORT(.dtors))) + /* end of list */ + LONG(0) + } > FLASH + PROVIDE(_dtor_start = LOADADDR(.dtors)); + PROVIDE(_dtor_end = LOADADDR(.dtors) + SIZEOF(.dtors)); + + /* read-only data */ + .rodata : { + *(.rodata*) + } > FLASH + PROVIDE(_rodata_start = ADDR(.rodata)); + PROVIDE(_rodata_end = ADDR(.rodata) + SIZEOF(.rodata)); + + /* pic offset tables */ + .got : { + . = ALIGN(4); + *(.got) + *(.got.plt) *(.igot.plt) *(.got) *(.igot) + . = ALIGN(4); + } > FLASH + PROVIDE(_got_start = ADDR(.got)); + PROVIDE(_got_end = ADDR(.got) + SIZEOF(.got)); + + /* reserved ram */ + .compal.reservedram 0x800000 (NOLOAD) : { + . = 0xff; + } > IRAM + + /* initialized data */ + .data : AT (LOADADDR(.got) + SIZEOF(.got)) { + . = ALIGN(4); + *(.data) + . = ALIGN(4); + } > IRAM + PROVIDE(__data_start = LOADADDR(.data)); + PROVIDE(__data_end = LOADADDR(.data) + SIZEOF(.data)); + PROVIDE(_data_start = ADDR(.data)); + PROVIDE(_data_end = ADDR(.data) + SIZEOF(.data)); + + /* ram code */ + .ramtext : AT (LOADADDR(.data) + SIZEOF(.data)) { + . = ALIGN(4); + *(.ramtext) + . = ALIGN(4); + } > IRAM + PROVIDE(__ramtext_start = LOADADDR(.ramtext)); + PROVIDE(__ramtext_end = LOADADDR(.ramtext) + SIZEOF(.ramtext)); + PROVIDE(_ramtext_start = ADDR(.ramtext)); + PROVIDE(_ramtext_end = ADDR(.ramtext) + SIZEOF(.ramtext)); + + /* uninitialized data */ + .bss (NOLOAD) : { + . = ALIGN(4); + *(.bss) + . = ALIGN(4); + } > IRAM + PROVIDE(__bss_start = ADDR(.bss)); + PROVIDE(__bss_end = ADDR(.bss) + SIZEOF(.bss)); + PROVIDE(_bss_start = __bss_start); + PROVIDE(_bss_end = __bss_end); + + /* end of image */ + . = ALIGN(4); + _end = .; + PROVIDE(end = .); +} diff --git a/src/target/firmware/board/compal_e99/loader.lds b/src/target/firmware/board/compal_e99/loader.lds new file mode 100644 index 0000000..bb117a8 --- /dev/null +++ b/src/target/firmware/board/compal_e99/loader.lds @@ -0,0 +1,147 @@ +/* + * Linker script for flashed loader on the Compal E99 + * + * This script creates a binary that can replace a standard firmware + * located at 0x20000. It works in conjunction with the compal ramloader. + * + * The interrupt vectors and start address are at known, fixed offsets. + * + */ +OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm") +OUTPUT_ARCH(arm) +ENTRY(_start) +MEMORY +{ + /* 2 MBytes of external flash memory */ + FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0x200000 + /* 256 kBytes of internal zero-waitstate sram */ + IRAM (rw) : ORIGIN = 0x00800000, LENGTH = 0x040000 + /* 256 kBytes of external slow sram */ + ERAM (rw) : ORIGIN = 0x01000000, LENGTH = 0x040000 +} +SECTIONS +{ + /* Provide symbols for the compal loader */ + .compal.loader 0x00000000 (NOLOAD) : { + _compal_loader_start = .; + . = 0x2000; + _compal_loader_end = .; + } > FLASH + + /* Compal-style image header */ + .compal.header 0x00020000 : { + _compal_header_start = .; + KEEP(*(.compal.header)) + *(.compal.header) + . = 0xA0; + _compal_header_end = .; + } > FLASH + + /* Compal-style vector table */ + .compal.vectors 0x000200A0 : { + PROVIDE(_exceptions = .); + KEEP(*(.text.exceptions)) + *(.text.exceptions) + } > FLASH + + /* Compal-style entry point */ + .text.start 0x000200F8 : { + PROVIDE(_start = .); + KEEP(*(.text.start)) + *(.text.start) + } > FLASH + + /* code */ + .text : { + /* regular code */ + *(.text*) + /* gcc voodoo */ + *(.glue_7t) *(.glue_7) *(.vfp11_veneer) *(.v4_bx) + } > FLASH + PROVIDE(_text_start = ADDR(.text)); + PROVIDE(_text_end = ADDR(.text) + SIZEOF(.text)); + + /* constructor pointers */ + .ctors : { + /* ctor count */ + LONG(SIZEOF(.ctors) / 4 - 2) + /* ctor pointers */ + KEEP(*(SORT(.ctors))) + /* end of list */ + LONG(0) + } > FLASH + PROVIDE(_ctor_start = LOADADDR(.ctors)); + PROVIDE(_ctor_end = LOADADDR(.ctors) + SIZEOF(.ctors)); + + /* destructor pointers */ + .dtors : { + /* dtor count */ + LONG(SIZEOF(.dtors) / 4 - 2) + /* dtor pointers */ + KEEP(*(SORT(.dtors))) + /* end of list */ + LONG(0) + } > FLASH + PROVIDE(_dtor_start = LOADADDR(.dtors)); + PROVIDE(_dtor_end = LOADADDR(.dtors) + SIZEOF(.dtors)); + + /* read-only data */ + .rodata : { + *(.rodata*) + } > FLASH + PROVIDE(_rodata_start = ADDR(.rodata)); + PROVIDE(_rodata_end = ADDR(.rodata) + SIZEOF(.rodata)); + + /* pic offset tables */ + .got : { + . = ALIGN(4); + *(.got) + *(.got.plt) *(.igot.plt) *(.got) *(.igot) + . = ALIGN(4); + } > FLASH + PROVIDE(_got_start = ADDR(.got)); + PROVIDE(_got_end = ADDR(.got) + SIZEOF(.got)); + + /* reserved ram */ + .compal.reservedram 0x800000 (NOLOAD) : { + . = 0xff; + } > IRAM + + /* initialized data */ + .data : AT (LOADADDR(.got) + SIZEOF(.got)) { + . = ALIGN(4); + *(.data) + . = ALIGN(4); + } > IRAM + PROVIDE(__data_start = LOADADDR(.data)); + PROVIDE(__data_end = LOADADDR(.data) + SIZEOF(.data)); + PROVIDE(_data_start = ADDR(.data)); + PROVIDE(_data_end = ADDR(.data) + SIZEOF(.data)); + + /* ram code */ + .ramtext : AT (LOADADDR(.data) + SIZEOF(.data)) { + . = ALIGN(4); + *(.ramtext) + . = ALIGN(4); + } > IRAM + PROVIDE(__ramtext_start = LOADADDR(.ramtext)); + PROVIDE(__ramtext_end = LOADADDR(.ramtext) + SIZEOF(.ramtext)); + PROVIDE(_ramtext_start = ADDR(.ramtext)); + PROVIDE(_ramtext_end = ADDR(.ramtext) + SIZEOF(.ramtext)); + + /* uninitialized data */ + .bss (NOLOAD) : { + . = ALIGN(4); + *(.bss) + . = ALIGN(4); + } > IRAM + PROVIDE(__bss_start = ADDR(.bss)); + PROVIDE(__bss_end = ADDR(.bss) + SIZEOF(.bss)); + PROVIDE(_bss_start = __bss_start); + PROVIDE(_bss_end = __bss_end); + + /* end of image */ + . = ALIGN(4); + _end = .; + PROVIDE(end = .); +} -- 1.7.3.4 --------------060605070405050509030107--

1 0

[PATCH] Fix: Correctly handle return value of msgb_pull()
by Andreas Eversberg 05 Jan '13

05 Jan '13

Now it is possible to use osmoload again to flash. Flashing was successfully tested with c123 and c155. --- src/host/osmocon/osmoload.c | 2 +- src/target/firmware/apps/loader/main.c | 7 +++++-- src/target/firmware/apps/loader_mtk/main.c | 4 ++-- 3 files changed, 8 insertions(+), 5 deletions(-) diff --git a/src/host/osmocon/osmoload.c b/src/host/osmocon/osmoload.c index 9b64935..e83f98a 100644 --- a/src/host/osmocon/osmoload.c +++ b/src/host/osmocon/osmoload.c @@ -307,7 +307,7 @@ loader_handle_reply(struct msgb *msg) { length = msgb_pull_u8(msg); crc = msgb_pull_u16(msg); address = msgb_pull_u32(msg); - data = msgb_pull(msg, length); + data = msgb_pull(msg, length) - length; break; case LOADER_MEM_WRITE: length = msgb_pull_u8(msg); diff --git a/src/target/firmware/apps/loader/main.c b/src/target/firmware/apps/loader/main.c index 50a39dd..fd07d0f 100644 --- a/src/target/firmware/apps/loader/main.c +++ b/src/target/firmware/apps/loader/main.c @@ -273,7 +273,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) crc = msgb_pull_u16(msg); address = msgb_pull_u32(msg); - data = msgb_pull(msg, nbytes); + data = msgb_pull(msg, nbytes) - nbytes; mycrc = osmo_crc16(0, data, nbytes); @@ -391,7 +391,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) chip = msgb_pull_u8(msg); address = msgb_pull_u32(msg); - data = msgb_pull(msg, nbytes); + data = msgb_pull(msg, nbytes) - nbytes; mycrc = osmo_crc16(0, data, nbytes); @@ -439,6 +439,9 @@ static void key_handler(enum key_codes code, enum key_states state) puts("Resetting due to keypress.\n"); device_reset(); break; + case KEY_MENU: + device_jump((void *)0x10000); + break; default: break; } diff --git a/src/target/firmware/apps/loader_mtk/main.c b/src/target/firmware/apps/loader_mtk/main.c index 7748dc4..3a12d27 100644 --- a/src/target/firmware/apps/loader_mtk/main.c +++ b/src/target/firmware/apps/loader_mtk/main.c @@ -213,7 +213,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) crc = msgb_pull_u16(msg); address = msgb_pull_u32(msg); - data = msgb_pull(msg, nbytes); + data = msgb_pull(msg, nbytes) - nbytes; mycrc = osmo_crc16(0, data, nbytes); @@ -331,7 +331,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) chip = msgb_pull_u8(msg); address = msgb_pull_u32(msg); - data = msgb_pull(msg, nbytes); + data = msgb_pull(msg, nbytes) - nbytes; mycrc = osmo_crc16(0, data, nbytes); -- 1.7.3.4 --------------060605070405050509030107 Content-Type: text/plain; name="0001-Generate-Compal-E99-binaries-for-loader-and-flash-lo.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0001-Generate-Compal-E99-binaries-for-loader-and-flash-lo.pa"; filename*1="tch"

1 0

baseband-devel unsubscribe notification
by mailman-bounces＠lists.osmocom.org 05 Jan '13

05 Jan '13

osmocom(a)slewe.com has been removed from baseband-devel.

1 0

OsmoDevCon 2013 brainstorming
by Harald Welte 04 Jan '13

04 Jan '13

Hi all, as the year 2012 has already ended or will soon end depending on your timezone, it might be a good occasion to start thinking of an OsmoDevCon 2013. I personally percevied OsmoDevCon 2012 as a big success, and it was fun to bring everyone together. Generally, I prefer to keep the spirit of an invitation-only developer+contributor-only event of those involved in Osmocom. At the same time, I would consider it a good idea to add a one day user-conference to the schedule, where we try to get interested users up to speed with the various projects, possibly including some workshops and the like. So schedule-wise, I would suggest something like: * one day user conference * two day developer/contributor event * optionally: 1-2 "hacking days". The concept of "hacking days" has proven to be quite useful for the netfilter project in the past (Pablo and I can acknowledge to that fact). I'm not sure how many people would be able to spend even more days of their schedule, but even if it's a much smaller group it would still be useful, IMHO. I'd like you to 1) provide feedback on the ideas about the one-day user event and the hacking days 2) consider whether late march (like 2012) would be a good schedule again 3) what we can improve from the last event In terms of improvements, I so far have noted down: * larger venue needs to be found * complaints about the venue not having sufficient heating Venue-wise, I would again suggest to hold it in Berlin, as it's reasonbly well connected, has lots of low-cost flights to it, accomodation is not too expensive and holger/me/sysmocom can take care of local organization related activities. Hoewver, if somebody has a strong opinion against berlin _and_ is willing to organize it, I'm not completely against another venue. Regards and happy new year, 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)

4 7

linking sdr trx with osmo-bts/openbsc
by jolly 03 Jan '13

03 Jan '13

hi thomas, i saw your work for your master of science. i must say: congratulations! it really brings both openbts and openbsc projects together. it allows to use both sdr and real bts together in one network. as shown at the chaos communication congress (29c3), sylvain presented a compal phone with firmware to turn it into a trx for openbts. with your code, it is possible to use it with openbsc. this is something i aimed at too. i like to know if your work is (only) a proof of concept or something that could be used in a productive environment. i would help to review the changes to osmo-bts and help to get them merged to the current master branch. iirc, there are just some fixes and minor issues to solve. i already had planed a similar approach: but instead of using source from openbts, i wanted to do scheduling and coding/fec inside osmo-bts. code from libosmocore could be used for that. instead of using the device to the femto-dsp as an interface, i wanted to add the trx manager's udp interface to osmo-bts code. this way it would not require an additional process to run a trx with osmo-bts. special things regarding to the trx could be configured with the osmo-bts' config. as some guys at the 29c3 might have noticed, i was a little shocked when i read about your work. i was highly motivated to do a work that i found it was already done, so my motivation dropped to zero. i would like to apologize for my bad mood at the congress. best regards, andreas

2 1

[PATCH] Custom range in cell_log
by Dario Lombardo 02 Jan '13

02 Jan '13

Hi guys Please find attached a patch to cell_log that allows a user to specify a custom frequency range instead of the standard one. In the past I've done the same job changing the code by hand and recompiling, but a command line switch is more feasible. This is useful when one wants to monitor a subset of arfcns (like in GSM900) or even a single one. Any comment appreciated. Dario.

2 3

[PATCH] l23 sysinfo: defer SI4 CBCH mobile allocation until SI1 is received
by Alex Badea 02 Jan '13

02 Jan '13

When parsing SI4, there's a check and a log message saying that CBCH MA is ignored until SI1 is received. Then the MA is decoded anyway -- incorrectly -- such that it remains incorrect even after receiving the next SI1. Fix that with an "else". Signed-off-by: Alex Badea <vamposdecampos(a)gmail.com> --- src/host/layer23/src/common/sysinfo.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/host/layer23/src/common/sysinfo.c b/src/host/layer23/src/common/sysinfo.c index 2816c26..b42bd65 100644 --- a/src/host/layer23/src/common/sysinfo.c +++ b/src/host/layer23/src/common/sysinfo.c @@ -753,6 +753,7 @@ short_read: LOGP(DRR, LOGL_NOTICE, "Ignoring CBCH allocation of " "SYSTEM INFORMATION 4 until SI 1 is " "received.\n"); + } else { gsm48_decode_mobile_alloc(s->freq, data + 2, data[1], s->hopping, &s->hopp_len, 1); } -- 1.7.0.4

2 1

Potential bug / problematic code in gsm411_rx_rl_data()
by Bhaskar11 02 Jan '13

02 Jan '13

In gsm411_sms.c the function gsm411_rx_rl_data receives "struct gsm48_hdr *gh" as input then in very first line typecasts the pointer to "struct gsm411_rp_hdr *rp_data" to access its "data" field. struct gsm411_rp_hdr *rp_data = (struct gsm411_rp_hdr*)&gh->data; But the two header structures have their "data" fields offset by one byte as in: struct gsm411_rp_hdr { > uint8_t len; > uint8_t msg_type; > uint8_t msg_ref; > uint8_t data[0]; > } __attribute__ ((packed)); > > struct gsm48_hdr { > uint8_t proto_discr; > uint8_t msg_type; > uint8_t data[0]; > } __attribute__((packed)); Obviously this displacement has been compensated for elsewhere in the code as the application works. But this seems to be inadvertent. And if it is deliberate, it is risky programming practice and could create problems later on. Request you to correct and update suitably. Thanks. B.

2 1

Re: 29c3 youtube video
by Luca Bongiorni 02 Jan '13

02 Jan '13

I perfectly understand and agree about being reluctant to publish code that could be used for malicious purposes. I was talking more about what Harald suggested: a public/private git repo related with Layers implementation into the MS. Cheers, Luca > Currently there is no commercial activity going on. and tool mostly contain testing tools like Multiple IMSI Detach .Identity impersonation , channel hijacking like one presented in this 29C3. Channel DOS. more issue is if we publish such tools we might get in trouble from Government and also from telecom Operator for creating such tools. for same purpose we didnt published those tools. its more like publishing complete sniffing app for GSM with all codec support. > > currently we shall publish l1 l2 l3 app on target code soon when code cleaning will be completed. but dont get time as code is having multiple changes and uses library from different osmocom git hosted locally. > > > about publishing tools and research papers we shall do it after total research is complete. > > and reason that its taking too much time is am single person who can do technical work and coding rest team is more on core telecom network security. > > thats major issue in completing research . > > > On Wed, Jan 2, 2013 at 10:07 AM, <luca.bongiorni1(a)studenti.unimi.it> wrote: > So, if I may ask, since you are NOT having anykind of commercial activity related with osmocom's tools and is more than one year that you are asking for technical explanations over this ml/irc... Why u didn't publish yet the sources/results of your researches into a public repo as Harald suggested? > > Cheers, > Luca > Sent from my Fuffaphone® > From: Akib Sayyed <akibsayyed(a)gmail.com> > Sender: baseband-devel-bounces(a)lists.osmocom.org > Date: Wed, 02 Jan 2013 08:36:46 +0300 > To: Luca Bongiorni<luca.bongiorni1(a)studenti.unimi.it> > Cc: <baseband-devel(a)lists.osmocom.org>; Harald Welte<laforge(a)gnumonks.org> > Subject: Re: 29c3 youtube video > > Damn typo mistake > On Jan 2, 2013 8:35 AM, "Akib Sayyed" <akibsayyed(a)gmail.com> wrote: > > > > Currently we are not in production stage. > > We are more focused on buying own stack or buying chipset with compatible stack as there is no gprs/edge/3g suppprt in osmocom. > > Our first tool was based on osmocom but we are not in production. > > > > On Jan 2, 2013 12:12 AM, "Luca Bongiorni" <luca.bongiorni1(a)studenti.unimi.it> wrote: > >> > >> Hey all, > >> actually is "interesting" his web site. > >> > >> Since it seems a commercial website*: > >> > >> * " Matrix Shell developed own GSM penetration testing tool.This tool is comprised of hardware unit and a laptop.it can perform various test on network using custom firmware. > >> Using this too tester can identify state in which end user is getting service in terms of security." > >> > >> * "We provide following services. > >> GSM Network Penetration Testing > >> Matrixshell have developed a tool that can be used for testing attack vectors from users point of view. That is attacks that can be carried out by using modified handsets which may cause misusing identity of GSM subscriber , mass cellphone cell phone switch off ,denial of service of subscriber etc. Such vulnerability may cause loss in reputation of provider. > >> We can find out such issues using our own tools. Our tools comprised of UM interface hardware and a laptop communicating with UM interface. This tool can run different tests on network like: Checking encryption type, Authentication bypass, Wrong way of TMSI assignment by network, Identity impersonating." > >> > >> I am wondering how his software tools are dealing with Osmocom's licenses. > >> > >> Cheers, > >> Luca > >> > >> > are you sharing your current progress in a public git repository? If > >> > not, I'd like to strongly encourage you to do so. I can also give you > >> > commit access so you can push to a private branch on git.osmocom.org, if you > >> > prefer that. > >> > > >> > -- > >> > - 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) > >> > > >> > >> > > > > -- > Akib Sayyed > Matrix-Shell > akibsayyed(a)gmail.com > akibsayyed(a)matrixshell.com > Mob:- +91-966-514-2243 >

1 0

29c3 youtube video
by Vic Delorge 02 Jan '13

02 Jan '13

this is the 29c3 talk about GSM DOS and SMS sniffing . awesome work osmocom team. layer 1,2,3 now runs all on the phone :) http://youtu.be/a1iZV2nl28A

6 10

Filter replacement
by Clemens Gruber 01 Jan '13

01 Jan '13

Hi, yesterday I fucked up the second C123 while trying to replace the filters, so I decided to buy one model from Sysmocom (with the filters already replaced), but due to too many orders they do not offer this service anymore. Is somebody on this list able and willing to sell me one C123 with the filter kit already built in (and tested)? I'd really appreciate if someone, who is more experienced in SMD soldering than me, could help me out. If so, please contact me at: clemensgru(a)gmail.com I live in Austria, so delivery from Europe should not be a problem. Thanks. Clemens

2 1

Possible fix for problem -- "l1ctl.c:114 FBSB RESP: result=255"
by Bhaskar11 01 Jan '13

01 Jan '13

When I run ccch_scan on a regular network, every once in a while, at random I find the app stops sniffing with the error: > <000c> l1ctl.c:291 BURST IND: @(1428545 = 1077/01/35) (-105 dBm, SNR 3, > SACCH) > <000c> l1ctl.c:114 FBSB RESP: result=255 At the same time Osmocon gives a message like the following: > => DSP reports FB in bit that is 1031487569 bits in the future?!? > Synchronize_TDMA > LOST 2313! The problems seems therefore to emerge from some corruption of data in reception which causes l1ctl.c to dispatch the S_L1CTL_FBSB_ERR signal.

2 1

Filter replacement
by Clemens Gruber 31 Dec '12

31 Dec '12

Hi, yesterday I fucked up the second C123 while trying to replace the filters, so I decided to buy one model from Sysmocom (with the filters already replaced), but due to too many orders they do not offer this service anymore. Is somebody on this list able and willing to sell me one C123 with the filter kit already built in (and tested)? I'd really appreciate if someone, who is more experienced in SMD soldering than me, could help me out. If so, please contact me at: clemensgru(a)gmail.com I live in Austria, so delivery from Europe should not be a problem. Thanks. Clemens

1 0

Need guidance for LNA and PA
by Akib Sayyed 31 Dec '12

31 Dec '12

Dear List I wanted to buy LNA and PA for my phone what specification should i use for purpose increasing signalling strength. please guide me thanks -- Akib Sayyed Matrix-Shell akibsayyed(a)gmail.com akibsayyed(a)matrixshell.com Mob:- +91-966-514-2243

1 0

Question on saving burst information
by Bhaskar11 30 Dec '12

30 Dec '12

In ccch_scan the burst information is first saved to file, then local_burst_decode is applied before sending to GSMTAP. Would it not be more useful to save burst data after local_burst_decode? Is there some utility in storing it in its raw form? Looks like I am missing something? B.

2 2

kraken for uplink bursts
by g.roelant＠telenet.be 30 Dec '12

30 Dec '12

Hi, Is there a kraken version vailable for uplink? what do i need to change on the source code in order to find the kc for uplink bursts? thanks ps. all downlink frames seem to have random padding here...

1 0

Osmocom-BTS
by Akib Sayyed 30 Dec '12

30 Dec '12

Congrats Sylvain for such great engineering work.its really a good and cheap solution who want to learn about GSM. there are certain questions didnt get chance to be asked in conference. here are some 1.is it possible in future to implement one phone and atleast 4 timeslot cell? means 3 voice and 1 BCCH. 2. what about encryption? is it possible to implement encryption ? 3.also how can be solve relying on commercial cell? 4.the code which will be released will contain single slot operation or multi slot with voice (after work and developement) Thankx and again congrats :) cheers -- Akib Sayyed Matrix-Shell akibsayyed(a)gmail.com akibsayyed(a)matrixshell.com Mob:- +91-966-514-2243

2 2

Re: Bug in switching baud rates in burst_ind branch?
by Bhaskar11 29 Dec '12

29 Dec '12

Sysmocom sells pre-modified CP201x. You can use them as they are. "mostly" LAPDm and Paging messages is normal. You should also see call setups and SMSs as they are used, much less frequently depending on local traffic. :-) If you have your cellphone on the same ARFCN, you should be able to see your cell making/receiving calls and sending messages. B. On Fri, Dec 28, 2012 at 4:12 PM, Erich Dachleger <edachleger(a)yahoo.com>wrote: > I am also using CP210x from sysmocom and haven't modified it since I > thought it didn't require modification. > Is that wrong? > When I use burst_ind with unmodified CP210x I receive mostly LAPDM and > System 4 messages in wireshark. > Regards > Erich > >

2 1

Beginner question of firmware and C139
by david＠frinet.es 29 Dec '12

29 Dec '12

Hi all, I am starting with this project and i have problems downloading the firmware to a c139, i built the t191 and i'm using a FTDI usb-serial. I use the command that is described in "Motorola C140" section: ./osmocon -p /dev/ttyUSB0 -m c140 -c ../../target/firmware/board/compal_e86/layer1.highram.bin ../../target/firmware/board/compal_e86/chainload.compalram.bin and also i have used it with "-m c140xor" but when i push briefly power button, shows it in next lines "got 1 byte from modem, data looks like: ff .", the data are changing in next lines, some times the bytes received are more than 1, are 2, 5, 6. I have some questions: Which is the sequence that have to receive the osmocon to start the comunication with the phone? Is posible that the compilation of osmocon has been badly? Thanks and regards.

1 0

Bug in switching baud rates in burst_ind branch?
by Bhaskar11 28 Dec '12

28 Dec '12

Using burst_ind branch, the code switches to a higher speed in function serial_up_to_eleven like this: int serial_up_to_eleven(void) { int rv; /* Attempt custom baudrate */ rv = osmo_serial_set_custom_baudrate(dnload.serial_fd.fd, 406250); if (rv == 0) return 0; #ifdef I_HAVE_A_CP210x /* and I know what I'm doing, I swear ! */ /* Try closest standard baudrate (CP210x reprogrammed adapters) */ rv = osmo_serial_set_baudrate(dnload.serial_fd.fd, B460800); if (rv == 0) return 0; #endif etc.... If the first attempt to switch to 406250 succeeds, the function exits and never reaches the I_HAVE_A_CP210x code which would switch to a higher speed! Is this a bug? Or is the lower speed good enough for burst_ind? In which case why bother with the I_HAVE_A_CP210x option? Or have I missed something obvious? B.

2 2

Beginner question of firmware and C139
by david＠frinet.es 27 Dec '12

27 Dec '12

Hi all, I am starting with this project and i have problems downloading the firmware to a c139, i built the t191 and i'm using a FTDI usb-serial. I use the command that is described in "Motorola C140" section: ./osmocon -p /dev/ttyUSB0 -m c140 -c ../../target/firmware/board/compal_e86/layer1.highram.bin ../../target/firmware/board/compal_e86/chainload.compalram.bin and also i have used it with "-m c140xor" but when i push briefly power button, shows it in next lines "got 1 byte from modem, data looks like: ff .", the data are changing in next lines, some times the bytes received are more than 1, are 2, 5, 6. I have some questions: Which is the sequence that have to receive the osmocon to start the comunication with the phone? Is posible that the compilation of osmocon has been badly? Thanks and regards.

1 0

frame guessing
by g.roelant＠telenet.be 26 Dec '12

26 Dec '12

Hi group, what is the most succesful: guessing uplink frames or downlink. i see some very simple uplink frames that make a good candidate. or is it all the same... kind regards

1 0

Frimware problem
by Mikhail Zisman 26 Dec '12

26 Dec '12

Hello, I am working with a project Osmocom-bb. I did compile the project. But when the firmware command : ./osmocon -p /dev/ttyUSB0-m c123xor ../../target/firmware/board/compal_e88/hello_world.compalram.bin screen is just hangs (the power button I also click) , or most likely expects to input a sequence of bytes, i.e., no information no longer appears. The phone is switched on. I used this instructions for checking the operation of the http://lists.osmocom.org/pipermail/baseband-devel/2011-August/002230.html . 1) I use the FTDI cable, it is OK. Port is OK. 2) Note : I don't see FMTTOOL ERROR (!!!) when i press the power button. I tried the next model C113,C115,C118. Why this may happen? Thank you!

1 0

double frames in burst file
by g.roelant＠telenet.be 24 Dec '12

24 Dec '12

Hi Group, i'm using the testing/sylvain burst branch. sometimes i get double frames in the bursts files taken with ccch_scan. what does this mean? bad reception? kind regards

2 6

How can I see the RAND/SRES
by dagar 24 Dec '12

24 Dec '12

Hello, I am in the process of setting up OsmocomBB but I was wondering where/which files in the firmware responsible for receiving/processing the RAND/SRES values from the network/SIM. Does anyone know this or can point me in the right direction? -- View this message in context: http://baseband-devel.722152.n3.nabble.com/How-can-I-see-the-RAND-SRES-tp40… Sent from the baseband-devel mailing list archive at Nabble.com.

2 1

problems after last update
by Vic Delorge 24 Dec '12

24 Dec '12

hello first off al these phone's and tools RULE . i already tested a couple branches . burst_ind work'd and captured packet's , sylvain/testing also worked a week or 2 ago and i could make a call en see it in wireshark :) . but now i saw that there were some updates in the sylvain testing branch i updated like the sim reader page on the wiki told me . could it be that the last commits broke the sylvain/testing branch ? i get error while loading libosmocore.so.4 i followed the tutorial on the wiki for sim reader . 2 weeks ago it worked fine . checked the code in the last updates and it seems that lib osmocore is now changed ? or am i doing wrong ?? thx in advance grts vic

2 1

usim programming
by ☎ 21 Dec '12

21 Dec '12

Hello. I'm struggling with a5/3 test - I've got osmocom usim (http://shop.sysmocom.de/products/sysmousim-gr1) which I've programmed with pySim-prog.py Unfortunately when I plug it into samsung galaxy s2 it indicates (via classmark) that it only supports a5/1 What am I doing wrong? I've tried operator's sim with the same phone - a5/3 support is indicated just fine. -- best regards, Max, http://fairwaves.ru

2 1

Can't compile after last pull
by Dario Lombardo 20 Dec '12

20 Dec '12

I've pulled git repo today, but the RSSI firmware gets an error. apps/rssi/main.c: In function `main': apps/rssi/main.c:896: warning: 'a' might be used uninitialized in this function apps/rssi/main.c:896: warning: 'e' might be used uninitialized in this function CC board/compal_e88/rssi.compalram.manifest.o LD board/compal_e88/rssi.compalram.elf OBJ board/compal_e88/rssi.compalram.bin CC board/compal_e88/rssi.highram.manifest.o LD board/compal_e88/rssi.highram.elf OBJ board/compal_e88/rssi.highram.bin CC board/compal_e88/rssi.e88loader.manifest.o LD board/compal_e88/rssi.e88loader.elf OBJ board/compal_e88/rssi.e88loader.bin CC board/compal_e88/rssi.e88flash.manifest.o LD board/compal_e88/rssi.e88flash.elf OBJ board/compal_e88/rssi.e88flash.bin CC board/compal_e86/rssi.compalram.manifest.o LD board/compal_e86/rssi.compalram.elf arm-elf-ld: region LRAM is full (board/compal_e86/rssi.compalram.elf section .data) make[1]: *** [board/compal_e86/rssi.compalram.elf] Error 1 make[1]: Leaving directory src/target/firmware' make: *** [firmware] Error 2 $ git pull Already up-to-date. $ Anyone experiencing the same issue?

9 11

graphical gsmtap helper
by ☎ 19 Dec '12

19 Dec '12

Hello. It's often handy to have a high-level look at message exchange between ms and gsm network captured via gsmtap. There are some tools to do that for ip captures but they completely ignore uplink-downlink semantics so are next to useless in this case. Attached is little helper which can be used to make proper descriptions for mscgen to produce nice message sequence charts. Usage instructions are inside the script. In short: .pcap in - .png out It requires mscgen and recent (>=1.9) tshark so you have to use git to get and build tshark binary yourself until wireshark 1.10 is released: git clone http://code.wireshark.org/git/wireshark Apologies if you received this message multiple times but I personally find this little helper to be very useful so I'd like to reach as wide audience as possible. -- best regards, Max, http://fairwaves.ru

1 0

restart layer1 from remote?
by Tim Ehlers 18 Dec '12

18 Dec '12

Hi, I have the problem, that after running for quite a while, lets say a week, the layer1 seems to crash. This crash is random and only happens on single phones (I have 6 phones connected to one mobile app). This phone is unusable, even after "shutdown/no shutdown" or complete restart of mobile, this phone stays like this: OsmocomBB# show ms 3 MS '3' is up, service is limited IMEI: XXXXXXXXXXXX IMEISV: XXXXXXXXXXXXX IMEI generation: fixed automatic network selection state: A1 trying RPLMN MCC=262 MNC=07 (Germany, O2) cell selection state: C1 normal cell selection radio ressource layer state: idle mobility management layer state: MM idle, PLMN search By restarting the phone (pressing power on the phone, and reloading layer1) its working again. But this need physical access to the phone. Is there a way to somehow "reboot" or restart the layer1 by software? And if not, could that easily be implemented? Thanks Tim

2 3

System information type 5 & 6
by g.roelant＠telenet.be 16 Dec '12

16 Dec '12

Hi, i'm capturing my own voice calls in wireshark. i can see a system information type packet just before ciphering command. 204 frames further there is a system information type 6 packet. but these 2 packets don't resamble... how can i subtract a key out of these 2 different packets? this doesn't make any sens.... if i look for the same type 5 packet... they are never at the same location.... :( is my reasoning wrong? kind regards

1 0

question about l1ctl_burst_ind structure
by g.roelant＠telenet.be 15 Dec '12

15 Dec '12

Hi, In the L1ctl_burst_ind structure is: uint8_t bits[15]; /* 114 bits + 2 steal bits. Filled MSB first */ if i do 8 * 15 = 120 that would make 6 bits extra... not 2 bits should i discard the last 6 bits of the last byte? thanks

2 1

burst_ind branch
by g.roelant＠telenet.be 15 Dec '12

15 Dec '12

Please correct me if i'm wrong: i'm writing a small c program to process to burst files. run ccch_scan and follow the frames in wireshark. if you see an "inrtresting" frame, note his number get the correct frame out of the burst file and display its bit stream. than this bitstream can be further used for processing add a certain offset to the framecounter and get that frame out of the burst file and display its bit stream. the rest.... i still have to figure that out... can anyone confirm i am doing the write thing? thanks

1 0

Questions about filter replacement and fbsb_req
by Pe 14 Dec '12

14 Dec '12

Hi list! I'm playing with ccch_scan from burst_ind branch. I have some troubles with going SDCCH - FCCH\SCH - TCH After receiving "assignment command" i call fbsb_req to L1 for waiting FCCH\SCH sync bursts. When fbsb_resp is coming, i call dm_est_req_h1 with channel and hopping params. But SNR of incoming tch bursts is less then 10 most of time. What did i wrong? Is it needs to synchronize only timers by SCH without FCCH freq sync? And why we lose sync when goes from SDCCH to TCH? And a question about filter replacement. After filter change on baluns i see -128 dBm on all ARFCNs when mobile app from master branch is started. After that i tried to connect balanced line to the former filter pad and unbalanced line to the ground via cap(on the EGSM channel), as Sylvain wrote. But it didnt help. Photo after filter rework on C115: http://s9.postimage.org/r50qtx73z/lastrep.jpg As i understand, the input tract with 2 caps, 2 inductors and band-pass filter just needs for image frequency disabling? -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Questions-about-filter-replaceme… Sent from the baseband-devel mailing list archive at Nabble.com.

1 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel