May 2014 - baseband-devel - lists.osmocom.org

Engagetted !
by Sébastien Lorquet 14 Oct '25

14 Oct '25

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

7 7

OpenBTS OsmocomBB Asterisk
by trixbox.t 14 Jul '18

14 Jul '18

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

6 14

Sniffing GPRS
by canarion 12 Dec '16

12 Dec '16

Hi, After compiling osmocom-bb and apply sylvain/burst_ind branch and gprs_multi.patch, I execute it and try to sniff gprs traffic. I loaded the layer1 into my C139 and I obtained an ARFCN code (883). When I run ccch_scan -a 883 I get the next result: opyright (C) 2010 Harald Welte <laforge(a)gnumonks.org> Contributions by Holger Hans Peter Freyther 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. Failed to connect to '/tmp/osmocom_sap'. Failed during sap_open(), no SIM reader <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(1476410343) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(1207963561) <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0x1ad1cda) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0x41ae98f9) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to imsi M(214031385056117) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3306441249) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214031482053520) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214036185306441) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4207880193) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4135931713) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4214223105) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3388536385) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(134915836) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3961436929) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4229756769) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(531909) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214034185316455) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3829437761) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214033485554660) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3639403521) <0001> app_ccch_scan.c:105 SI1 received. <0001> app_ccch_scan.c:464 unknown PCH/AGCH type 0x00 <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3827744513) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(335734299) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3561969409) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4294310401) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3698994241) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3682615617) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(67866789) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4003487553) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3770351169) <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0x41ae98f9) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0x1ad1cda) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to imsi M(214031385056117) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3306441249) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214031482053520) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214036185306441) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4102036289) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4135931713) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214032485273805) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3798414145) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(134915836) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3988859137) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3735175681) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(531909) <0001> app_ccch_scan.c:248 GSM48 IMM ASS (ra=0x78, chan_nr=0x0f, HSN=24, MAIO=1, TS=7, SS=0, TSC=1) Dropping frame with 55 bit errors <000c> l1ctl.c:238 Dropping frame with 55 bit errors <000c> l1ctl.c:290 BURST IND: @(830928 = 0626/20/36) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830928 = 0626/20/36) (-110 dBm, SNR 8) <000c> l1ctl.c:290 BURST IND: @(830929 = 0626/21/37) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830929 = 0626/21/37) ( -83 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830930 = 0626/22/38) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830930 = 0626/22/38) ( -87 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830931 = 0626/23/39) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830931 = 0626/23/39) ( -83 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830932 = 0626/24/40) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830932 = 0626/24/40) ( -88 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830933 = 0626/25/41) (-105 dBm, SNR 8, UL, SACCH) <000c> l1ctl.c:290 BURST IND: @(830933 = 0626/25/41) (-107 dBm, SNR 5, SACCH) <000c> l1ctl.c:290 BURST IND: @(830934 = 0626/00/42) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830934 = 0626/00/42) ( -88 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830935 = 0626/01/43) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830935 = 0626/01/43) ( -83 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830936 = 0626/02/44) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830936 = 0626/02/44) ( -88 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830937 = 0626/03/45) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830937 = 0626/03/45) ( -89 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830938 = 0626/04/46) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830938 = 0626/04/46) ( -88 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830939 = 0626/05/47) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830939 = 0626/05/47) ( -82 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830940 = 0626/06/48) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830940 = 0626/06/48) ( -87 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830941 = 0626/07/49) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830941 = 0626/07/49) ( -87 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830942 = 0626/08/50) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830942 = 0626/08/50) ( -86 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830943 = 0626/09/00) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830943 = 0626/09/00) ( -86 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830944 = 0626/10/01) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830944 = 0626/10/01) ( -87 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830945 = 0626/11/02) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830945 = 0626/11/02) ( -87 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830947 = 0626/13/04) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830947 = 0626/13/04) ( -84 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830948 = 0626/14/05) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830948 = 0626/14/05) ( -85 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830949 = 0626/15/06) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830949 = 0626/15/06) ( -88 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830950 = 0626/16/07) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830950 = 0626/16/07) ( -89 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830951 = 0626/17/08) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830951 = 0626/17/08) ( -88 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830952 = 0626/18/09) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830952 = 0626/18/09) ( -85 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830953 = 0626/19/10) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830953 = 0626/19/10) ( -87 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830954 = 0626/20/11) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830954 = 0626/20/11) ( -87 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830955 = 0626/21/12) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830955 = 0626/21/12) (-106 dBm, SNR 0) <000c> l1ctl.c:290 BURST IND: @(830956 = 0626/22/13) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830956 = 0626/22/13) (-107 dBm, SNR 5) <000c> l1ctl.c:290 BURST IND: @(830957 = 0626/23/14) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830957 = 0626/23/14) (-106 dBm, SNR 2) <000c> l1ctl.c:290 BURST IND: @(830958 = 0626/24/15) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830958 = 0626/24/15) (-108 dBm, SNR 1) <000c> l1ctl.c:290 BURST IND: @(830959 = 0626/25/16) (-106 dBm, SNR 2, UL, SACCH) <000c> l1ctl.c:290 BURST IND: @(830959 = 0626/25/16) (-109 dBm, SNR 5, SACCH) <000c> l1ctl.c:290 BURST IND: @(830960 = 0626/00/17) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830960 = 0626/00/17) (-108 dBm, SNR 3) <000c> l1ctl.c:290 BURST IND: @(830961 = 0626/01/18) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830961 = 0626/01/18) (-106 dBm, SNR 2) <000c> l1ctl.c:290 BURST IND: @(830962 = 0626/02/19) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830962 = 0626/02/19) (-108 dBm, SNR 3) <000c> l1ctl.c:290 BURST IND: @(830963 = 0626/03/20) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830963 = 0626/03/20) (-107 dBm, SNR 0) <000c> l1ctl.c:290 BURST IND: @(830964 = 0626/04/21) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830964 = 0626/04/21) ( -85 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830965 = 0626/05/22) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830965 = 0626/05/22) ( -87 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830966 = 0626/06/23) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830966 = 0626/06/23) ( -85 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830967 = 0626/07/24) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830967 = 0626/07/24) ( -86 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830968 = 0626/08/25) (-107 dBm, SNR 6, UL) <000c> l1ctl.c:290 BURST IND: @(830968 = 0626/08/25) (-109 dBm, SNR 0) <000c> l1ctl.c:290 BURST IND: @(830969 = 0626/09/26) (-101 dBm, SNR 6, UL) But it stop to capture frames, seems to be left in a standby state and I don't know why that is. With gprsdecode I can see the next image in the wireshark: http://baseband-devel.722152.n3.nabble.com/file/n3712433/wireshark-capture.… If someone knows what is the problem, please tell me. Thanks in advance. Cheers, Dani -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Sniffing-GPRS-tp3712433p3712433.… Sent from the baseband-devel mailing list archive at Nabble.com.

