The SIM and the SIM reader in the phone and the mechanical contact between them are definitely working because the SIM can be accessed from the motorola firmware, from another phone and from a PC smartcard reader with no PIN or anything. However, under simtest firmware no data is received by the phone, even the ATR is zero bytes... Anybody had this problem? Also, is l1CTL SIM APDU command not implemented in the layer1 firmware? How are people making calls without a SIM? :P Gianni ----------------SIMTEST----8<----------------- Initializing driver: SIM: Registering interrupt handler for simcard-interface ====================== CALYPSO SIM REGISTER DUMP ===================== Reg_sim_cmd register (R/W) - FFFE:0000 |-REG_SIM_CMD = 0000 | |-REG_SIM_CMD_CMDCARDRST = 0 ==> SIM card reset sequence disabled. | |-REG_SIM_CMD_CMDIFRST = 0 | |-REG_SIM_CMD_CMDSTOP = 0 | |-REG_SIM_CMD_CMDSTART = 0 | |-REG_SIM_CMD_MODULE_CLK_EN = 0 ==> Clock of the module disabled. |-REG_SIM_STAT = 000b | |-REG_SIM_STAT_STATNOCARD = 1 ==> No card! | |-REG_SIM_STAT_STATTXPAR = 1 ==> Parity ok! | |-REG_SIM_STAT_STATFIFOFULL = 0 | |-REG_SIM_STAT_STATFIFOEMPTY = 1 ==> Fifo empty! |-REG_SIM_CONF1 = 000c | |-REG_SIM_CONF1_CONFCHKPAR = 0 ==> Parity check on reception disabled. | |-REG_SIM_CONF1_CONFCODCONV = 0 ==> Coding convention is direct (normal). | |-REG_SIM_CONF1_CONFTXRX = 1 ==> SIO line direction is in transmit mode. | |-REG_SIM_CONF1_CONFSCLKEN = 1 ==> SIM clock in normal mode. | |-REG_SIM_CONF1_reserved = 0 ==> ETU period is CONFETUPERIOD. | |-REG_SIM_CONF1_CONFSCLKDIV = 0 ==> SIM clock frequency is 13/4 Mhz. | |-REG_SIM_CONF1_CONFSCLKLEV = 0 ==> SIM clock idle level is low. | |-REG_SIM_CONF1_CONFETUPERIOD = 0 ==> ETU period is 372/8*1/Fsclk. | |-REG_SIM_CONF1_CONFBYPASS = 0 ==> Hardware timers and start and stop sequences are normal. | |-REG_SIM_CONF1_CONFSVCCLEV = 0 ==> SVCC Level is low (Only valid when CONFBYPASS = 1). | |-REG_SIM_CONF1_CONFSRSTLEV = 0 ==> SRST Level is low (Only valid when CONFBYPASS = 1). | |-REG_SIM_CONF1_CONFTRIG = 0x0 (FIFO trigger level) | |-REG_SIM_CONF1_CONFSIOLOW = 0 |-REG_SIM_CONF2 = 0940 | |-REG_SIM_CONF2_CONFTFSIM = 0x0 (time delay for filtering of SIM_CD) | |-REG_SIM_CONF2_CONFTDSIM = 0x4 (time delay for contact activation/deactivation) | |-REG_SIM_CONF2_CONFWAITI = 0x9 (CONFWAITI overflow wait time between two received chars) |-REG_SIM_IT = 0000 | |-REG_SIM_IT_SIM_NATR = 0 ==> On read access to REG_SIM_IT. | |-REG_SIM_IT_SIM_WT = 0 ==> On read access to REG_SIM_IT. | |-REG_SIM_IT_SIM_OV = 0 ==> On read access to REG_SIM_IT. | |-REG_SIM_IT_SIM_TX = 0 ==> On write access to REG_SIM_DTX or on switching | | from transmit to receive mode (CONFTXRX bit) | |-REG_SIM_IT_SIM_RX = 0 ==> On read access to REG_SIM_DRX. |-REG_SIM_DRX = 0100 | |-REG_SIM_DRX_SIM_DRX = 0x0 (next data byte in FIFO available for reading) | |-REG_SIM_DRX_STATRXPAR = 1 ==> Parity Ok. |-REG_SIM_DTX = 00 (next data byte to be transmitted) |-REG_SIM_MASKIT = 003f | |-REG_SIM_MASKIT_MASK_SIM_NATR = 1 ==> No-answer-to-reset interrupt is masked. | |-REG_SIM_MASKIT_MASK_SIM_WT = 1 ==> Character wait-time overflow interrupt is masked. | |-REG_SIM_MASKIT_MASK_SIM_OV = 1 ==> Receive overflow interrupt is masked. | |-REG_SIM_MASKIT_MASK_SIM_TX = 1 ==> Waiting characters to be transmit interrupt is masked. | |-REG_SIM_MASKIT_MASK_SIM_RX = 1 ==> Waiting characters to be read interrupt is masked. | |-REG_SIM_MASKIT_MASK_SIM_CD = 1 ==> SIM card insertion/extraction interrupt is masked. |-REG_SIM_IT_CD = fffe0010 |-REG_SIM_IT_CD_IT_CD = 0 ==> SIM card insertion/extraction interrupt is unmasked. Power up simcard: * Power enabled! * Clock enabled! * Reset released! SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Character underflow! (0 bytes) Reset simcard: * Reset pulled down! * Reset released! SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Character underflow! (0 bytes) SIM-T0: Transceiving APDU-Header: (a0 a4 00 00 02) SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-T0: Case 2: No input / Output of known length (See also GSM 11.11 Page 34) SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Character underflow! SIM-T0: T0 Protocol error: Missing ACK byte -- aborting! SIM-T0: Transceiving APDU-Header: (a0 c0 00 00 0f) SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-T0: Case 4: Input / No output (See also GSM 11.11 Page 34) SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Character underflow! SIM-T0: T0 Protocol error: Incorrect or missing answer -- aborting! e0 73 d7 b9 ae ea bf 7e f7 3b 7f 6f 32 fe 25 (15 bytes) Test Phase 1: Testing bare sim commands... * Testing SELECT: Selecting MF SIM-T0: Transceiving APDU-Header: (a0 a4 00 00 02) SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-T0: Case 2: No input / Output of known length (See also GSM 11.11 Page 34) SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Character underflow! SIM-T0: T0 Protocol error: Missing ACK byte -- aborting! ==> Status word: ffff * Testing SELECT: Selecting DF_GSM SIM-T0: Transceiving APDU-Header: (a0 a4 00 00 02) SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... At this point it hangs "forever" - well at least half hour.
On Wed, 2011-05-11 at 01:12 +0100, Gianni Tedesco wrote:
The SIM and the SIM reader in the phone and the mechanical contact between them are definitely working because the SIM can be accessed from the motorola firmware, from another phone and from a PC smartcard reader with no PIN or anything.
However, under simtest firmware no data is received by the phone, even the ATR is zero bytes...
Anybody had this problem?
Also, is l1CTL SIM APDU command not implemented in the layer1 firmware? How are people making calls without a SIM? :P
On Mon May 9 12:12:49 CEST 2011, Nico Golde wrote
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...
Actually, how far have you got with this? Turns out I had the same idea as you except I was going to use a unix socket with no protocol (ie. no SAP) to just communicate with my ccid-utils driver to talk to the SIM. Gianni
On Wed, 2011-05-11 at 01:39 +0100, Gianni Tedesco wrote:
On Wed, 2011-05-11 at 01:12 +0100, Gianni Tedesco wrote:
The SIM and the SIM reader in the phone and the mechanical contact between them are definitely working because the SIM can be accessed from the motorola firmware, from another phone and from a PC smartcard reader with no PIN or anything.
However, under simtest firmware no data is received by the phone, even the ATR is zero bytes...
Anybody had this problem?
Also, is l1CTL SIM APDU command not implemented in the layer1 firmware? How are people making calls without a SIM? :P
On Mon May 9 12:12:49 CEST 2011, Nico Golde wrote
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...
Actually, how far have you got with this? Turns out I had the same idea as you except I was going to use a unix socket with no protocol (ie. no SAP) to just communicate with my ccid-utils driver to talk to the SIM.
I did just that using SEQPACKET unix sockets. Patch attached, sample simctl is at https://github.com/giannitedesco/ccid-utils/tree/simctl I was able to register a network and place a voice call with this. Gianni
Hi, * Gianni Tedesco <gianni@scaramanga.co.uk> [2011-05-11 13:49]:
On Wed, 2011-05-11 at 01:12 +0100, Gianni Tedesco wrote: [...] On Mon May 9 12:12:49 CEST 2011, Nico Golde wrote
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...
Actually, how far have you got with this? Turns out I had the same idea as you except I was going to use a unix socket with no protocol (ie. no SAP) to just communicate with my ccid-utils driver to talk to the SIM.
That's what I did before but as sap_interface.c already existed and there is a sap server with pcsc in the softsim repository I wanted a real SAP client to use it directly. I've got a working prototype which needs some cleaning. I'll send a patch for this to the list in the next days. Cheers Nico
On Wed, 2011-05-11 at 14:12 +0200, osmocom@ngolde.de wrote:
Hi, * Gianni Tedesco <gianni@scaramanga.co.uk> [2011-05-11 13:49]:
On Wed, 2011-05-11 at 01:12 +0100, Gianni Tedesco wrote: [...] On Mon May 9 12:12:49 CEST 2011, Nico Golde wrote
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...
Actually, how far have you got with this? Turns out I had the same idea as you except I was going to use a unix socket with no protocol (ie. no SAP) to just communicate with my ccid-utils driver to talk to the SIM.
That's what I did before but as sap_interface.c already existed and there is a sap server with pcsc in the softsim repository I wanted a real SAP client to use it directly. I've got a working prototype which needs some cleaning. I'll send a patch for this to the list in the next days.
If you can get the command-line configuration of this working then I could always resubmit my patch on top of it as a "naked-protocol" option for the SAP module or something like that? Gianni
I have now committed the attached patch to remotes/origin/nion/sap. I've used this so far in combination with the sap server in the softsim repository in order to not use the sim driver. The patch removes the pre-defined sap socket path and additionally to the already existing config option introduces a new vty command to set the socket before issuing sap reader ms... Andreas told me that the initial plan was to implement the sap server in osmocom as well and also speak to the sim into the phone over sap. I haven't implemented this, however I'm also not sure how much sense this makes given the additional complexity for practically no gain (or I miss something). Comments welcome... Cheers Nico
Hi, * Nico Golde <osmocom@ngolde.de> [2011-05-23 11:18]:
I have now committed the attached patch to remotes/origin/nion/sap.
Forgot to add the patch. Adding again for reference in case the remote branch gets wiped at some point. Cheers Nico
Hi all, On Tue, May 24, 2011 at 12:47:25AM +0200, Nico Golde wrote:
* Nico Golde <osmocom@ngolde.de> [2011-05-23 11:18]:
I have now committed the attached patch to remotes/origin/nion/sap.
Forgot to add the patch. Adding again for reference in case the remote branch gets wiped at some point.
about half a year later, we still have never decided if we want to merge that patch or not. There has been some off-list arguments/doubts about whether we want to route our SIM card accesses to something along the lines of a BT-SAP-style interface. The advantage is that we have a clear and somewhat standardized interface to external applications that provide [remote] SIM card access or SIM card emulation. I personally am in favor of the patch, but given that I wasn't involved in any other SIM related work of OsmocomBB, I feel it is up to other developers to make any decision. In case we agree it gets merged, I would like to suggest adding some comments to the code, in the sense of "why are we doing this", and "what standard is this oriented at", two topics which are not clear to somebody who doesn't know the history of the patch before it was merged. Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi,
about half a year later, we still have never decided if we want to merge that patch or not.
But what does that patch do exacty ? I think it'd be great if: - mobile could use any other card reader - any other app could use the onboard sim reader Does the patch achieves any of these ? Is there a pcsc -> bt-sap server bt-sap client -> pcsc code available somewhere ? Cheers, Sylvain
There is already code doing that, using the BT-SAP interface: http://bb.osmocom.org/trac/wiki/softSIM it's written in ruby, but it was just for demos purposes and works. - you can provide a SIM from the PCSC interface - you can read a SIM using the BT-SAP interface - you can simulate a SIM (softSIM) - ... thanks, kevin Excerpte from Sylvain Munaut's message of Wed Nov 02 10:17:37 +0100 2011:
Hi,
about half a year later, we still have never decided if we want to merge that patch or not.
But what does that patch do exacty ?
I think it'd be great if: - mobile could use any other card reader - any other app could use the onboard sim reader
Does the patch achieves any of these ?
Is there a pcsc -> bt-sap server bt-sap client -> pcsc code available somewhere ?
Cheers,
Sylvain
hi nico, nice work. i like the idea that BTSAP is used by layer23. this was my intention when i added the sap_interface.c. not only that layer23 can use softsim as reader, but also other btsap clients could use osmocombb as reader. to make this possible, the next step would be adding the btsap server socket to osmocon. (currently it only provides a socket for L1CTL.) also layer1 sim reader would require to get a btsap compatible interface. there is only one thing i disagree: you implemented function in the VTY to set the socket. this is already done in the configurations of each mobile instance. i would suggest that you open the socket (osmosap_init(ms)) at app_mobile.c when the instance is started (no shutdown), in case the socket is given. then, if the mobile instance starts working, the socket will be connected and the sim client will read the sim as soon as the socket is connected. best regards, andreas
Hi, I'm also in favor for BTSAP. I personally find the protocol fairly sane and like Kevin mentioned there is also already the SAP server implementation in the osmocom repositories. * jolly <andreas@eversberg.eu> [2011-11-07 17:31]:
nice work. i like the idea that BTSAP is used by layer23. this was my intention when i added the sap_interface.c. not only that layer23 can use softsim as reader, but also other btsap clients could use osmocombb as reader.
I didn't even think of this option so far, but it's a good idea and shouldn't be too difficult to add to the current code!
to make this possible, the next step would be adding the btsap server socket to osmocon. (currently it only provides a socket for L1CTL.) also layer1 sim reader would require to get a btsap compatible interface.
there is only one thing i disagree: you implemented function in the VTY to set the socket. this is already done in the configurations of each mobile instance. i would suggest that you open the socket (osmosap_init(ms)) at app_mobile.c when the instance is started (no shutdown), in case the socket is given. then, if the mobile instance starts working, the socket will be connected and the sim client will read the sim as soon as the socket is connected.
I totally agree. I think the reason I did it this way was for simplicity because when the reader and the SAP interface are activated manually subsequently, the ATR command will already have it's reply. If it's not done this way the mobile application would have to wait for it to complete because the process is fairly slow. But the cleaner way would be app_mobile.c. I can work on that but will likely need some time due to various other commitments at the moment. Kind regards Nico
participants (7)
-
Gianni Tedesco -
Harald Welte -
jolly -
Kevin Redon -
Nico Golde -
osmocom＠ngolde.de
-
Sylvain Munaut