Hello,
I was walking through trac while I came across this file: http://bb.osmocom.org/trac/browser/src/host/layer23/src/common/sim.c
I see here: 183 /* send APDU to card reader */ 184 static int sim_apdu_send(struct osmocom_ms *ms, uint8_t *data, uint16_t length) 185 { 186 LOGP(DSIM, LOGL_INFO, "sending APDU (class 0x%02x, ins 0x%02x)\n", 187 data[0], data[1]); 188 l1ctl_tx_sim_req(ms, data, length); 189 return 0; 190 }
ohoh, that's hardcoded.
If we would like to have a software SIM, a SIM in a card reader on the PC, or a real sim in the MS, I think this would this be the correct place to plug a modular sim implementation.
I mean something that looks like:
struct osmocom_sim_ops { int (*sim_apdu_init)(.....); int (*sim_apdu_fini)(.....); void (*sim_op_reset)(.....); void (*sim_apdu_send)(.....); void (*sim_response_callback)(.....); };
void ms_register_sim_driver(struct osmocom_ms *ms, struct osmocom_sim_ops *ops);
this could be a part of struct osmocom_ms.
I would be easy to have 3 implementations: -sim in the mobile, using the current calls 'l1ctl_tx_sim_req' 'l1ctl_tx_sim_conf' -sim in PCSC using pcsclite or winscard, and a command-line option to select the reader (by index, by name, or first reader with a card inside for simple setups) -virtual sim using pure software
What do you think about this?
Regards Sebastien
Hi,
There was some plan to use BTSAP as an internal interface to allow plugging of SIM interface .. not sure where it's at.
What's for sure is that what's in sylvain/testing is a hack, that's why all that is not in master.
Cheers,
Sylvain
Not sure to understand what you mean.
src/host/layer23/src/common/sim.c is the same in both branches.
we also have a struct gsm_sim in struct osmocom_ms.
Would that struct be the place to store the sim callbacks?
Sebastien
On Jan 31, 2011 11:02pm, Sébastien Lorquet squalyl@gmail.com wrote:
Not sure to understand what you mean.
src/host/layer23/src/common/sim.c is the same in both branches.
I meant it was an idea discussed here ... I didn't say _any_ of it had ever been implemented ... anywhere.
See mailing list archives for details.
Cheers,
Sylvain
Hi,
[just for completeness]
On 31.01.2011 18:36, Sylvain Munaut wrote:
There was some plan to use BTSAP as an internal interface to allow plugging of SIM interface .. not sure where it's at.
Yeah, prom started to work on this some months back, the unfinished target-side code is in the prom/simaccess branch.
Regards, Steve
hi,
thinking more about the SIM.
I started to look at the code and I now have some ideas on how to do that.
Just a question for the moment:
The SIM code is common to all apps so I'm looking at src/host/layer23/src/common/main.c .
I see that the handle_options() is the proper place to add a --sim option that would become available to all l23 apps to choose the SIM implementation to use (l1ctl, pcsclite, etc.)
But the handle_options() function does not take the struct osmocom_ms *ms pointer as a parameter. And I would need that to setup the proper functions for the SIM.
Is this lack of parameters on purpose? Can I do this sort of change without being (understandably) barked at? There is no API breaking involved, handle_options() is static.
The result is that for the moment, handle_options() can only access a struct l23_app_info *app. So for my own amusement, I will do the required changes until someone discourages me with a serious reason (in my own branch, in my own repository)
I'm just playing with the code now.
Sebastien
On Tue, Feb 1, 2011 at 12:36 AM, Steve Markgraf steve@steve-m.de wrote:
Hi,
[just for completeness]
On 31.01.2011 18:36, Sylvain Munaut wrote:
There was some plan to use BTSAP as an internal interface to allow plugging of SIM interface .. not sure where it's at.
Yeah, prom started to work on this some months back, the unfinished target-side code is in the prom/simaccess branch.
Regards, Steve
baseband-devel@lists.osmocom.org
-
246tnt＠gmail.com -
Steve Markgraf -
Sylvain Munaut
-
Sébastien Lorquet