8 12

"Type not handled! 40" gprsdecode
by George Andguladze 21 Nov '16

21 Nov '16

Hey there, I bumped into this error when testing gprsdecode from srldabs.de When I try the sample .dat files provided from srlabs.de it works fine though. Any hints? Kind Regards George AndguladzeSenior Software EngineerBusiness Management Technology www.bmt.ge

2 1

layer2/3 ported to target? paging attack code?
by Craig Comstock 05 Aug '16

05 Aug '16

Hey, I finally watched Nico's talk "let me answer that for you" and heard him say he ported layer2/3 to target. Also found a mailing list message about him cleaning it up and putting it up on git and sending it to a few folks. Did that code ever get shared? Would be cool to play around with and is certainly something I would eventually want to accomplish for my project of making a phone that works by itself. -Craig

8 15

Please can anyone advise me - FMTOOL Error and no further processing
by Raz Sharif 25 May '16

25 May '16

Dear all, I vae the C115 with a T1 USB to Serial cable with the Prolific chipset. When i run osmocon i get :- an its just sits there with no further processing. ./osmocon -p /dev/ttyUSB0 -m c123xor ../../target/firmware/board/compal_e88/loader.compalram.bin read_file(../../target/firmware/board/compal_e88/loader.compalram.bin): file_size=17120, hdr_len=4, dnload_len=17127 read_file(../../target/firmware/board/compal_e88/loader.compalram.bin): file_size=17120, hdr_len=4, dnload_len=17127 got 1 bytes from modem, data looks like: 00 . got 2 bytes from modem, data looks like: 2f 00 /. got 1 bytes from modem, data looks like: 1b . got 3 bytes from modem, data looks like: f6 02 00 ... got 1 bytes from modem, data looks like: 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 got 1 bytes from modem, data looks like: 66 f got 1 bytes from modem, data looks like: 74 t got 1 bytes from modem, data looks like: 6d m got 1 bytes from modem, data looks like: 74 t got 1 bytes from modem, data looks like: 6f o got 1 bytes from modem, data looks like: 6f o got 1 bytes from modem, data looks like: 6c l Received FTMTOOL from phone, ramloader has aborted got 1 bytes from modem, data looks like: 65 e got 1 bytes from modem, data looks like: 72 r got 1 bytes from modem, data looks like: 72 r got 1 bytes from modem, data looks like: 6f o got 1 bytes from modem, data looks like: 72 r got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . I think the cable is ok as when i run my fingers on the tip i get random Zeros so it appears to be talking to the cable. Also when i tried to run Mobile i get the :- even though i created the Mobile.cfg file in /etc/osmoco Failed to parse the config file: '/home/raz/.osmocom/bb/mobile.cfg' Please check or create config file using: 'touch /home/raz/.osmocom/bb/mobile.cfg' I have spent some hours researching the lists and trying various things to no avail but I want to continue until I resolve this issues and use this great stack to learn about the GSM network. Please advise. Great full for any help or pointers but this maybe a timing issue that is difficult to debug. Thanks Raz

5 6

cell re-selection
by Andreas.Eversberg 05 Mar '16

05 Mar '16

hi, i did a lot of resarch and testing on cell selection and re-selection process the last two week. the cell selection process, network selection process (manual and automatic) and mobility management process were already implemented in OsmocomBB a long time, but turned out to be buggy and incomplete. i made test drives to check the process and debugged it. the re-selection process is new. it is used to track surrounding cells while listening to the BCCH of the current cell (camping on a cell). special extension to the layer1 firmare is used to measure neighbour cells. if an neighbour cell becomes 'better', the mobile switches to that cell, depening on different criteria. now it is possible to move with OsmocomBB. the re-selection process is not handover! handover is a process where a phone switches between cells while doing a call. handover is one next step to implement. the process is a little more complex, because it requires not only neighbour cell measurements, but also syncing to them without interrupting the traffic channel. most layer 3 stuff of handover is already implemented. if you like to play and test your moving OsmocomBB, you can check out the "jolly/roaming" branch. it contains the extension to layer1, as well as sim reader and fixes from "sylvain/testing" branch. use both "mobile" and "layer1" firmware from this branch. in order to see some process at VTY, you can do: enable monitor network 1 (continously display the strongest cell and neighbour cells) show ms 1 (to see current states) show neighbour-cells 1 (to see a more detailed current list of neighbours) andreas

3 3

Set fixed TMSI and Kc
by Simian Denson 29 Feb '16

29 Feb '16

Hi, in the osmocom bb mobile.cfg I don't see any posibility to set a fixed Kc encryption key and the tmsi. How could I achieve that osmocom uses my defined Kc and tmsi? cheers, Simian

5 21

Baseband: MS '1' is up, service is limited
by Hoàng Mạnh Hùng 22 May '15

22 May '15

Hi all, *I connected, sent and made call successful with osmocombb (with real IMSI and IMEI). But, now, I get error, always be rejected:* OsmocomBB# show ms MS '1' is up, service is limited IMEI: 357337016773249 IMEISV: 3573370167732490 IMEI generation: fixed automatic network selection state: A0 null cell selection state: PLMN search radio ressource layer state: idle mobility management layer state: MM idle, PLMN search OsmocomBB# % (MS 1) % Trying to registering with network... *in my config file (/root/.osmocom/bb/mobile.cfg)**:* ! ! OsmocomBB () configuration saved from vty !! ! line vty no login ! gps device /dev/ttyACM0 gps baudrate default no gps enable ! no hide-default ! ms 1 layer2-socket /tmp/osmocom_l2 sap-socket /tmp/osmocom_sap sim reader network-selection-mode auto imei 357337016773249 0 imei-fixed emergency-imsi 452040399998391 sms-service-center +84980200030 no call-waiting no auto-answer no force-rekey no 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 gsm-850 dcs 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 -106 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 ! Anyone help me???, thanks a lot! -- Thanks and Best Regards -- From: Hoàng Mạnh Hùng

5 10

Location update problems on Motorola C118
by Maciej Grela 12 Nov '14

12 Nov '14

