Hi Blake, Does it make sense that partners modify their own wpa_supplicant and obtain the necessary SIM information from card reader driver or directly from radio driver ? In this cause, we don't need to modify wpa_supplicant or create a new worker thread to listen and wait there. In this case, we just need to configure wpa_supplicant.conf to enable eap sim for specific SSID.
Many Thanks, Vincent Chang, Software Engineer of Mozilla Taiwan 2013/8/14 Blake Kaplan <[email protected]> > 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 > _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
