7 May
2011
7 May
'11
9:25 a.m.
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(a)yahoo.com> wrote:
From: eisencah eisenach <wbg_1000(a)yahoo.com>
Subject: Re: mobile - making a call
To: baseband-devel(a)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(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)
7 May
7 May
10:07 a.m.
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
9 May
9 May
12:12 p.m.
Hi,
* Sylvain Munaut <246tnt(a)gmail.com> [2011-05-09 11:30]:
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
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.
15 May
15 May
4:52 p.m.
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(a)gmail.com> wrote:
From: Sylvain Munaut <246tnt(a)gmail.com>
Subject: Re: Fw: Re: mobile - making a call
To: "eisencah eisenach" <wbg_1000(a)yahoo.com>
Cc: baseband-devel(a)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
5169
days inactive
5177
days old
baseband-devel@lists.osmocom.org
3 comments
3 participants
participants (3)
-
eisencah eisenach -
Nico Golde -
Sylvain Munaut