<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">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? :) <br><br>GOOD CASE:<br><0004> gsm48_mm.c:1557 AUTHENTICATION RESPONSE<br><0001> gsm48_rr.c:4904 (ms 1) Message 'RR_DATA_REQ' received in state dedicated<br><0001> gsm48_rr.c:235 Using and incrementing V(SD) = 0 (pdisc 5)<br><000e> sim.c:209 got new job: SIM_JOB_UPDATE_BINARY (handle=00000005)<br><000e> sim.c:241 SELECT (file=0x6f20)<br><000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4)<br><000e> sim.c:876 received APDU (len=0 sw1=0x9f sw2=0x0f)<br><000e> sim.c:949 command
 successfull<br><000e> sim.c:571 GET RESPONSE (len=15)<br><000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0)<br><000e> sim.c:876 received APDU (len=15 sw1=0x90 sw2=0x00)<br><000e> sim.c:949 command successfull<br><000e> sim.c:294 UPDATE BINARY (offset=0 len=9)<br><000e> sim.c:187 sending APDU (class 0xa0, ins 0xd6)<br><000e> sim.c:876 received APDU (len=0 sw1=0x90 sw2=0x00)<br><000e> sim.c:949 command successfull<br><000e> sim.c:151 sending result to callback function (type=0)<br><0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0)<br><br>BAD CASE:<br><0004> gsm48_mm.c:1557 AUTHENTICATION RESPONSE<br><0001> gsm48_rr.c:4904 (ms 1) Message 'RR_DATA_REQ' received in state dedicated<br><0001> gsm48_rr.c:235 Using and
 incrementing V(SD) = 0 (pdisc 5)<br><000e> sim.c:209 got new job: SIM_JOB_UPDATE_BINARY (handle=00000005)<br><000e> sim.c:241 SELECT (file=0x6f20)<br><000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4)<br><000e> sim.c:876 received APDU (len=0 sw1=0x9f sw2=0x0f)<br><000e> sim.c:949 command successfull<br><000e> sim.c:571 GET RESPONSE (len=15)<br><000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0)<br><000e> sim.c:876 received APDU (len=15 sw1=0x90 sw2=0x00)<br><000e> sim.c:949 command successfull<br><000e> sim.c:294 UPDATE BINARY (offset=0 len=9)<br><000e> sim.c:187 sending APDU (class 0xa0, ins 0xd6)<br><0004> gsm48_mm.c:3695 (ms 1) Received 'RR_DATA_IND' from RR in state location updating initiated<br><br><br>--- On <b>Wed, 5/4/11, Harald
 Welte <i><laforge@gnumonks.org></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: Harald Welte <laforge@gnumonks.org><br>Subject: Re: mobile - making a call<br>To: "eisencah eisenach" <wbg_1000@yahoo.com><br>Date: Wednesday, May 4, 2011, 11:59 AM<br><br><div class="plainMail">On Tue, May 03, 2011 at 03:02:58AM -0700, eisencah eisenach wrote:<br><br>> So is as if the message for the sim job doesn't get pulled from the<br>> queue, "got new job: SIM_JOB_RUN_GSM_ALGO " never appears.  Must say<br>> the computer I use osmocom on is not exactly a rocket :) (is a 500Mhz<br>> celeron with ubuntu 6.10) , and It gets slowed down when running the<br>> hole thing. Can that be the cause?  Mihai.<br><br>The L1CTL protocol goes through a unix domain socket, and you can trace<br>it in either osmocon or in the mobile program itself.  It should
 be<br>relatively easy to detect if the RUN_GSM_ALGO is transmitted by mobile,<br>or if it is lost, where it is lost.<br><br>-- <br>- Harald Welte <<a ymailto="mailto:laforge@gnumonks.org" href="/mc/compose?to=laforge@gnumonks.org">laforge@gnumonks.org</a>>           <a href="http://laforge.gnumonks.org/" target="_blank">http://laforge.gnumonks.org/</a><br>============================================================================<br>"Privacy in residential applications is a desirable marketing option."<br>                                                  (ETSI EN 300 175-7 Ch. A6)<br></div></blockquote></td></tr></table>