- baseband-devel - lists.osmocom.org

R: Re: lost dump ?!?!?
by screaming-pain＠libero.it 06 May '11

06 May '11

Thanks Alex, I actually played a bit with the code and found out that exactly half of the times the write() call in the function gsmtap_fd_cb() (gsmtap_util.c) fails because of EAGAIN or EWOULDBLOCK. I implemented a retransmission in this case and this solve the problem: all the gsmtap are successfully sent and received. Though, I suspect is impacting negatively on the rest of the mobile program. Anyway I do not have a real evidence of this only the fact that after the modification I have never had a successful location update. Do you think this is plausible? am I degrading the overall performances when trying to get all the gsmtap? Can i solve this problem? Thanks Alex and list, Loretta >----Messaggio originale---- >Da: vamposdecampos(a)gmail.com >Data: 6-mag-2011 8.35 >A: "screaming-pain(a)libero.it"<screaming-pain(a)libero.it> >Cc: <baseband-devel(a)lists.osmocom.org> >Ogg: Re: lost dump ?!?!? > >On Thu, May 5, 2011 at 5:28 PM, screaming-pain(a)libero.it ><screaming-pain(a)libero.it> wrote: >> Hi list, >> >> I know I am very slow in understanding osmocom-bb, anyway this is just a quick >> question. >> Is it possible that some of the gsmtap messages are getting lost? >> For example I can see a LOCATION UPDATE and a LOCATION ACCEPT from the >> 'mobile' application log but there aren't the corresponding messages in the >> wireshark capture, >> though this does not always happen, I mean I had captures of location updates >> other times, this is why I am wondering if they are getting lost and what it >> does depend on. >> for what I understood the gsmtap functions utilities are in gsmtap_util.c and >> the one to send the messages on the socket is called by l1ctl.c am I right? >> Can you help me understanding why I cannot see all the messages? >> >> thank you in advance >> Loretta > >Hi, > >I've had this happen to me when I wasn't receiving the gsmtap packets. > >Specifically, I had the gsmtap packets sent over the network (i.e., >non-localhost). There was no UDP listener on the receiving end, such >that ICMP port-unreachable replies were being sent back. It would >appear that this causes the sender's kernel to snub some of the >outgoing packets. I don't know if the same happens on localhost. > >If this is your case, you can try "iptables -I INPUT -p udp -d 4729 -j >DROP", or something like "nc -l -u 4729 > /dev/null". > >Cheers, >Alex > >

3 2

lost dump ?!?!?
by screaming-pain＠libero.it 06 May '11

06 May '11

Hi list, I know I am very slow in understanding osmocom-bb, anyway this is just a quick question. Is it possible that some of the gsmtap messages are getting lost? For example I can see a LOCATION UPDATE and a LOCATION ACCEPT from the 'mobile' application log but there aren't the corresponding messages in the wireshark capture, though this does not always happen, I mean I had captures of location updates other times, this is why I am wondering if they are getting lost and what it does depend on. for what I understood the gsmtap functions utilities are in gsmtap_util.c and the one to send the messages on the socket is called by l1ctl.c am I right? Can you help me understanding why I cannot see all the messages? thank you in advance Loretta

3 2

Questions regarding testing branch
by ArMaND VanHell 05 May '11

05 May '11

Some questions about Sylvain testing branch: why is not merged SIMreader into master branch? is planned for mobile aplication to support SMS (sending/receiving)? Thank you, ArMaND VanHell

1 0

[PATCH 0/5] merge mtk-loader to master
by Wolfram Sang 05 May '11

05 May '11

