Closed Bug 923359 Opened 6 years ago Closed 5 years ago

Support EAP-SIM

Categories

(Firefox OS Graveyard :: Vendcom, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:-)

RESOLVED FIXED
blocking-b2g -

People

(Reporter: skao, Unassigned)

References

Details

(Whiteboard: POVB [FT:RIL] )

Attachments

(1 file)

this is the tracking bug for EAP-SIM
Assignee: nobody → skao
to summarize, we have 2 different concept to implement this:

1. without patching wpa_supplicant, we need help of pcsc-lite and implement related interface with 3 RIL requests: SIM_OPEN_CHANNEL, SIM_ACCESS_CHANNEL, SIM_CLOSE_CHANNEL
2. by patching wpa_supplicant, replace get imsi & authentication functions in pcsc.c, and call related apis in RIL or elsewhere.

Both concept need Qualcomm or vendor support (for 3 RIL requests or authentication apis)
Depends on: 921320
Depends on: 890694
Blocks: 920933
This is a feature in 1.3.
blocking-b2g: --- → 1.3+
status update: since we'll need vendor's support to implement this, so now we proposed another approach to make things simpler:
* we simply tell wpa_supplicant to do EAP-SIM authentication (which was already done in bug 890694)
* chip set vendor support have their implementation in wpa_supplicant
* some patches for gecko may be needed
** set imsi as identity
*** this depends on whether imsi reading implemented in wpa_supplicant, if not we'll have to set it in setNetworkConfiguration (WifiWorker.js), ex. config.identity = quote("1466923202406081@wlan.mnc092.mcc466.3gppnetwork.org");
** deal with multi-sim
** send correct configuration to wpa_supplicant
*** depends on the implementation too, if implemented in the similar way we previously proposed (through pcsc) then we only have to set this config in setNetworkConfiguration (WifiWorker.js): config.pcsc = quote("");
Target Milestone: --- → 1.3 Sprint 5 - 11/22
Whiteboard: [FT:RIL]
Blocks: 938986
No longer blocks: 938986
Depends on: 938986
Depends on: 939000
Blocks: 939000
No longer depends on: 939000
Target Milestone: 1.3 Sprint 5 - 11/22 → 1.3 Sprint 6 - 12/6
No longer depends on: 921320
Update about latest design,

Gecko send the following parameters to wpa_supplicant:
network={
ssid="eapsim"
key_mgmt=WPA-EAP
eap=SIM
} 

