Closed Bug 982384 (WISPr) Opened 6 years ago Closed 6 years ago

[Meta]WiSPr Support needed to enable roaming between wireless internet service providers

Categories

(Firefox OS Graveyard :: Wifi, defect)

x86
macOS
defect
Not set

Tracking

(feature-b2g:2.0, tracking-b2g:backlog)

RESOLVED FIXED
2.0 S3 (6june)
feature-b2g 2.0
tracking-b2g backlog

People

(Reporter: rdandu, Assigned: hchang)

References

Details

(Whiteboard: [ucid:WLAN21, 2.0, ft:RIL] [priority][dependency:Marketplace])

WISPr (Wireless Internet Service Provider roaming) is used. This will allow users to roam between wireless internet service providers. A RADIUS server is used to authenticate the subscriber's credentials.
Assignee: nobody → kchang
Requirement document: http://goo.gl/AVHUwF
Blocks: b2g-WLAN-2.0
Whiteboard: [ucid:WLAN21, 1.5, ft:RIL]
blocking-b2g: --- → backlog
Whiteboard: [ucid:WLAN21, 1.5, ft:RIL] → [ucid:WLAN21, 1.5, ft:RIL] [priority]
Here are some limits for current WISPr design.
1. The WISPr app have to be a pre-installed certified app.
2. Because of item 2, the WISPr app can only be updated while re-flashing new release image.
3. The WISPr SSIDs list can only be preloaded in first time powering on.(via Customization file and WPA-supplicant configuration file.)
4. Because of item 3, The WISPr SSIDs list can not be dynamically loaded according to SIM card in first time powering on. For example, we can only have one SSIDs list for all SIM cards in one release. we can not based on different inserted SIMs to load different SSIDs lists into phone in FTU stage.

PMs, do you have any concern for these limits?
Flags: needinfo?(wmathanaraj)
Flags: needinfo?(rdandu)
(In reply to Ken Chang[:ken] from comment #2)
> Here are some limits for current WISPr design.
> 1. The WISPr app have to be a pre-installed certified app.

this is fine as long we understand that we can to provide support to get certification done for partners who develop this app.

> 2. Because of item 2, the WISPr app can only be updated while re-flashing
> new release image.

confused as to what is item 2?? I assume you mean item1 - then fine. this is a limitation because it has to be a certified app.

> 3. The WISPr SSIDs list can only be preloaded in first time powering on.(via
> Customization file and WPA-supplicant configuration file.)

limitation is fine - we can work with this.

> 4. Because of item 3, The WISPr SSIDs list can not be dynamically loaded
> according to SIM card in first time powering on. For example, we can only
> have one SSIDs list for all SIM cards in one release. we can not based on
> different inserted SIMs to load different SSIDs lists into phone in FTU
> stage.

why would this be? can we not maintain a list of possible SSID based on MNC/MCC to load up when we first start the device with a SIM? why is this only first time and only one list for all SIMs?

> 
> PMs, do you have any concern for these limits?
Flags: needinfo?(wmathanaraj)
(In reply to Wilfred Mathanaraj [:WDM] from comment #3)
> confused as to what is item 2?? I assume you mean item1 - then fine. this is
> a limitation because it has to be a certified app.
Sorry for the typo. Fortunately, you have a good 6 sense...:-). 

> > 4. Because of item 3, The WISPr SSIDs list can not be dynamically loaded
> > according to SIM card in first time powering on. For example, we can only
> > have one SSIDs list for all SIM cards in one release. we can not based on
> > different inserted SIMs to load different SSIDs lists into phone in FTU
> > stage.
> 
> why would this be? can we not maintain a list of possible SSID based on
> MNC/MCC to load up when we first start the device with a SIM? why is this
> only first time and only one list for all SIMs?
If we want to do this, that means we need to provide a webapi of adding WISPr ssid for FTU so that FTU can dynamically add the WIPr ssids list according to inserted SIM card(That is different form item 3). And then gecko needs to pass these ssids getting from FTU to WPA supplicant. However, wifi may not be enabled yet, we need to find a way to avoid this condition. Therefore, the efforts for this are
1. To create a webapi, which means we need to spend a little time discussing this webapi.
2. Gecko needs to add a function to send these ssids to WPA supplicant.
3. To find out a solution for storing these ssid into WPA supplicant when WIFI is not enabled.
4. We need to ask FTU to add this feature.
We are afraid that we can not finish all of these things in 2.0. So, in order to minimize efforts, we suggest listing this as a known limit.
ok point taken - too complicated for what we have time in 2.0. we can work on the webapi for future release.

I will sync up with partners and explain the limitations in our implementation.
(In reply to Wilfred Mathanaraj [:WDM] from comment #5)
> ok point taken - too complicated for what we have time in 2.0. we can work
> on the webapi for future release.
> 
> I will sync up with partners and explain the limitations in our
> implementation.
Thanks for your help.
Agreed with Wilfred's steps to explain the limitations of the 2.0 release. 
Ken, do you need another bug for the WebAPI for a future release
Flags: needinfo?(rdandu) → needinfo?(kchang)
Blocks: 1000006
Done, it is the bug 1000006.
Flags: needinfo?(kchang)
Henry would like to take this bug. Thanks.
Assignee: kchang → hchang
Whiteboard: [ucid:WLAN21, 1.5, ft:RIL] [priority] → [ucid:WLAN21, 2.0, ft:RIL] [priority]
Whiteboard: [ucid:WLAN21, 2.0, ft:RIL] [priority] → [ucid:WLAN21, 2.0, ft:RIL] [priority][dependency:marketplace]
Whiteboard: [ucid:WLAN21, 2.0, ft:RIL] [priority][dependency:marketplace] → [ucid:WLAN21, 2.0, ft:RIL] [priority][dependency:Marketplace]
feature-b2g: --- → 2.0
No longer blocks: 1000006
This bug should be a meta bug. I'll create other bugs for tracking implementation detail.
Depends on: 1010733
Alias: WISPr
Summary: WiSPr Support needed to enable roaming between wireless internet service providers → [Meta]WiSPr Support needed to enable roaming between wireless internet service providers
Search term "bug 982384", "Firefox OS v2.0" in Moztrap.
http://mzl.la/ROad2r
EAP-SIM cases and EAP security cases for testing WISPr.
Flags: in-moztrap+
Target Milestone: --- → 2.0 S3 (6june)
mark as resolved fixed, all dependent bug are fixed.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
blocking-b2g: backlog → ---
You need to log in before you can comment on or make changes to this bug.