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@yahoo.com wrote:
From: eisencah eisenach wbg_1000@yahoo.com Subject: Re: mobile - making a call To: baseband-devel@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@gnumonks.org wrote:
From: Harald Welte laforge@gnumonks.org Subject: Re: mobile - making a call To: "eisencah eisenach" wbg_1000@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.
So any ideea where to look for the answer to the UPDATE_BINARY message?
No not really ...
But there is a good reason the SIM driver is not in master ... it sucks at several level, including blocking behavior in interrupt context IIRC, so it's totally plausible your machine speed triggers some weird things.
My advice would be to: - Cleanup the SIM driver - Bypass it in the code and try to access a real PCSC device locally rather than the built in SIM reader.
Both are non-trivial of course.
Cheers,
Sylvain
Hi, * Sylvain Munaut 246tnt@gmail.com [2011-05-09 11:30]:
So any ideea where to look for the answer to the UPDATE_BINARY message?
No not really ...
But there is a good reason the SIM driver is not in master ... it sucks at several level, including blocking behavior in interrupt context IIRC, so it's totally plausible your machine speed triggers some weird things.
My advice would be to:
- Cleanup the SIM driver
- Bypass it in the code and try to access a real PCSC device locally
rather than the built in SIM reader.
Both are non-trivial of course.
If you wait a bit you will get code for the second suggestion. We currently have a working version that forwards the apdu to a local client transforming this into SAP and speaking with a SAP server that uses pcsc to talk to a SIM card in an external SIM reader. My goal though is to transform this into a complete SAP client in sap_interface.c, I will work on that now...
Cheers Nico
Hi again. So after some digging I'm quite sure the ADPU response doesn't make it back into the upper layers. My question is , case the osmocon output contains some weird characters (see bellow), I should assume that at that point something went wrong with the serial link? Also is there some flag to compile the firmware such that the prints have no effect, as to offload the serial link? Thanks, Mihai.
L1CTL_DATA_REQ (link_id=0x00) ul=00811fe0, ul->payload=00811fe4, data_ind=00811fe4, data_ind->data=00811fe4 l3h=00811fe4 SIM Request (7): a0 a4 00 00 02 6f 20 Status 2: 9F 0F SIM Request (5): a0 c0 00 00 0f Status 1: 90 00 SIM Request (14): a0 d6 00 00 09 ff 49 fd 1a 49 8f 70 00 01 Status 2: 90��Q��L1CTL_PARAM_REQ (ta=1, tx_power=6) L1CTL_DATA_REQ (link_id=0x00) ul=00811fe0, ul->payload=00811fe4, data_ind=00811fe4, data_ind->data=00811fe4 l3h=00811fe4 L1CTL_DATA_REQ (link_id=0x00) ul=008123c4, ul->payload=008123c8, data_ind=008123c8, data_ind->data=008123c8 l3h=008123c8
--- On Sat, 5/7/11, Sylvain Munaut 246tnt@gmail.com wrote:
From: Sylvain Munaut 246tnt@gmail.com Subject: Re: Fw: Re: mobile - making a call To: "eisencah eisenach" wbg_1000@yahoo.com Cc: baseband-devel@lists.osmocom.org Date: Saturday, May 7, 2011, 11:07 AM
So any ideea where to look for the answer to the UPDATE_BINARY message?
No not really ...
But there is a good reason the SIM driver is not in master ... it sucks at several level, including blocking behavior in interrupt context IIRC, so it's totally plausible your machine speed triggers some weird things.
My advice would be to: - Cleanup the SIM driver - Bypass it in the code and try to access a real PCSC device locally rather than the built in SIM reader.
Both are non-trivial of course.
Cheers,
Sylvain
baseband-devel@lists.osmocom.org
-
eisencah eisenach -
Nico Golde -
Sylvain Munaut