Ravi Dandu Reporter
	Description • 11 years ago

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.

	howie [:howie]
	Comment 1 • 11 years ago

Requirement document: http://goo.gl/AVHUwF

	Ken Chang[:kenkai]
	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?

	Wilfred Mathanaraj [:WDM]
	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?

	Ken Chang[:kenkai]
	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.

	Wilfred Mathanaraj [:WDM]
	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.

	Ken Chang[:kenkai]
	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.

	Ravi Dandu 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

	Ken Chang[:kenkai]
	Comment 8 • 11 years ago

Done, it is the bug 1000006.

	Ken Chang[:kenkai]
	Comment 9 • 11 years ago

Henry would like to take this bug. Thanks.

	Henry Chang [:hchang] Assignee
	Comment 10 • 11 years ago

This bug should be a meta bug. I'll create other bugs for tracking implementation detail.

	Eric Chang [:ericcc] [:echang]
	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.

	howie [:howie]
	Comment 12 • 10 years ago

mark as resolved fixed, all dependent bug are fixed.