Hello everybody, I have to admit that I don't know very much about EAP-SIM, but maintaining a patch on top of wpa_supplicant seems like a really bad idea. Even going through Qualcomm is a risky proposition because actual OEMs have a tendency of shipping their own versions of various libraries/programs anyway and we won't necessarily have the source readily available (also, I'm not sure if we can get OEMs to build with our custom patches, though mwu might know more about that).
Is there any way to hook into the existing smart card infrastructure, even though it's more complicated than what we need to avoid this? Also, we really don't want to add another wifi worker (and we have work undergoing to remove at least one of the two existing workers happening in <https://bugzilla.mozilla.org/show_bug.cgi?id=864932>) so we're almost certainly going to have to figure out how to use an existing worker to do this. On Wed, Aug 7, 2013 at 12:30 PM, Jonas Sicking <[email protected]> wrote: > Hi Dimi, > > I feel like I don't really know the code well enough here and want to > avoid giving bad advice, so I talked with Blake about having him look > this over. > > / Jonas > > On Fri, Aug 2, 2013 at 12:33 AM, Dimi Lee <[email protected]> wrote: >> Hi Jonas, >> I will explain pcsc_funcs first and then propose possible solution in >> current architecture if we want to use >> existing wifi worker. >> >> pcsc stands for Personal Computer/Smartcard Interface. >> The main usage of this component(pcsc_funcs.c) is it provide an interface >> for wpa_supplicant to access USIM/GSM SIM. >> And following is the APIs it provides: >> >> - struct scard_data * scard_init(scard_sim_type sim_type) >> - void scard_deinit(struct scard_data *scard); >> - int scard_set_pin(struct scard_data *scard, const char *pin); >> - int scard_get_imsi(struct scard_data *scard, char *imsi, size_t *len); >> - int scard_gsm_auth(struct scard_data *scard, const unsigned char *_rand, >> unsigned char *sres, unsigned char *kc); >> - int scard_umts_auth(struct scard_data *scard, const unsigned char >> *_rand, const unsigned char *autn, unsigned char *res, size_t *res_len, >> unsigned char *ik, unsigned char *ck, unsigned char *auts); >> >> and pcsc component will be used when wpa_supplicant is doing EAP-SIM / >> EAP-AKA authentication. >> As you can see scard_gsm_auth & scard_umts_auth are the authentication >> APIs. >> >> The original implementation of pcsc_funcs.c access SIM through "card >> reader", it will need to link another package >> called pcsc-lite and acsess SIM through card reader. >> >> But in our B2G we don't support card reader and we don't need such a >> complicate way to get SIM information because >> we can access SIM simply through RIL module. So the architecture diagram >> show we modify pcsc_funcs to communicate >> with WifiWorker directly and then access SIM through >> RadioInterfaceLayer.js. >> >> The best way to communicate with WifiWorker is reuse original notification >> IPC channel established between >> WifiWorker and wpa_supplicant so we will not need to create another worker >> thread listen on another IPC channel. >> >> But after tracing wpa_supplicant code, we found that we cannot retrieve >> the notification socket in pcsc_funcs.c. >> There is no API to get it and wpa_supplicant neither pass any information >> through above APIs for pcsc_func to >> retrieve the notification socket. >> >> So if we want to re-use existing worker, i will propose modify the >> scard_init API and add another parameter to let >> wpa_supplicant pass it's context, and then in pcsc_func we can retrieve >> notification socket through the context. >> The drawback of this solution is that we changed the API, so it means we >> need modify the code of wpa_supplicant. >> >> In this case, maybe we will need to discuss with qualcomm and apply a >> mozilla patch to qualcomm wpa_supplicant, so >> the wpa_supplicant will use the new API. Or we will need to maintain our >> own wpa_supplicant in our repository, but >> i think its a pretty bad idea to maintain our own wpa_supplicant. >> >> Please let me know your suggestion, thanks >> >> Best regards >> Dimi -- Blake Kaplan _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