Hi, I'm trying to run the latest osmocom-bb git on a Motorola C118 phone. After a minor problem with the build (as you may've noticed in the patch I've sent). I got to the point of successfuly running layer1 on the phone and the mobile app on the PC (I have also enabled TX). The process seems to be stuck on trying to perform a location update. The status of the ms is always either: show ms MS '1' is up, MM connection active IMEI: 000000000000000 IMEISV: 0000000000000000 IMEI generation: fixed automatic network selection state: A1 trying RPLMN MCC=104 MNC=002 (104, 002) cell selection state: connected mode 1 ARFCN=19 MCC=104 MNC=002 LAC=0xb00f CELLID=0x4fd9 (104, 002) radio ressource layer state: connection pending mobility management layer state: wait for RR connection (location updating) OsmocomBB> or show ms MS '1' is up, service is limited (pending) IMEI: 000000000000000 IMEISV: 0000000000000000 IMEI generation: fixed automatic network selection state: A1 trying RPLMN MCC=104 MNC=002 (104, 002) cell selection state: C3 camped normally ARFCN=19 MCC=104 MNC=002 LAC=0xb00f CELLID=0x4fd9 (104, 002) radio ressource layer state: idle mobility management layer state: MM idle, attempting to update OsmocomBB> I think, that because of this I can't make any calls or send sms (all the requests are being rejected): OsmocomBB# call 1 <X> call 1 <X> OsmocomBB# % (MS 1) % Call has been rejected The log information from mobile when it's trying to do a location update is show below: <000b> gsm48_rr.c:2174 PAGING REQUEST 1 <000b> gsm48_rr.c:2141 IMSI 260021964220249 (not for us) <000b> gsm48_rr.c:2132 TMSI fd82a501 (not for us) <000e> gsm48_mm.c:344 Location update retry <0005> gsm48_mm.c:345 timer T3211 (loc. upd. retry delay) has fired <0005> gsm48_mm.c:4311 (ms 1) Received 'MM_EVENT_TIMEOUT_T3211' event in state MM IDLE, attempting to update <000e> gsm48_mm.c:2199 Perform location update (MCC 104, MNC 002 LAC 0xb00f) <0005> gsm48_mm.c:2333 LOCATION UPDATING REQUEST <0005> gsm48_mm.c:2355 using LAI (mcc 104 mnc 002 lac 0xb00f) <0005> gsm48_mm.c:2363 using TMSI 0x28a3d62e <0005> gsm48_mm.c:914 new state MM IDLE, attempting to update -> wait for RR connection (location updating) <0001> gsm48_rr.c:5428 (ms 1) Message 'RR_EST_REQ' received in state idle (sapi 0) <000e> gsm48_rr.c:1318 Establish radio link due to mobility management request <0003> gsm322.c:4037 (ms 1) Event 'EVENT_LEAVE_IDLE' for Cell selection in state 'C3 camped normally' <0003> gsm322.c:823 new state 'C3 camped normally' -> 'connected mode 1' <0003> gsm322.c:3653 Going to camping (normal) ARFCN 19. <0003> gsm322.c:463 Sync to ARFCN=19 rxlev=-74 (Sysinfo, ccch mode NON-COMB) <0001> gsm48_rr.c:366 new state idle -> connection pending <0001> gsm48_rr.c:1465 CHANNEL REQUEST: 00 (Location Update with NECI) <0003> gsm322.c:2938 Channel synched. (ARFCN=19, snr=16, BSIC=17) <0001> gsm322.c:2959 using DSC of 90 <0003> gsm48_rr.c:4816 Channel provides data. <0001> gsm48_rr.c:1601 RANDOM ACCESS (requests left 5) <0001> gsm48_rr.c:1658 RANDOM ACCESS (Tx-integer 50 combined no S(lots) 0 ra 0x0e) <0001> gsm48_rr.c:1697 Use MS-TXPWR-MAX-CCH power value 5 (33 dBm) <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:1601 RANDOM ACCESS (requests left 4) <0001> gsm48_rr.c:1658 RANDOM ACCESS (Tx-integer 50 combined no S(lots) 55 ra 0x07) <0001> gsm48_rr.c:1697 Use MS-TXPWR-MAX-CCH power value 5 (33 dBm) <0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT: <0001> gsm48_rr.c:2462 (ta 2/1107m ra 0x75 chan_nr 0x0a MAIO 0 HSN 38 TS 2 SS 0 TSC 0) <0001> gsm48_rr.c:2503 Request, but not for us. <0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT: <0001> gsm48_rr.c:2462 (ta 2/1107m ra 0x75 chan_nr 0x0a MAIO 0 HSN 38 TS 2 SS 0 TSC 0) <0001> gsm48_rr.c:2503 Request, but not for us. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:673 MON: f=19 lev=-78 snr= 0 ber= 0 LAI=104 002 b00f ID=4fd9 <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:1601 RANDOM ACCESS (requests left 3) <0001> gsm48_rr.c:1658 RANDOM ACCESS (Tx-integer 50 combined no S(lots) 55 ra 0x0f) <0001> gsm48_rr.c:1697 Use MS-TXPWR-MAX-CCH power value 5 (33 dBm) <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:1601 RANDOM ACCESS (requests left 2) <0001> gsm48_rr.c:1658 RANDOM ACCESS (Tx-integer 50 combined no S(lots) 55 ra 0x01) <0001> gsm48_rr.c:1697 Use MS-TXPWR-MAX-CCH power value 5 (33 dBm) <0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT: <0001> gsm48_rr.c:2473 (ta 1/553m ra 0x18 chan_nr 0x59 ARFCN 19 TS 1 SS 3 TSC 1) <0001> gsm48_rr.c:2503 Request, but not for us. <0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT: <0001> gsm48_rr.c:2473 (ta 1/553m ra 0x18 chan_nr 0x59 ARFCN 19 TS 1 SS 3 TSC 1) <0001> gsm48_rr.c:2503 Request, but not for us. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:1601 RANDOM ACCESS (requests left 1) <0001> gsm48_rr.c:1658 RANDOM ACCESS (Tx-integer 50 combined no S(lots) 55 ra 0x0a) <0001> gsm48_rr.c:1697 Use MS-TXPWR-MAX-CCH power value 5 (33 dBm) <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:673 MON: f=19 lev=-78 snr= 0 ber= 1 LAI=104 002 b00f ID=4fd9 <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:1601 RANDOM ACCESS (requests left 0) <0001> gsm48_rr.c:1605 Done with sending RANDOM ACCESS bursts <0001> gsm48_rr.c:836 starting T3126 with 5.000 seconds <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2225 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:673 MON: f=19 lev=-78 snr= 0 ber= 0 LAI=104 002 b00f ID=4fd9 <0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT: <0001> gsm48_rr.c:2473 (ta 2/1107m ra 0x0a chan_nr 0x41 ARFCN 19 TS 1 SS 0 TSC 1) <0001> gsm48_rr.c:2393 request 0a matches but not frame number (IMM.ASS fn=22,6,30 != RACH fn=22,5,25) <0001> gsm48_rr.c:2503 Request, but not for us. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT: <0001> gsm48_rr.c:2473 (ta 2/1107m ra 0x05 chan_nr 0x49 ARFCN 19 TS 1 SS 1 TSC 1) <0001> gsm48_rr.c:2503 Request, but not for us. <0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT: <0001> gsm48_rr.c:2473 (ta 2/1107m ra 0x05 chan_nr 0x49 ARFCN 19 TS 1 SS 1 TSC 1) <0001> gsm48_rr.c:2503 Request, but not for us. <0001> gsm48_rr.c:2225 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:673 MON: f=19 lev=-77 snr= 0 ber= 6 LAI=104 002 b00f ID=4fd9 <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT: <0001> gsm48_rr.c:2473 (ta 2/1107m ra 0x00 chan_nr 0x61 ARFCN 19 TS 1 SS 4 TSC 1) <0001> gsm48_rr.c:2503 Request, but not for us. <0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT: <0001> gsm48_rr.c:2473 (ta 2/1107m ra 0x00 chan_nr 0x61 ARFCN 19 TS 1 SS 4 TSC 1) <0001> gsm48_rr.c:2503 Request, but not for us. <0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT: <0001> gsm48_rr.c:2462 (ta 2/1107m ra 0x7d chan_nr 0x0b MAIO 0 HSN 38 TS 3 SS 0 TSC 0) <0001> gsm48_rr.c:2503 Request, but not for us. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT: <0001> gsm48_rr.c:2462 (ta 2/1107m ra 0x7d chan_nr 0x0b MAIO 0 HSN 38 TS 3 SS 0 TSC 0) <0001> gsm48_rr.c:2503 Request, but not for us. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:673 MON: f=19 lev=-78 snr= 0 ber= 0 LAI=104 002 b00f ID=4fd9 <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2225 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2225 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:673 MON: f=19 lev=-78 snr= 0 ber= 3 LAI=104 002 b00f ID=4fd9 <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT: <0001> gsm48_rr.c:2462 (ta 2/1107m ra 0x77 chan_nr 0x09 MAIO 0 HSN 38 TS 1 SS 0 TSC 0) <0001> gsm48_rr.c:2503 Request, but not for us. <0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT: <0001> gsm48_rr.c:2462 (ta 2/1107m ra 0x77 chan_nr 0x09 MAIO 0 HSN 38 TS 1 SS 0 TSC 0) <0001> gsm48_rr.c:2503 Request, but not for us. <0001> gsm48_rr.c:2225 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:673 MON: f=19 lev=-78 snr= 0 ber= 6 LAI=104 002 b00f ID=4fd9 <0001> gsm48_rr.c:765 timer T3126 has fired <000e> gsm48_rr.c:770 Requesting channel failed <0001> gsm48_rr.c:366 new state connection pending -> idle <0003> gsm322.c:4037 (ms 1) Event 'EVENT_RET_IDLE' for Cell selection in state 'connected mode 1' <0003> gsm322.c:3565 Selecting ARFCN 19. after LOC.UPD. <0003> gsm322.c:463 Sync to ARFCN=19 rxlev=-74 (Sysinfo, ccch mode NON-COMB) <0003> gsm322.c:823 new state 'connected mode 1' -> 'C3 camped normally' <0005> gsm48_mm.c:3902 (ms 1) Received 'RR_REL_IND' from RR in state wait for RR connection (location updating) (sapi 0) <0005> gsm48_mm.c:2732 RR link released after loc. upd. <000e> gsm48_mm.c:2676 Location update failed <000e> gsm48_mm.c:2686 Try location update later <0005> gsm48_mm.c:2688 Loc. upd. failed, retry #0 <0005> gsm48_mm.c:413 starting T3211 (loc. upd. retry delay) with 15.0 seconds <0005> gsm48_mm.c:1143 We are camping normally as returning to MM IDLE <0005> gsm48_mm.c:1159 Loc. upd. allowed. <0005> gsm48_mm.c:919 new state wait for RR connection (location updating) -> MM IDLE, location updating needed <0005> gsm48_mm.c:909 new MM IDLE state location updating needed -> attempting to update <0005> gsm48_mm.c:2215 Loc. upd. already pending. <0005> gsm48_mm.c:4311 (ms 1) Received 'MM_EVENT_CELL_SELECTED' event in state MM IDLE, attempting to update <0005> gsm48_mm.c:2215 Loc. upd. already pending. <0003> gsm322.c:2938 Channel synched. (ARFCN=19, snr=16, BSIC=17) <0001> gsm322.c:2959 using DSC of 90 Can you provide me any hints on how to debug this ? Why is the location update failing constantly ? Thanks in advance for your help. Best regards, Maciej Grela