Vendors have to handle eapsim identity/authentication in wpa_supplicant.
this is a patch for external/wpa_supplicant_8/src/utils/sim_funcs.c to testing with hard coded kc.
This bug is for tracking Vender status. it should not block user story.
Assignee: skao → nobody
No longer blocks: 920933, 920936, 920939
Component: Wifi → Vendcom
Hi Ken, Steven, 
Should we mark POVB on this bug, and assign to vendor?
Also I would like to know if there's ETA for it.
Flags: needinfo?(styang)
Flags: needinfo?(kchang)
Target Milestone: 1.3 Sprint 6 - 12/6 → ---
(In reply to Wesley Huang [:wesley_huang] from comment #7)
> Hi Ken, Steven, 
> Should we mark POVB on this bug, and assign to vendor?
Yes, it is a better method.
Flags: needinfo?(kchang)
@  Wesley Huang and @ Ken Chang: If i understand good, Firefox OS don't have software's support of EAP-SIM, it's only by device ?? Some phone could have support EAP-SIM and some not ??
(In reply to vulcain from comment #9)
> @  Wesley Huang and @ Ken Chang: If i understand good, Firefox OS don't have
> software's support of EAP-SIM, it's only by device ?? Some phone could have
> support EAP-SIM and some not ??

In 1.3, FireFox OS should support EAP-SIM.
However, from my understanding, this will also depend on device as EAP-SIM requires interop between modem and WiFi module.
Whiteboard: [FT:RIL] → POVB [FT:RIL]
Sam, could you resume the works on EAM-SIM?
Flags: needinfo?(styang) → needinfo?(sam.hua)
okay.
which route will moz continue now? RIL or WIFI?
Flags: needinfo?(sam.hua)
(In reply to sam.hua from comment #12)
> okay.
> which route will moz continue now? RIL or WIFI?

Dimi, 
Do you have answer for Sam's question?
Flags: needinfo?(dlee)
(In reply to sam.hua from comment #12)
> okay.
> which route will moz continue now? RIL or WIFI?

RIL means Radio Interface Layer ??
https://en.wikipedia.org/wiki/Radio_Interface_Layer
yes,
Use the following requests to send auth request to modem
this.REQUEST_SIM_OPEN_CHANNEL = 121;
this.REQUEST_SIM_CLOSE_CHANNEL = 122;
this.REQUEST_SIM_ACCESS_CHANNEL = 123;
For information, it's RFC 4187: https://tools.ietf.org/html/rfc4186
(In reply to sam.hua from comment #12)
> okay.
> which route will moz continue now? RIL or WIFI?
Sam, James had told me that you modified the wpa_supplicate for getting authentication information from SIM via RILC. And that is what you did in Android phone. I think Shao-hang had worked on this with you for a long time before. You can contact with dimi to know more detail.
(In reply to vulcain from comment #14)
> (In reply to sam.hua from comment #12)
> > okay.
> > which route will moz continue now? RIL or WIFI?
> 
> RIL means Radio Interface Layer ??
> https://en.wikipedia.org/wiki/Radio_Interface_Layer

Yes, it is.
(In reply to vulcain from comment #16)
> For information, it's RFC 4187: https://tools.ietf.org/html/rfc4186

Thanks for this information. However, this is only to define EAP-SIM authentication flow. Currently, we need a method to get KC and SRES from SIM via RIL daemon. And the problem is there is not vendor provide method for getting these via RIL daemon. Even 3GPP had defined AT command for getting KC and SRES.
(In reply to Ken Chang[:ken] from comment #19)

> Thanks for this information. However, this is only to define EAP-SIM
> authentication flow. Currently, we need a method to get KC and SRES from SIM
> via RIL daemon. And the problem is there is not vendor provide method for
> getting these via RIL daemon. Even 3GPP had defined AT command for getting
> KC and SRES.

ok
hi Steven, is our partner still working on this ? Thanks
Flags: needinfo?(styang)
Sam, could you let us know the current status? Thanks
Flags: needinfo?(styang) → needinfo?(sam.hua)
There are two ways:

1 we can get the KC and SRES from SIM by sending AT directly to modem in WIFI without RILC support.

2 if we want to get them via RIL,we have finished the code in RILC but need the be verified.
Flags: needinfo?(sam.hua)
We're past 1.3 feature complete here - are we still planning to do this? Renominating for more discussion.
blocking-b2g: 1.3+ → 1.3?
(In reply to Jason Smith [:jsmith] from comment #24)
> We're past 1.3 feature complete here - are we still planning to do this?
> Renominating for more discussion.
For gecko part, EAP_SIM is supported and verified with a test fix in partner's code. 
This bug is for tracking partner's status. I don't think it is 1.3+.
blocking-b2g: 1.3? → -
(In reply to Wesley Huang [:wesley_huang] from comment #13)
> (In reply to sam.hua from comment #12)
> > okay.
> > which route will moz continue now? RIL or WIFI?
Sam, in current design and what we discussed before, you should make your WPA_Supplicant to get KC and SRES from your RILC directly. Thanks.
Flags: needinfo?(dlee)
yes,our new modem bin will support it.
What's the state of the implementation of EAP-SIM ?

I'm asking 'cos I'd like to test it with the french carrier Free Mobile which supports EAP-SIM.

Testing yesterday with the Peak and the last release of 1.4, the connection seemed to be established with the SSID but was then lost.

Is there something to do like activate a hidden parameter or something to make use of EAP-SIM with the Keon or the Peak ?
(In reply to kael from comment #28)
> What's the state of the implementation of EAP-SIM ?
> 
> I'm asking 'cos I'd like to test it with the french carrier Free Mobile
> which supports EAP-SIM.
> 
> Testing yesterday with the Peak and the last release of 1.4, the connection
> seemed to be established with the SSID but was then lost.
> 
> Is there something to do like activate a hidden parameter or something to
> make use of EAP-SIM with the Keon or the Peak ?
Besides to support EAP-SIM in Firefox OS, it still needs vendor's support in WPA supplicant. Currently, Keon and Peak doesn't support EAP-SIM.
according to comment 27, close this ticket.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.