The first four patches remove some hardcoded calypso-dependencies (as discussed on the list). The final one then adds the mtk-stuff with comments from Sylvain addressed (hopefully). The new mtk-loader was succesfully tested on my Sciphone G2 by loading and executing a bootloader. The compal loaders still compile fine (and no code was changed there). This should get rid of the branches remotes/origin/steve-m/loader_sciphone remotes/origin/steve-m/mtk_hack and should ease merging new platforms in general a bit more. Regards, Wolfram Wolfram Sang (5): comm: msgb: don't set backlight on error lib: move delay.c from calypso to lib cfi_flash: delete unused defines uart.h: move header out of calypso-directory target/boards: add infrastructure for loaders for Mediatek platforms src/Makefile | 8 +- src/target/firmware/Makefile.mtk | 33 ++ src/target/firmware/apps/loader/main.c | 2 +- src/target/firmware/apps/loader_mtk/main.c | 366 ++++++++++++++++++++ src/target/firmware/board/compal_e86/init.c | 2 +- src/target/firmware/board/compal_e88/init.c | 2 +- src/target/firmware/board/compal_e99/init.c | 2 +- src/target/firmware/board/gta0x/init.c | 2 +- src/target/firmware/board/mediatek/macros.S | 76 +++++ src/target/firmware/board/mediatek/ram.lds | 112 +++++++ src/target/firmware/board/mediatek/start.ram.S | 26 ++ src/target/firmware/board/mediatek/uart.c | 426 ++++++++++++++++++++++++ src/target/firmware/board/mt62xx/init.c | 139 ++++++++ src/target/firmware/board/pirelli_dpl10/init.c | 2 +- src/target/firmware/calypso/Makefile | 2 +- src/target/firmware/calypso/delay.c | 16 - src/target/firmware/calypso/uart.c | 2 +- src/target/firmware/comm/msgb.c | 1 - src/target/firmware/comm/sercomm.c | 2 +- src/target/firmware/comm/sercomm_cons.c | 2 +- src/target/firmware/flash/cfi_flash.c | 5 - src/target/firmware/include/calypso/uart.h | 32 -- src/target/firmware/include/mtk/emi.h | 42 +++ src/target/firmware/include/mtk/mt6235.h | 74 ++++ src/target/firmware/include/mtk/system.h | 195 +++++++++++ src/target/firmware/include/uart.h | 32 ++ src/target/firmware/lib/Makefile | 2 +- src/target/firmware/lib/console.c | 2 +- src/target/firmware/lib/delay.c | 16 + 29 files changed, 1556 insertions(+), 67 deletions(-) create mode 100644 src/target/firmware/Makefile.mtk create mode 100644 src/target/firmware/apps/loader_mtk/main.c create mode 100644 src/target/firmware/board/mediatek/macros.S create mode 100644 src/target/firmware/board/mediatek/ram.lds create mode 100644 src/target/firmware/board/mediatek/start.ram.S create mode 100644 src/target/firmware/board/mediatek/uart.c create mode 100644 src/target/firmware/board/mt62xx/init.c delete mode 100644 src/target/firmware/calypso/delay.c delete mode 100644 src/target/firmware/include/calypso/uart.h create mode 100644 src/target/firmware/include/mtk/emi.h create mode 100644 src/target/firmware/include/mtk/mt6235.h create mode 100644 src/target/firmware/include/mtk/system.h create mode 100644 src/target/firmware/include/uart.h create mode 100644 src/target/firmware/lib/delay.c -- 1.7.2.5

2 6

Anyone based in India on this list? Students?
by Harald Welte 05 May '11

05 May '11

I'm looking for somebody in India who has a deep GSM interest and who is preferrably a student. If you're quick, I have a free giveaway for you. Please simply e-mail me, details will follow. 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)

2 2

Re: mobile - making a call
by eisencah eisenach 04 May '11

04 May '11