6 9

Re: Error loading firmware onto Motorola C115.
by msokolov＠ivan.Harhan.ORG 30 Jul '14

30 Jul '14

Ravi Sharan <ravisharan(a)iith.ac.in> wrote: > I am trying out osmocom-bb with the Motorla C115. [...] < I get the following error: > > $ osmocon -p /dev/ttyUSB0 -m c123 > ~/osmocom-bb/src/target/firmware/board/compal_e88/hello_world.compalram.bin > [snipped the part where everything goes as it should] > 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: 45 E > got 1 bytes from modem, data looks like: 53 S > got 1 bytes from modem, data looks like: 16 . > Received DOWNLOAD NACK from phone, something went wrong :( Try -m c123xor instead of -m c123. HTH, SF

4 6

[PATCH] Update GPRS cipher API to comply with ETSI TS 155.22
by Max 17 Jun '14

17 Jun '14

--- include/osmocom/crypt/gprs_cipher.h | 8 ++++++-- src/gsm/gprs_cipher_core.c | 20 +++++++++++++++++--- src/gsm/libosmogsm.map | 1 + 3 files changed, 24 insertions(+), 5 deletions(-) diff --git a/include/osmocom/crypt/gprs_cipher.h b/include/osmocom/crypt/gprs_cipher.h index 3051071..b6b8e93 100644 --- a/include/osmocom/crypt/gprs_cipher.h +++ b/include/osmocom/crypt/gprs_cipher.h @@ -10,6 +10,7 @@ enum gprs_ciph_algo { GPRS_ALGO_GEA1, GPRS_ALGO_GEA2, GPRS_ALGO_GEA3, + GPRS_ALGO_GEA4, _GPRS_ALGO_NUM }; @@ -28,7 +29,7 @@ struct gprs_cipher_impl { /* As specified in 04.64 Annex A. Uses Kc, IV and direction * to generate the 1523 bytes cipher stream that need to be * XORed wit the plaintext for encrypt / ciphertext for decrypt */ - int (*run)(uint8_t *out, uint16_t len, uint64_t kc, uint32_t iv, + int (*run)(uint8_t *out, uint16_t len, uint8_t *kc, uint32_t iv, enum gprs_cipher_direction direction); }; @@ -40,11 +41,14 @@ int gprs_cipher_load(const char *path); /* function to be called by core code */ int gprs_cipher_run(uint8_t *out, uint16_t len, enum gprs_ciph_algo algo, - uint64_t kc, uint32_t iv, enum gprs_cipher_direction dir); + uint8_t *kc, uint32_t iv, enum gprs_cipher_direction dir); /* Do we have an implementation for this cipher? */ int gprs_cipher_supported(enum gprs_ciph_algo algo); +/* Return key length for supported cipher, in bytes */ +unsigned gprs_cipher_key_length(enum gprs_ciph_algo algo); + /* GSM TS 04.64 / Section A.2.1 : Generation of 'input' */ uint32_t gprs_cipher_gen_input_ui(uint32_t iov_ui, uint8_t sapi, uint32_t lfn, uint32_t oc); diff --git a/src/gsm/gprs_cipher_core.c b/src/gsm/gprs_cipher_core.c index b9a22a1..450272b 100644 --- a/src/gsm/gprs_cipher_core.c +++ b/src/gsm/gprs_cipher_core.c @@ -26,8 +26,8 @@ #include <osmocom/core/utils.h> #include <osmocom/core/linuxlist.h> #include <osmocom/core/plugin.h> - #include <osmocom/crypt/gprs_cipher.h> +#include <osmocom/gsm/gea.h> static LLIST_HEAD(gprs_ciphers); @@ -53,12 +53,14 @@ int gprs_cipher_register(struct gprs_cipher_impl *ciph) int gprs_cipher_load(const char *path) { /* load all plugins available from path */ - return osmo_plugin_load_all(path); + if (path) + return osmo_plugin_load_all(path); + return 0; } /* function to be called by core code */ int gprs_cipher_run(uint8_t *out, uint16_t len, enum gprs_ciph_algo algo, - uint64_t kc, uint32_t iv, enum gprs_cipher_direction dir) + uint8_t *kc, uint32_t iv, enum gprs_cipher_direction dir) { if (algo >= ARRAY_SIZE(selected_ciphers)) return -ERANGE; @@ -73,6 +75,18 @@ int gprs_cipher_run(uint8_t *out, uint16_t len, enum gprs_ciph_algo algo, return selected_ciphers[algo]->run(out, len, kc, iv, dir); } +unsigned gprs_cipher_key_length(enum gprs_ciph_algo algo) +{ + switch (algo) { + case GPRS_ALGO_GEA0: return 0; + case GPRS_ALGO_GEA1: return 8; + case GPRS_ALGO_GEA2: return 8; + case GPRS_ALGO_GEA3: return 8; + case GPRS_ALGO_GEA4: return 16; + default: return 0; + } +} + int gprs_cipher_supported(enum gprs_ciph_algo algo) { if (algo >= ARRAY_SIZE(selected_ciphers)) diff --git a/src/gsm/libosmogsm.map b/src/gsm/libosmogsm.map index 3a4a643..3beb1e9 100644 --- a/src/gsm/libosmogsm.map +++ b/src/gsm/libosmogsm.map @@ -31,6 +31,7 @@ gprs_cipher_load; gprs_cipher_register; gprs_cipher_run; gprs_cipher_supported; +gprs_cipher_key_length; gprs_tlli_type; gprs_tmsi2tlli; -- 1.8.3.2

3 3

Osmovom-BB on Raspberry Pi
by Richard Menedetter 16 Jun '14

16 Jun '14

Hi All Just wanted to confirm that I got Osmocom-BB up and running on a Raspberry Pi. I did not use the GPIO UART pins but USB <-> serial converters. I tried Motorola C118 and C155 with success. Everything you need is already described: http://bb.osmocom.org/trac/wiki/GnuArmToolchain http://bb.osmocom.org/trac/wiki/libosmocore http://bb.osmocom.org/trac/wiki/Software/GettingStarted?redirectedfrom=Gett… My previous problem seems to have been a not fully compatible crosscompiled toolchain. (it worked mostly, but I could not log-in to a cell and the spectrum view crashed on the RSSI Firmware. Also if you want transmit capability (or flashing) then you need to activate those features in the makefile. Thanks Sylvain (confirming c118 will work) and all others who are involved!! PS: Any news on the "emulated BTS" that has been presented at last years chaos communication congress? I have 2 C118s + 1 normal USB serial dongle + 1 capable of burst ind. I hope this will suffice to also run also a possible future 1 trasmit phone + 1 receive phone configuration. I assume that even without the filter change it should be enough to send a few meters of distance.

5 10

about sms lost
by Swift 29 May '14

29 May '14

Hi I lost many sms(sent by myself) using the luca/gsmmap branch with my c118 and cp2102; Could the sylvain/burst_ind branch or other branches fix the problem? Regards, Swift. -- View this message in context: http://baseband-devel.722152.n3.nabble.com/about-sms-lost-tp4026485.html Sent from the baseband-devel mailing list archive at Nabble.com.

1 1

lost sms
by changchuan618＠gmail.com 29 May '14

29 May '14

Hi I built the luca/gsmmap branch, and saw many messages in the wireshark with protocol GSM_SMS; but when I tried to capture my sms (sending by my own phone), it does not work, I can not see my sms in wireshark; then I used another phone to send a message to my phone, I saw nothing in wireshark too; Could anyone tell me why? Is it a problem about time slot ? Regards, Swift changchuan618(a)gmail.com

2 2

lost sms
by Swift 29 May '14

29 May '14

Hi I built the luca/gsmmap branch, and saw many messages in the wireshark with protocol GSM_SMS; but when I tried to capture my sms (sending by my own phone), it does not work, I can not see my sms in wireshark; then I used another phone to send a message to my phone, I saw nothing in wireshark too; Could anyone tell me why? Is it a problem about time slot ? Regards, Swift -------------------------------------------------------------------------------- -- View this message in context: http://baseband-devel.722152.n3.nabble.com/lost-sms-tp4026483.html Sent from the baseband-devel mailing list archive at Nabble.com.

2 1

Manual For VTY interface
by R M 28 May '14

28 May '14

Hi, While browsing through the wiki, I did not find a page for the VTY interface. Does it really not exist or did I miss it ? If it does not exist, I am planning to write one and send it to the mailing list. I have gone through some of the commands while reading the code and I want to share what I have learnt. Regards, RM

2 1

Re: http://bb.osmocom.org/trac/ Why no visit?
by Paul Wise 28 May '14

28 May '14

On Wed, May 28, 2014 at 3:00 PM, Holger Hans Peter Freyther wrote: > which language (simplified chinese?) do you offer to trac. There > were no pending updates for babel/trac. Could you give me the HTTP > request you make? wget --header='Accept-Language: zh-cn,en;q=0.5' http://bb.osmocom.org/trac/ -- bye, pabs http://bonedaddy.net/pabs3/

2 1

http://bb.osmocom.org/trac/ Why no visit?
by warriornew 28 May '14

28 May '14

<http://baseband-devel.722152.n3.nabble.com/file/n4026475/QQ%E6%88%AA%E5%9B%…> Why recently osmocombb website can't visit? -- View this message in context: http://baseband-devel.722152.n3.nabble.com/http-bb-osmocom-org-trac-Why-no-… Sent from the baseband-devel mailing list archive at Nabble.com.

3 2

Bounce action notification
by mailman＠lists.osmocom.org 27 May '14

27 May '14

This is a Mailman mailing list bounce action notice: List: baseband-devel Member: bjoern.riemer(a)fokus.fraunhofer.de Action: Subscription disabled. Reason: Excessive or fatal bounces. The triggering bounce notice is attached below. Questions? Contact the Mailman site administrator at mailman(a)lists.osmocom.org.

1 0

R: Re: Sylvain testing branch
by Luca Bongiorni 26 May '14

26 May '14

Hi there, > Try master or jolly/testing > The sylvain/testing branch has some patches for the BTS mode that seem > to break 'normal phone' mode. It means that, at the state of art, the best branch to work with CalypsoBTS is the jolly/testing or the sylvain/testing? Cheers, Luca **************** Il 5 x mille alla nostra Università è un investimento sui giovani, sui loro migliori progetti. Sostiene la libera ricerca. Alimenta le loro speranze nel futuro. Investi il tuo 5 x mille sui giovani. Università degli Studi di Milano codice fiscale 80012650158 http://www.unimi.it/13084.htm?utm_source=firmaMail&utm_medium=email&utm_con…

1 0

Sylvain testing branch
by R M 23 May '14

23 May '14

Hi, I am trying to build the Sylvain testing branch. I am facing an issue there. What I did is as follows: 1. I got the Sylvain testing branch to my computer. 2. I tried to build it and it failed saying that it cannot find the libosmocore library. 3. I changed the top most Makefile to install libosmocore after building. 4. Again I tried to build and it built and installed libosmocore but now Its complaining about osmocom/core/talloc.h not found in sim.c in layer23 folder 6. As per the top Makefile, talloc is disabled in libosmocore but sim.c file does not have conditional include for this header file. Is this a problem or I am doing something wrong ? Regards, RM

2 3

Re: How to fix for problem -- "l1ctl.c:114 FBSB RESP: result=255"?
by warriornew 23 May '14

23 May '14

打一个补丁 patch blog.lishixin.net 自己去博客看吧 -- View this message in context: http://baseband-devel.722152.n3.nabble.com/How-to-fix-for-problem-l1ctl-c-1… Sent from the baseband-devel mailing list archive at Nabble.com.

1 0

c139/c140 jtag anyone?
by Craig Comstock 19 May '14

19 May '14

I'm at the point w/ flashing firmware where I feel like I need to use a debugger w/ JTAG. I figured I could probably use serial line logging somehow but JTAG seems better and I should learn it anyway. Has anyone pried open the shield on a c139/c140 and tried attaching to the JTAG test points that are just inside the shield next to the test points which are accessible via the battery compartment?

2 3

Re : Sylvain testing branch
by Ravi Sharan 18 May '14

18 May '14

Hi, Have you complied the libosmocore separately ? If you are using fedora based distro make sure you have set the path correctly. Regards, Ravi Sharan

1 0

Locked C139 bootloader reverse-engineered
by msokolov＠ivan.Harhan.ORG 15 May '14

15 May '14

Hello fellow hackers, Following my successful reverse eng of Tracfone "unlocking" utility mot931c.exe, I wrote a native Unix/Linux program (tfc139, based on FreeCalypso rvinterf tools) that breaks into locked-down TF C139 phones in the same fashion, with an IRAM payload that enables and jumps to the Calypso boot ROM. Doing so allowed me to run fc-loadtool against one of these Tracfones that still has its original locked-down bootloader intact (*not* overwritten with mot931c), and make a dump of the latter for examination. So here is how the bootloader lock works: the bootloader which sits in the first 0x2000 bytes of flash sector 0 is clearly built together with the main fw image as a single whole (TI's reference firmware is built the same way, so no surprise), and thus the bootloader version changes in sync with the main fw version. Most of the versions seen in the wild are almost byte-identical, the only diffs being some unused signature (?) words at 0x20 and the word at 0x964 giving the initial value to be loaded into the stack pointer - variations in the latter are a linker artifact resulting from how this bootloader is built together with the main fw. Despite the way in which they must have been compiled, the older versions of the bootloader have one good quality: if you are going to break into the bootloader serially (in our familiar way), then only the first 0x2000 bytes of the flash (in fact, even less than that) need to be good; the flash from 0x2000 onward can be blank or filled with garbage or malware or whatever - as long as the boot process is interrupted with a serial download, the jump to 0x20f8 doesn't happen and nothing from 0x2000 onward affects anything. So far, so good. But the newer versions of the bootloader that are part of the newer firmwares for both C11x/123 and C139/140 have an added malicious feature. Before sending what we call PROMPT1 out the serial port and waiting for a possible serial download, the boot code now checks the word in flash at 0x2060. This word needs to equal 0xDDDDDDDD (was it some developer's fascination with bras? - scnr); if this word contains any other value, no serial download opportunity is offered, and the code proceeds directly to the silly routine that emits that "ftmtool error" nonsense, followed by the jump to 0x20f8. All TF-branded C139 phones I've seen have fw version 8.8.17, which features the new malware bootloader. And the word at 0x2060 is zeroed out, resulting in the observed behavior of no serial download opportunity being given on boot. I speculate that perhaps the newer fw versions containing boot code with this malicious feature start out with 0xDDDDDDDD in the word at 0x2060, so that their own developers could do their job, but when shipping phones to end users, the bastards issued some ETM or whatever command to zero that word out, disabling the serial download access - remember that any NOR flash bit can be changed from 1 to 0 at any time, but going the other way around requires erasing and rewriting the whole sector. So what do we do about it? Well, at least the TF-branded C139s still have that ETM memory write command that allows us to break in by writing a little payload into IRAM and smashing the stack while the main fw is running, and we now have a free, source-enabled, Unix/Linux- based tool for performing this break-in. Not too long ago there was someone else on this list who had a newer C139 with Cingular branding (not TF) that also featured the maliciously locked bootloader. Not surprisingly, mot931c wouldn't work on that phone, as this closed source Weendoze binary does a fw version query and refuses to work with any versions other than TF's 8.8.x. But now that we have our own free tool for the hack in question, it may be worth testing if one can break into non-TF phones by the same method. The addresses for the IRAM payload download and the stack smashing may need to be tweaked experimentally, but hey... When the time comes to flash our own FreeCalypso firmware into these phones, I'm thinking of adopting one of the old bootloader versions as our "standard". In fact, the only diff between C11x/123 and C139/140 versions of this boot code is that the latter adds the check for "1003" at 0x803ce0, whereas the former has no such check. Thus we can use the more basic C11x/123 version of the boot code on all hw versions, and make our chainloading more efficient by loading 32 bytes instead of 15332. :) All of the work described above has already been pushed into the freecalypso-sw and freecalypso-reveng Hg repositories on Bitbucket. VLR, SF

1 0

Calypso-BTS: State of Art and Future Improvements
by Luca Bongiorni 14 May '14

14 May '14

Hey folks, Since I am planning to delve deeper into the Calypso-BTS... I was wondering if.... after Sylvain and Jolly's last commits into their "*/testing" branches [1][2]... - Someone else have made some (private) changes/improvements to the sources?! - Is there a TO DO list available for suggested improvements? - Is anyone working on it or it would be interested? And another question... why those branches have not been merged? Cheers, Luca [1] http://cgit.osmocom.org/osmocom-bb/commit/?h=sylvain/testing&id=1b8f488f396… [2] http://cgit.osmocom.org/osmocom-bb/commit/?h=jolly/testing&id=c1d728975f4c0… **************** Il 5 x mille alla nostra Università è un investimento sui giovani, sui loro migliori progetti. Sostiene la libera ricerca. Alimenta le loro speranze nel futuro. Investi il tuo 5 x mille sui giovani. Università degli Studi di Milano codice fiscale 80012650158 http://www.unimi.it/13084.htm?utm_source=firmaMail&utm_medium=email&utm_con…

3 3

Tracfone C139 break-in procedure
by msokolov＠ivan.Harhan.ORG 14 May '14

14 May '14

Hello fellow hackers, As has been discussed on this list a little over a month ago, Mot C139 phones sold with Tracfone branding usually have firmware version 8.8.17, which contains a bootloader in which the serial break-in and download capability has been disabled. However, this locked-down firmware version still has the **16379# keypad command that switches the headset jack back to the UART and presents a variant of TI's RVTMUX interface on this UART; and there exists a Weendoze program called mot931c.exe that: 1. connects to this RVTMUX interface; 2. does some black magic to break into the otherwise locked-down phone; 3. erases and rewrites flash sector 0, replacing the "bad" bootloader version with a "good" one. The elusive part has been step 2 above - just what does this closed source Winblows binary send to the phone to make the initial break-in? Whoever was responsible for producing the locked-down fw in these Tracfones really did close all of the well-known holes: not only have they tied the nIBOOT pin high directly underneath the BGA and disabled the serial access in their own bootloader, but TI's standard ETM_CORE commands which would normally be available over RVTMUX don't work either. Well, I have finally reverse-engineered what this mot931c.exe tool does (by running it under Wine, pointing the Wine-emulated COM port to a Unix pseudo-tty instead of a real serial port, and listening and talking back on the master side of the Unix pty), and here is the secret: Compal's firmware features some non-standard commands of their own invention in their version of TI's ETM, these non-standard commands have *not* been disabled in the TF-branded fw, and one of them is a raw memory write command. (The following description assumes that the reader is familiar with TI's standard versions of RVTMUX and ETM; if you aren't familiar with these things, read my write-up thereof in the FreeCalypso documentation.) Compal's non-standard ETM memory write command has the following format: 0x14 octet: tells the RiViera Trace MUX that the packet is for ETM 0x40 octet: non-std opcode in the place where ETM component ID would normally go 4 octets: absolute address at which the bytes are to be written, in LE bytes order remaining octets before ETM checksum: raw bytes to be written 1 octet: standard ETM command packet checksum at the end (Wrapped in the RVTMUX STX/DLE byte stuffing as usual.) The mot931c tool uses the above ETM memory write command to write 204 (0xCC) bytes at address 0x800000, at the low end of IRAM - this happens with the regular fw still running! So far, so good. How is control then transferred to this downloaded payload? Answer: by smashing the stack! After downloading its payload (in two chunks: first 120 bytes, then the remaining 84), the mot931c tool sends more ETM memory write command packets in exactly the same format, but this time each write is just 4 bytes long. The address being written into starts at 0x837C54, and increments by 4 from there. The data written with each of these commands is 00 00 80 00, i.e., 32-bit word 0x800000 in LE. It is obviously seeking to hit a return address location on the stack, in order to transfer control to the payload it just downloaded. If it keeps getting "ETM command successful" responses from the target, it keeps retrying with incrementing write addresses until it reaches 0x838BF0, at which point it gives up. If this procedure succeeds in hitting the function return address on the stack and thus transferring control to 0x800000, which will indeed succeed when run against the TF firmware in question, the code that's been downloaded into that IRAM location then provides its own very simple serial download protocol whereby the next code stage is downloaded and run. I haven't pursued the process further, as the initial break-in was/is all I'm interested in. I strongly dislike this mot931c.exe tool's Heisenbergian approach of altering the flash content without saving the original first, and my plan is to use this break-in procedure to make FreeCalypso's fc-loadtool work with these TF C139s. Once we are running fc-loadtool, all of this tool's functions will be available just like it currently offers on Openmoko and Pirelli targets: flash dump2bin, flash erase, flash program-bin etc. Put the user back in control, instead of a closed source Weendoze binary that does all of the reflashing without asking the user if she wants it or not. Viva la Revolucion, SF

1 0

Problem with connecting to network
by R M 12 May '14

12 May '14

Hi, I have recently purchased a SIM card. When I use the SIM in Nokia 3310, and try to manually select a particular cell, it says no access. SIM belongs to the same network. If I insert the same SIM in Blackberry Bold 9780, I am able to manually select the same network and even make phone calls. I have set the Network selection mode in Blackberry to Manual. I have also asked it connect only to 2G networks. To debug the issue, I connected the Nokia 3310 to my laptop and observed the messages it exchanged with the network. From the messages, I see that Nokia 3310 is getting a TIMSI assigned from the same cell. But my Nokia 3310 says, No Access. I also see a "DTAP Radio Resources Management Message Type: Channel Release (0x0d)" message from the Network to the phone. What does the above message mean ? Is there any way for me to further debug the issue ? Thanks and Regards, RM

2 5

Re: Useful article on patching Nokia DCT4+ firmware
by msokolov＠ivan.Harhan.ORG 08 May '14

08 May '14

"E:V:A" <xdae3v3a(a)gmail.com> wrote: > That was indeed a very nice and entertaining find. Also the many links > within that document should let you find both useful code and > contacts. Furthermore, what is interesting is that it also provides > a historical perspective of the xgold modems, which should be useful in > paving the way to deeper studies in the more modern versions. Entertaining as it is, keep in mind that the fellow who did that hack and wrote the article about it got *paid* to make those Kosher phones for the religious customers in question. In the absence of such a paid arrangement, I don't really understand why someone would willingly waste her time trying to hack a "modern" phone, dealing with chips sans docs, tivoized bootloaders and firmware that only exists as binaries without source or even semi-src. The big question is: WHY would anyone willingly choose to suffer through that mess, when instead one can choose to use a phone based on the good old Calypso chipset, with full docs, full schematics for some models, and a published semi-src for TI's reference firmware version? Yes, Calypso is old. Ancient, to be more precise. But so what? It still works! If it ain't broke, don't fix it. Dismissing a perfectly working and usable solution merely because of its mature age is irrational. Yes, Calypso-based phones are no longer made, and every existing model that is still obtainable on ebay etc is crippled in one way or another. But so what? We can solve this problem by building our own Calypso- based "dumbphone", and making it exactly the way we like. Yes, Calypso chips themselves aren't made any more either. But what is the total number of people in the world who would want a "dumbphone" running their own free firmware? Is it greater or less than 100? If the number of people desiring such a phone is <= 100, I already have enough Calypso+etc chipsets for all 100 of us sitting in my desk drawer. If the number of interested persons is > 100, there should be more chips still available in the vast nation of China. Yes, the available surplus of Calypso/Iota/Rita chips won't last forever. But if there really are so many of us to exhaust that supply, then surely we could pay some Chinese chip fab to reverse-eng that old silicon and fab new verbatim clones in whatever quantity we need. I just posted an update to the other mailing list, showing where the free & usable Calypso dumbphone project currently stands and how it is progressing: http://lists.openmoko.org/pipermail/community/2014-May/069469.html VLR, SF

1 0

Error loading firmware onto Motorola C115.
by Ravi Sharan 08 May '14

08 May '14

Hi, I am trying out osmocom-bb with the Motorla C115. I have compiled libosmocore as a shared library and osmocom successfully. Also, I have compiled a "arm-none'eabi" cross toolchain from scratch. I get the following error: $ osmocon -p /dev/ttyUSB0 -m c123 ~/osmocom-bb/src/target/firmware/board/compal_e88/hello_world.compalram.bin got 1 bytes from modem, data looks like: 00 . got 2 bytes from modem, data looks like: 00 00 .. got 4 bytes from modem, data looks like: 1b f6 02 00 .... got 1 bytes from modem, data looks like: 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(/home/ravi/osmocom-bb/src/target/firmware/board/compal_e88/hello_world.compalram.bin): file_size=25184, hdr_len=4, dnload_len=25191 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(): 4096 bytes (4096/25191) handle_write(): 4096 bytes (8192/25191) handle_write(): 4096 bytes (12288/25191) handle_write(): 4096 bytes (16384/25191) handle_write(): 4096 bytes (20480/25191) handle_write(): 4096 bytes (24576/25191) handle_write(): 615 bytes (25191/25191) handle_write(): finished 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: 45 E got 1 bytes from modem, data looks like: 53 S got 1 bytes from modem, data looks like: 16 . Received DOWNLOAD NACK from phone, something went wrong :( got 1 bytes from modem, data looks like: 66 f got 1 bytes from modem, data looks like: 74 t got 1 bytes from modem, data looks like: 6d m got 1 bytes from modem, data looks like: 74 t got 1 bytes from modem, data looks like: 6f o got 1 bytes from modem, data looks like: 6f o got 1 bytes from modem, data looks like: 6c l Received FTMTOOL from phone, ramloader has aborted got 1 bytes from modem, data looks like: 65 e got 1 bytes from modem, data looks like: 72 r got 1 bytes from modem, data looks like: 72 r got 1 bytes from modem, data looks like: 6f o got 1 bytes from modem, data looks like: 72 r 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 Can the error be because of the toolchain ? Or can it be that my device is refusing connection with osmocon ? Thanks in advance. Ravi Sharan

2 2

Useful article on patching Nokia DCT4+ firmware
by Andrew Tipton 06 May '14

06 May '14

Hi folks, Came across this article in the latest PoC||GTFO journal describing (part of) the process for patching firmware on Nokia DCT4+ phones. The good stuff is pages 22-29 of this file: http://openwall.info/wiki/_media/people/solar/pocorgtfo03.pdf Alas, this does not appear to permit patching the first 1MB of firmware, so may not be helpful for OsmocomBB. But perhaps someone with more time on their hands can take this and run with it... Cheers, -Andrew

2 1

baseband-devel unsubscribe notification
by mailman-bounces＠lists.osmocom.org 05 May '14

05 May '14

rodrigo(a)chupelupe.com.ar has been removed from baseband-devel.

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel May 2014