Closed
Bug 982384
(WISPr)
Opened 11 years ago
Closed 10 years ago
[Meta]WiSPr Support needed to enable roaming between wireless internet service providers
Categories
(Firefox OS Graveyard :: Wifi, defect)
Tracking
(feature-b2g:2.0, tracking-b2g:backlog)
RESOLVED
FIXED
2.0 S3 (6june)
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.
Reporter | ||
Updated•11 years ago
|
Assignee: nobody → kchang
Updated•11 years ago
|
Blocks: b2g-WLAN-2.0
Whiteboard: [ucid:WLAN21, 1.5, ft:RIL]
Updated•11 years ago
|
blocking-b2g: --- → backlog
Whiteboard: [ucid:WLAN21, 1.5, ft:RIL] → [ucid:WLAN21, 1.5, ft:RIL] [priority]
Comment 2•11 years ago
|
||
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)
Comment 3•11 years ago
|
||
(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)
Comment 4•11 years ago
|
||
(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.
Comment 5•11 years ago
|
||
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.
Comment 6•11 years ago
|
||
(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.
Reporter | ||
Comment 7•11 years ago
|
||
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)
Updated•11 years ago
|
Whiteboard: [ucid:WLAN21, 1.5, ft:RIL] [priority] → [ucid:WLAN21, 2.0, ft:RIL] [priority]
Updated•11 years ago
|
Whiteboard: [ucid:WLAN21, 2.0, ft:RIL] [priority] → [ucid:WLAN21, 2.0, ft:RIL] [priority][dependency:marketplace]
Updated•11 years ago
|
Whiteboard: [ucid:WLAN21, 2.0, ft:RIL] [priority][dependency:marketplace] → [ucid:WLAN21, 2.0, ft:RIL] [priority][dependency:Marketplace]
Updated•11 years ago
|
feature-b2g: --- → 2.0
Assignee | ||
Comment 10•11 years ago
|
||
This bug should be a meta bug. I'll create other bugs for tracking implementation detail.
Updated•10 years ago
|
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
Comment 11•10 years ago
|
||
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+
Updated•10 years ago
|
Target Milestone: --- → 2.0 S3 (6june)
Comment 12•10 years ago
|
||
mark as resolved fixed, all dependent bug are fixed.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Updated•10 years ago
|
blocking-b2g: backlog → ---
tracking-b2g:
--- → backlog
You need to log in
before you can comment on or make changes to this bug.
Description
•