Fw: Re: mobile - making a call

[eisencah eisenach]

So any ideea where to look for the answer to the UPDATE_BINARY message? 
Can I have a buffer overflow on UART RX? Is the buffer size selectable 
somewhere?

--- On Wed, 5/4/11, eisencah eisenach <wbg_1000 at yahoo.com> wrote:

From: eisencah eisenach <wbg_1000 at yahoo.com>
Subject: Re: mobile - making a call
To: baseband-devel at lists.osmocom.org
Date: Wednesday, May 4, 2011, 4:58 PM

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 at gnumonks.org> wrote:

From: Harald Welte <laforge at gnumonks.org>
Subject: Re: mobile - making a call
To: "eisencah eisenach" <wbg_1000 at 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 at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20110507/7bc4b64b/attachment-0001.htm>