Done some more digging in the logs and it seems the sim state machine has locked earlier (when attaching to the network) while waiting for some response on UPDATE BINARY. Does this sounds familiar to anyone? :) GOOD CASE: [0;m[1;32m<0004> gsm48_mm.c:1557 AUTHENTICATION RESPONSE [0;m[1;34m<0001> gsm48_rr.c:4904 (ms 1) Message 'RR_DATA_REQ' received in state dedicated [0;m[1;34m<0001> gsm48_rr.c:235 Using and incrementing V(SD) = 0 (pdisc 5) [0;m[0;35m<000e> sim.c:209 got new job: SIM_JOB_UPDATE_BINARY (handle=00000005) [0;m[0;35m<000e> sim.c:241 SELECT (file=0x6f20) [0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) [0;m[0;35m<000e> sim.c:876 received APDU (len=0 sw1=0x9f sw2=0x0f) [0;m[0;35m<000e> sim.c:949 command successfull [0;m[0;35m<000e> sim.c:571 GET RESPONSE (len=15) [0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) [0;m[0;35m<000e> sim.c:876 received APDU (len=15 sw1=0x90 sw2=0x00) [0;m[0;35m<000e> sim.c:949 command successfull [0;m[0;35m<000e> sim.c:294 UPDATE BINARY (offset=0 len=9) [0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xd6) [0;m[0;35m<000e> sim.c:876 received APDU (len=0 sw1=0x90 sw2=0x00) [0;m[0;35m<000e> sim.c:949 command successfull [0;m[0;35m<000e> sim.c:151 sending result to callback function (type=0) [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) BAD CASE: [0;m[1;32m<0004> gsm48_mm.c:1557 AUTHENTICATION RESPONSE [0;m[1;34m<0001> gsm48_rr.c:4904 (ms 1) Message 'RR_DATA_REQ' received in state dedicated [0;m[1;34m<0001> gsm48_rr.c:235 Using and incrementing V(SD) = 0 (pdisc 5) [0;m[0;35m<000e> sim.c:209 got new job: SIM_JOB_UPDATE_BINARY (handle=00000005) [0;m[0;35m<000e> sim.c:241 SELECT (file=0x6f20) [0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) [0;m[0;35m<000e> sim.c:876 received APDU (len=0 sw1=0x9f sw2=0x0f) [0;m[0;35m<000e> sim.c:949 command successfull [0;m[0;35m<000e> sim.c:571 GET RESPONSE (len=15) [0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) [0;m[0;35m<000e> sim.c:876 received APDU (len=15 sw1=0x90 sw2=0x00) [0;m[0;35m<000e> sim.c:949 command successfull [0;m[0;35m<000e> sim.c:294 UPDATE BINARY (offset=0 len=9) [0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xd6) [0;m[1;32m<0004> gsm48_mm.c:3695 (ms 1) Received 'RR_DATA_IND' from RR in state location updating initiated --- On Wed, 5/4/11, Harald Welte <laforge(a)gnumonks.org> wrote: From: Harald Welte <laforge(a)gnumonks.org> Subject: Re: mobile - making a call To: "eisencah eisenach" <wbg_1000(a)yahoo.com> Date: Wednesday, May 4, 2011, 11:59 AM On Tue, May 03, 2011 at 03:02:58AM -0700, eisencah eisenach wrote: > So is as if the message for the sim job doesn't get pulled from the > queue, "got new job: SIM_JOB_RUN_GSM_ALGO " never appears. Must say > the computer I use osmocom on is not exactly a rocket :) (is a 500Mhz > celeron with ubuntu 6.10) , and It gets slowed down when running the > hole thing. Can that be the cause? Mihai. The L1CTL protocol goes through a unix domain socket, and you can trace it in either osmocon or in the mobile program itself. It should be relatively easy to detect if the RUN_GSM_ALGO is transmitted by mobile, or if it is lost, where it is lost. -- - 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

mobile - making a call
by eisencah eisenach 03 May '11

03 May '11

Hi. I'm using mobile application (sylvain/testing branch) to initiate calls. My experience is that the call si succesfull in about 20% of cases. Most of the time the connection seems to be lost after receiving the AUTHENTICATION REQUEST message. Has anyone else had this experience, it has to do with the power measurements above? Thanks, Mihai. [0;m[1;33m<0005> gsm48_cc.c:496 Sending MMCC_EST_REQ [0;m[1;32m<0004> gsm48_mm.c:3568 (ms 1) Received 'MMCC_EST_REQ' event in state MM idle [0;m[1;32m<0004> gsm48_mm.c:3571 -> substate normal service [0;m[1;32m<0004> gsm48_mm.c:3573 -> callref 1, transaction_id 255 [0;m[1;32m<0004> gsm48_mm.c:2873 Init MM Connection. [0;m[1;32m<0004> gsm48_mm.c:1332 New MM Connection (proto 0x03 trans_id 255 ref 1) [0;m[1;32m<0004> gsm48_mm.c:1291 (ref 1) new state IDLE -> CONN_PEND [0;m[1;32m<0004> gsm48_mm.c:2650 CM SERVICE REQUEST (cause 9) [0;m[1;32m<0004> gsm48_mm.c:2681 -> Using TMSI [0;m[1;34m<0001> gsm48_rr.c:4904 (ms 1) Message 'RR_EST_REQ' received in state idle [0;m[1;37m<000d> gsm48_rr.c:1181 Establish radio link due to mobility management request [0;m[34m<0003> gsm322.c:3319 (ms 1) Event 'EVENT_LEAVE_IDLE' for Cell selection in state 'C3 camped normally' [0;m[34m<0003> gsm322.c:2959 Going to camping frequency 47. [0;m[34m<0003> gsm322.c:252 Sync to ARFCN=47 rxlev=-61 (Sysinfo, ccch mode NON-COMB) [0;m[1;34m<0001> gsm48_rr.c:363 new state idle -> connection pending [0;m[1;34m<0001> gsm48_rr.c:1313 CHANNEL REQUEST: e0 (Orig TCH/F) [0;m[1;32m<0004> gsm48_mm.c:887 new state MM IDLE, normal service -> wait for RR connection (MM connection) [0;m[34m<0003> gsm322.c:2434 Channel synched. (ARFCN=47, snr=16, BSIC=33) [0;m[1;34m<0001> gsm322.c:2461 using DSC of 90 [0;m[34m<0003> gsm48_rr.c:4541 Channel provides data. [0;m[1;34m<0001> gsm48_rr.c:1452 RANDOM ACCESS (requests left 5) [0;m[1;34m<0001> gsm48_rr.c:1509 RANDOM ACCESS (Tx-integer 32 combined no S(lots) 0 ra 0xed) [0;m[1;34m<0001> gsm48_rr.c:1547 Use MS-TXPWR-MAX-CCH power value 5 (33 dBm) [0;m[1;34m<0001> gsm48_rr.c:1452 RANDOM ACCESS (requests left 4) [0;m[1;34m<0001> gsm48_rr.c:1509 RANDOM ACCESS (Tx-integer 32 combined no S(lots) 217 ra 0xed) [0;m[1;34m<0001> gsm48_rr.c:1547 Use MS-TXPWR-MAX-CCH power value 5 (33 dBm) [0;m[1;34m<0001> gsm48_rr.c:2258 IMMEDIATE ASSIGNMENT: [0;m[1;34m<0001> gsm48_rr.c:2270 (ta 1/553m ra 0xed chan_nr 0x41 MAIO 2 HSN 36 TS 1 SS 0 TSC 1) [0;m[1;34m<0001> gsm48_rr.c:2204 request ed matches (fn=4,24,16) [0;m[1;34m<0001> gsm48_rr.c:2304 resetting scheduler [0;m[1;34m<0001> gsm48_rr.c:2858 decoding mobile allocation [0;m[1;34m<0001> sysinfo.c:396 Serving cell ARFCN #0: 31 [0;m[1;34m<0001> sysinfo.c:396 Serving cell ARFCN #1: 44 [0;m[1;34m<0001> sysinfo.c:396 Serving cell ARFCN #2: 47 [0;m[1;34m<0001> sysinfo.c:396 Serving cell ARFCN #3: 57 [0;m[1;34m<0001> sysinfo.c:410 Hopping ARFCN: 0 (bit 31) [0;m[1;34m<0001> sysinfo.c:410 Hopping ARFCN: 1 (bit 44) [0;m[1;34m<0001> sysinfo.c:410 Hopping ARFCN: 2 (bit 47) [0;m[1;34m<0001> sysinfo.c:410 Hopping ARFCN: 3 (bit 57) [0;m[1;34m<0001> gsm48_rr.c:3019 sending establish message [0;m[1;34m<0001> gsm48_rr.c:235 Using and incrementing V(SD) = 0 (pdisc 5) [0;m[1;34m<0001> gsm48_rr.c:2763 setting indicated TA 1 (actual TA 1) [0;m[1;34m<0001> gsm48_rr.c:2774 using last SACCH timeout 16 [0;m[1;34m<0001> gsm48_rr.c:774 stopping pending timer T_meas [0;m[1;34m<0001> gsm48_rr.c:2666 MEAS REP: pwr=5 TA=1 meas-invalid=1 rxlev-full=-110 rxlev-sub=-110 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 [0;m[1;34m<0001> gsm48_rr.c:2796 establishing channel in dedicated mode [0;m[1;34m<0001> gsm48_rr.c:2800 Channel type 64, subch 0, ts 1, mode 0, cipher 1 [0;m[1;34m<0001> gsm48_rr.c:363 new state connection pending -> dedicated [0;m[1;32m<0004> gsm48_mm.c:3695 (ms 1) Received 'RR_EST_CNF' from RR in state wait for RR connection (MM connection) [0;m[1;32m<0004> gsm48_mm.c:431 starting T3230 (MM connection timeout) with 15.0 seconds [0;m[1;32m<0004> gsm48_mm.c:897 new state wait for RR connection (MM connection) -> wait for outgoing MM connection [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 1 (actual ta 1) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 5 [0;m[1;34m<0001> gsm48_rr.c:1828 New SYSTEM INFORMATION 5 [0;m[1;34m<0001> gsm48_rr.c:1583 Complete set of SI5* for BA(0) [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 1 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 3 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 6 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 13 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 17 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 19 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 20 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 21 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 24 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 26 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 30 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 33 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 36 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 37 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 40 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 41 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 42 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 47 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 49 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 58 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 59 [0;m[1;32m<0004> gsm48_mm.c:4083 (ms 1) Received 'MM_EVENT_SYSINFO' event in state wait for outgoing MM connection [0;m[34m<0003> gsm322.c:2104 Sysinfo of selected cell is updated. [0;m[1;32m<0004> gsm48_mm.c:3695 (ms 1) Received 'RR_DATA_IND' from RR in state wait for outgoing MM connection [0;m[1;32m<0004> gsm48_mm.c:3863 (ms 1) Received 'MT_MM_AUTH_REQ' in MM state wait for outgoing MM connection [0;m[1;32m<0004> gsm48_mm.c:468 stopping pending (periodic loc. upd. delay) timer T3212 [0;m[1;32m<0004> gsm48_mm.c:1533 AUTHENTICATION REQUEST (seq 1) [0;m[1;32m<0004> subscriber.c:898 Generating KEY at SIM [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 5 [0;m[1;34m<0001> gsm48_rr.c:4493 setting new ta and tx_power [0;m[1;34m<0001> gsm48_rr.c:609 MON: f=47 lev=-60 snr=11 ber= 27 LAI=226 01 2b96 ID=e328 TA=0 pwr=5 TS=1/0 [0;m[1;34m<0001> gsm48_rr.c:2666 MEAS REP: pwr=5 TA=0 meas-invalid=0 rxlev-full=-60 rxlev-sub=-60 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 5 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 6 [0;m[1;34m<0001> gsm48_rr.c:4493 setting new ta and tx_power [0;m[1;34m<0001> gsm48_rr.c:609 MON: f=47 lev=-58 snr= 0 ber= 17 LAI=226 01 2b96 ID=e328 TA=0 pwr=6 TS=1/0 [0;m[1;34m<0001> gsm48_rr.c:2666 MEAS REP: pwr=6 TA=0 meas-invalid=0 rxlev-full=-58 rxlev-sub=-58 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 7 [0;m[1;34m<0001> gsm48_rr.c:4493 setting new ta and tx_power [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 7 [0;m[1;34m<0001> gsm48_rr.c:609 MON: f=47 lev=-59 snr= 0 ber= 0 LAI=226 01 2b96 ID=e328 TA=0 pwr=7 TS=1/0 [0;m[1;34m<0001> gsm48_rr.c:2666 MEAS REP: pwr=7 TA=0 meas-invalid=0 rxlev-full=-59 rxlev-sub=-59 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 8 [0;m[1;34m<0001> gsm48_rr.c:4493 setting new ta and tx_power [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 8 [0;m[1;34m<0001> gsm48_rr.c:609 MON: f=47 lev=-57 snr= 0 ber= 18 LAI=226 01 2b96 ID=e328 TA=0 pwr=8 TS=1/0 [0;m[1;34m<0001> gsm48_rr.c:2666 MEAS REP: pwr=8 TA=0 meas-invalid=0 rxlev-full=-57 rxlev-sub=-57 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 8 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 9 [0;m[1;34m<0001> gsm48_rr.c:4493 setting new ta and tx_power [0;m[1;34m<0001> gsm48_rr.c:609 MON: f=47 lev=-57 snr= 0 ber= 49 LAI=226 01 2b96 ID=e328 TA=0 pwr=9 TS=1/0 [0;m[1;34m<0001> gsm48_rr.c:2666 MEAS REP: pwr=9 TA=0 meas-invalid=0 rxlev-full=-57 rxlev-sub=-57 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 9 [0;m[1;32m<0004> gsm48_mm.c:3695 (ms 1) Received 'RR_DATA_IND' from RR in state wait for outgoing MM connection [0;m[1;32m<0004> gsm48_mm.c:3863 (ms 1) Received 'MT_MM_AUTH_REQ' in MM state wait for outgoing MM connection [0;m[1;32m<0004> gsm48_mm.c:1533 AUTHENTICATION REQUEST (seq 1) [0;m[1;32m<0004> subscriber.c:898 Generating KEY at SIM [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 9 [0;m[1;34m<0001> gsm48_rr.c:609 MON: f=47 lev=-57 snr= 0 ber= 32 LAI=226 01 2b96 ID=e328 TA=0 pwr=9 TS=1/0 [0;m[1;34m<0001> gsm48_rr.c:2666 MEAS REP: pwr=9 TA=0 meas-invalid=0 rxlev-full=-57 rxlev-sub=-57 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 10 [0;m[1;34m<0001> gsm48_rr.c:4493 setting new ta and tx_power [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 10 [0;m[1;34m<0001> gsm48_rr.c:609 MON: f=47 lev=-57 snr= 0 ber= 41 LAI=226 01 2b96 ID=e328 TA=0 pwr=10 TS=1/0 [0;m[1;34m<0001> gsm48_rr.c:2666 MEAS REP: pwr=10 TA=0 meas-invalid=0 rxlev-full=-57 rxlev-sub=-57 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 10 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 10 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 10 [0;m[1;34m<0001> gsm48_rr.c:609 MON: f=47 lev=-58 snr= 0 ber= 74 LAI=226 01 2b96 ID=e328 TA=0 pwr=10 TS=1/0 [0;m[1;34m<0001> gsm48_rr.c:2666 MEAS REP: pwr=10 TA=0 meas-invalid=0 rxlev-full=-58 rxlev-sub=-58 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 11 [0;m[1;34m<0001> gsm48_rr.c:4493 setting new ta and tx_power [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 11 [0;m[1;34m<0001> gsm48_rr.c:609 MON: f=47 lev=-59 snr= 0 ber= 9 LAI=226 01 2b96 ID=e328 TA=0 pwr=11 TS=1/0 [0;m[1;34m<0001> gsm48_rr.c:2666 MEAS REP: pwr=11 TA=0 meas-invalid=0 rxlev-full=-59 rxlev-sub=-59 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 11 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 11 [0;m[1;34m<0001> gsm48_rr.c:609 MON: f=47 lev=-58 snr= 0 ber= 35 LAI=226 01 2b96 ID=e328 TA=0 pwr=11 TS=1/0 [0;m[1;34m<0001> gsm48_rr.c:2666 MEAS REP: pwr=11 TA=0 meas-invalid=0 rxlev-full=-58 rxlev-sub=-58 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 [0;m[1;34m<0001> gsm48_rr.c:3174 channel release request with cause 0x00) [0;m[1;34m<0001> gsm48_rr.c:363 new state dedicated -> release pending [0;m[1;34m<0001> gsm48_rr.c:738 starting T3110 with 1.500 seconds [0;m[1;37m<000d> gsm48_rr.c:4666 Requested channel aborted [0;m[1;34m<0001> gsm48_rr.c:798 stopping pending timer T3110 [0;m[1;34m<0001> gsm48_rr.c:363 new state release pending -> idle [0;m[34m<0003> gsm322.c:3319 (ms 1) Event 'EVENT_RET_IDLE' for Cell selection in state 'C3 camped normally' [0;m[34m<0003> gsm322.c:541 new state 'C3 camped normally' -> 'C5 choose cell' [0;m[34m<0003> gsm322.c:2820 No BA range(s), try sysinfo. [0;m[34m<0003> gsm322.c:2859 free sysinfo arfcn=47 [0;m[34m<0003> gsm322.c:2859 free sysinfo arfcn=66 [0;m[1;32m<0004> gsm48_mm.c:3695 (ms 1) Received 'RR_REL_IND' from RR in state wait for outgoing MM connection [0;m[1;32m<0004> gsm48_mm.c:495 stopping pending (MM connection timeout) timer T3230 [0;m[1;32m<0004> gsm48_mm.c:1367 Release any MM Connection [0;m[1;32m<0004> gsm48_mm.c:1348 Freeing MM Connection [0;m[1;32m<0004> gsm48_mm.c:1291 (ref 1) new state CONN_PEND -> IDLE [0;m[1;33m<0005> gsm48_cc.c:2122 (ms 1) Received 'MMCC_ERR_IND' in CC state MM_CONNECTION_PEND [0;m[1;33m<0005> gsm48_cc.c:189 (ms 1 ti ff) Sending 'MNCC_REL_IND' to MNCC. [0;m[1;37m<0007> mnccms.c:336 Call has been released (cause 16)

2 3

AW: mobile - making a call
by Andreas.Eversberg 03 May '11

03 May '11

hi, can you try a different sim / different network? andreas

1 0

RMS / FSF / OsmocomBB / Free Software GSM phone
by Harald Welte 02 May '11

02 May '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Some months ago, Richard Stallman (rms) has contacted me regarding my work with OsmocomBB. As it is not a big surprise to us, he is really interested in the project. After all, it would be the first mobile phone that he himself would be able to use, given that there is no proprietary software on the baseband anymore. And of course it would enable loads of other freedom-loving users to finally have an alternative to the proprietary telephony world. Here in Morocco, I've had some further discussion on the topic face to face with him, and he is sort of unhappy with the fact that nobody is working on making an actual self-contained phone (no matter how simple or limited in features) that can be used by a regular user as 'just a phone'. I explained to him that our motivation is mostly a different one (research, security, GSM-attached PBX, etc.) and thus there is no intrinsic motivation to work towards a more user-friendly version. Furthermore, we are system level hackers with an interest in communications, not particularly people who like to work on a UI or usability. So we agreed to make a public call for volunteers to wokr on that aspect of the phone. I understand this will likely cause some effort on our side (fencing off poeple who don't have the neccessary skills, integrating such code, finally deciding on a RTOS to use, etc.). However, I more or less see it as my (and our?) duty to realize the potential of our protocol stack and baseband firmware. Next to all our own self-motivated personal interestes, there is a bigger cause that we can help along: Free Software based telephony. So the least we can do is to try to find somebody who can work on that part, and help developer[s] to interact with our code. It's the question of whether we are just hacking away on our personal little pet, or if we try to achieve something bigger. I've already drafted a version of the 'job description' and with some luck the FSF will soon publish it, reaching out beyond our existing small Osmocom community. e will try to draft a similar job description related to MS-side GPRS support (L1, RLC/MAC, ..). That would be yet another area where we would appreciate some contribution, and which eventually be important beyond our existing voice telephony capabilities. 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) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iD8DBQFNvs0JXaXGVTD0i/8RArkDAKCONleE9HJ2i1jp7L/XnMY0YweIjACbB8Lz puH7X4lkqY8AqzU0SAlOAxM= =Cmo8 -----END PGP SIGNATURE-----

5 6

[PATCH] linuxlist.h: silence a noisy warning
by Wolfram Sang 02 May '11

02 May '11

Fixes a couple of warnings like this: In file included from ../../shared/libosmocore/include/osmocom/core/msgb.h:24:0, from include/comm/sercomm.h:6, from apps/loader/main.c:41: ../../shared/libosmocore/include/osmocom/core/linuxlist.h: In function 'prefetch': ../../shared/libosmocore/include/osmocom/core/linuxlist.h:10:41: warning: unused parameter 'x' Signed-off-by: Wolfram Sang <wolfram(a)the-dreams.de> --- .../libosmocore/include/osmocom/core/linuxlist.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/shared/libosmocore/include/osmocom/core/linuxlist.h b/src/shared/libosmocore/include/osmocom/core/linuxlist.h index fb99c5e..ff2c491 100644 --- a/src/shared/libosmocore/include/osmocom/core/linuxlist.h +++ b/src/shared/libosmocore/include/osmocom/core/linuxlist.h @@ -7,7 +7,7 @@ #define inline __inline__ #endif -static inline void prefetch(const void *x) {;} +static inline void prefetch(__attribute__((unused)) const void *x) {;} /** * container_of - cast a member of a structure out to the containing structure -- 1.7.2.5

2 1