966925 - Trying to connect to the Mozilla network in Paris with a SIM with no service gets stuck connecting forever (WPA-EAP)

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Wifi, defect)

Description

[Jason Smith [:jsmith]]

Build:

* Gecko: 83a3ef9b2144
* Gaia: 3b2fe2f86164f95db699b6ea2661925b21ecb994
* Build ID: 20140202160200
* Version: 1.4

STR

1. In wifi settings, try to connect to the Mozilla network (WPA-EAP) with a SIM with no service

Expected

We should eventually time out trying to the connect to the network.

Actual

We get stuck connecting forever with no end in sight. Restarting the phone won't help either.

Comment 1

[Jason Smith [:jsmith]]

Oh and - the nom here is mainly to ensure that this UX is disabled on 1.4, as bug 790056 shows evidence that the feature itself is non-blocking for 1.4. However, we should not expose busted UX to a user.

Comment 2

[Vincent Chang[:vchang][changyihsin]]

 If we remove EAP support, it means that EAP-SIM will be removed, too.

Comment 3

[Jason Smith [:jsmith]]

(In reply to Vincent Chang[:vchang] from comment #2)
>  If we remove EAP support, it means that EAP-SIM will be removed, too.

Going to pull nom for a second to discuss a couple of things.

Should I open a separate bug to disable the UX here? We're still exposing the EAP UX from what I can tell right now.

Comment 4

[Vincent Chang[:vchang][changyihsin]]

One problem here is that there is no way for UX to distinguish between EAP-SIM AP and EAP-PEAP, EAP-TLS AP.... which make it difficult to just support EAP-SIM.

Comment 5

[Jason Smith [:jsmith]]

(In reply to Vincent Chang[:vchang] from comment #4)
> One problem here is that there is no way for UX to distinguish between
> EAP-SIM AP and EAP-PEAP, EAP-TLS AP.... which make it difficult to just
> support EAP-SIM.

This is highly problematic. That means a user can end up connecting to a network that might never work, which is busted UX.

Can UX weigh in here on what we should do here? Apparently exposing EAP wifi networks right now in the wifi network selection screen includes networks we don't support right now, so you could hit this bug that I've cited.

Comment 6

[Jason Smith [:jsmith]]

Leaving qawanted here to find out what happens on 1.1 & 1.3 right now.

Comment 7

[Stephany Wilkes]

Flagging Omega, though I expect others may need to weigh in here, as it sounds like this may hint at a case where UX can't be a solo fix (i.e. if the UI can't discern and thus show what the issue is, and will need something system-side in order to do that).

Comment 8

[Omega Feng [:Omega] [:馮於懋]]

Here is the UX suggestion: When trying to connect to an AP, try automatically only 3 times. If the device still cannot connect to the AP, forget the AP and won't try it anymore. (Of course user can tap it again to try another 3 times.)
It should solve the original problem in this bug for now.

Comment 9

[Vincent Chang[:vchang][changyihsin]]

I just check with unagi phone but it doesn't seem to have reasonalbe messages from wpa_supplicant which  make it difficult to implement the mechanism that retry to connect to AP 3 times and forget the SSID if failed in this case. I got three messages from wpa_supplicant repeatly here. 

-*- WifiWorker component: Event coming in: Associated with 3c:94:d5:7b:87:42
-*- WifiWorker component: Event coming in: CTRL-EVENT-EAP-STARTED EAP authentication started
-*- WifiWorker component: Event coming in: CTRL-REQ-IDENTITY-3:Identity needed for SSID Mozilla

Maybe we can detect that we are in the loop of this three message and forget the SSID automatically. But it doesn't seem to make sense....

Comment 10

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #6)
> Leaving qawanted here to find out what happens on 1.1 & 1.3 right now.

Note - I confirmed this problem on 1.3 in the Mozilla office on Buri.

Comment 11

[Jason Smith [:jsmith]]

So checking the roadmap, EAP-SIM was introduced in 1.3, so this only applies in 1.3+.

Noming this because I think this is busted UX, as we're exposing wifi networks that are impossible to connect to.

Comment 12

[Ken Chang[:kenkai]]

(In reply to Jason Smith [:jsmith] from comment #11)
> So checking the roadmap, EAP-SIM was introduced in 1.3, so this only applies
> in 1.3+.
> 
> Noming this because I think this is busted UX, as we're exposing wifi
> networks that are impossible to connect to.
If this is a 1.3+ issue, that means we need to add Bug 922930 into 1.3 also.

Comment 13

[Jason Smith [:jsmith]]

(In reply to Ken Chang[:ken] from comment #12)
> (In reply to Jason Smith [:jsmith] from comment #11)
> > So checking the roadmap, EAP-SIM was introduced in 1.3, so this only applies
> > in 1.3+.
> > 
> > Noming this because I think this is busted UX, as we're exposing wifi
> > networks that are impossible to connect to.
> If this is a 1.3+ issue, that means we need to add Bug 922930 into 1.3 also.

I'm actually not arguing to add a feature here, as that's not an option at this point in the release. I'm arguing that we can't expose wifi networks that cannot be connected to, as that a broken UX to a user. If that means we need to disable EAP-SIM to do this, then that might need to be on the table. Hopefully there's a different hack on the table here to consider where we keep EAP-SIM and disable the other networks involved here that won't ever be possible to connect to.

Comment 14

[Jason Smith [:jsmith]]

I'm going to start an offline email discussion with product on what to do here with Ken cc-ed.

Comment 15

[Stephany Wilkes]

For UX's part in general, aside from Omega's specific time-out recommendation above (which still stands), we'd prefer:

* That the device not attempt to connect to anything that is not supported: if a network is of n type, and the device or OS does not support that type, then there is no point (for the user) in attempting the network connection. In short, I agree with Jason that we not expose wifi networks that cannot be connected to. In some cases, a user may know of a particular network to which s/he wants to connect, and perhaps be confused about why it does not appear, but that temporary confusion is likely no worse than repeatedly attempting to a network that cannot actually be used but appears as if it can be. 

Jason: In your comment #13 is "disable the other networks" technically the same thing as to not exposing the wifi networks that cannot be connected to? They sound like they may be different but I'm not sure.

If this is not possible...

* Then there is the fact, as Vincent pointed out earlier, that the information driving the UX is perhaps not helpful, as the UX cannot distinguish between EAP-SIM AP and EAP-PEAP, EAP-TLS AP, etc. If Gaia does not receive a specific enough "message," we have no way to adapt the user-facing UX in either direction: what piece tells/would tell Gaia that "this network is of a type to which this device cannot connect" upon which we could provide more specific UX? If this sort of message gets "sent" then I don't see why we couldn't create UX based on it but if that's not there, I'm not sure what else would direct/enable the UX.

Comment 16

[Ken Chang[:kenkai]]

Per discussing with Gaia, we will add a property for vendor. Vendor can use this property to show or not to show EAP APs list.
The other thing is that we would like to remove EAP-SIM option form adding hidden network menu. Normally, carrier won't configure an EAP-SIM AP as a hidden network.

Comment 17

[Ken Chang[:kenkai]]

(In reply to Ken Chang[:ken] from comment #16)
> The other thing is that we would like to remove EAP-SIM option form adding
> hidden network menu. Normally, carrier won't configure an EAP-SIM AP as a
> hidden network.
Stephany, this will change UI spec, does it work for you?

Comment 19

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Attachment: Filter scan result based on platform property.

Per offline discussion, add a property for partner to indicate if the device supports EAP-SIM, so they don't have to modify Gaia code.

Also, we only support EAP-SIM in WPA-EAP mode, so we can bond the EAP filter with EAP-SIM capability.
After WPA-EAP mode(bug 917102, bug 917175, bug 917176, and some other minor patches) is checked in, the filter will be removed.

Furthermore, Gaia prefers an API in Wifi Manager to provide capabilities of device so it can adjust UI in a general way.
We will discussion how how to provide such info through this API later.

Comment 20

[Stephany Wilkes]

Carrie is the UX person who should be flagged on this spec change, though it is not clear to me what precisely it should be given the API constraints noted in comment #19. Can someone please specify precisely what the proposed spec change is so Carrie can evaluate? Thanks.

Comment 21

[Carrie Wang [New account: [e-mail]]]

Omega is in charge of this. Pass it to him. Thanks.

Comment 22

[Omega Feng [:Omega] [:馮於懋]]

(In reply to Ken Chang[:ken] from comment #17)
> (In reply to Ken Chang[:ken] from comment #16)
> > The other thing is that we would like to remove EAP-SIM option form adding
> > hidden network menu. Normally, carrier won't configure an EAP-SIM AP as a
> > hidden network.
> Stephany, this will change UI spec, does it work for you?

Ken, I cannot see "EAP-SIM" option in Settings. Do you mean removing "WPA-EAP" from Security options when joining hidden network?

Comment 23

[Ken Chang[:kenkai]]

(In reply to Omega Feng [:Omega] from comment #22)
> (In reply to Ken Chang[:ken] from comment #17)
> > (In reply to Ken Chang[:ken] from comment #16)
> > > The other thing is that we would like to remove EAP-SIM option form adding
> > > hidden network menu. Normally, carrier won't configure an EAP-SIM AP as a
> > > hidden network.
> > Stephany, this will change UI spec, does it work for you?
> 
> Ken, I cannot see "EAP-SIM" option in Settings. Do you mean removing
> "WPA-EAP" from Security options when joining hidden network?
Yes, you are right.

Comment 24

[Omega Feng [:Omega] [:馮於懋]]

Please see bug 988150 for the latest UX spec.

Comment 25

[Vincent Chang[:vchang][changyihsin]]

Comment on attachment 8393984 [details] [diff] [review]
Filter scan result based on platform property.

Review of attachment 8393984 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good. Thank you.

Comment 26

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Try : https://tbpl.mozilla.org/?tree=Try&rev=ec56c1912b00

Comment 27

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

All green except KK emulator build error, but not caused by this bug based on the error log.

Comment 28

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/integration/b2g-inbound/rev/8de70e6d49fd

Comment 29

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/8de70e6d49fd

Comment 30

[Ryan VanderMeulen [:RyanVM]]

Please request approval-mozilla-b2g28 on this patch if it's ready for uplift to v1.3.

Comment 31

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Attachment: Filter scan result based on platform property (v1.3)

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 922930
User impact if declined: User can use WPA functions doesn't supported by the device.
Testing completed: m-c
Risk to taking this patch (and alternatives if risky): No
String or UUID changes made by this patch: No change

Comment 32

[bhavana bajaj [:bajaj]]

Chuck lee approval in comment #31 seems to be 1.3 specific.

Whats the plan to resolve this on 1.4 here ? Uplift the patch on central to aurora ? IF so, please request mozilla-aurora approval on the needed patch.

Comment 33

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

I thought request approval for 1.3 implies approval for 1.4, I will request that.

Comment 34

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Comment on attachment 8399868 [details] [diff] [review]
Filter scan result based on platform property (v1.3)

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 922930
User impact if declined: User can use WPA functions which doesn't supported by the device.
Testing completed (on m-c, etc.): m-c
Risk to taking this patch (and alternatives if risky): No
String or IDL/UUID changes made by this patch: No change

Comment 35

[bhavana bajaj [:bajaj]]

(In reply to Chuck Lee [:chucklee] from comment #33)
> I thought request approval for 1.3 implies approval for 1.4, I will request
> that.

Yea, i was not sure if the 1.3 attachment applies only on that branch or could work on gecko 30. nevertheless thanks for the request. this helps!

Comment 36

[bhavana bajaj [:bajaj]]

:jsmith, since  you were able to reproduce this can you confirm this is foxed on 1.3 once it lands ?

Comment 37

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Comment on attachment 8399868 [details] [diff] [review]
Filter scan result based on platform property (v1.3)

Sorry, aurora should use patch for central.

Comment 38

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Comment on attachment 8393984 [details] [diff] [review]
Filter scan result based on platform property.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 922930
User impact if declined: User can use WPA functions which doesn't supported by the device.
Testing completed (on m-c, etc.): m-c
Risk to taking this patch (and alternatives if risky): No
String or IDL/UUID changes made by this patch: No change

Comment 39

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/965dcb2e8059
https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/5e3d82f695ba

Comment 40

[Jason Smith [:jsmith]]

lgtm on trunk - I'm not seeing Mozilla-G & Mozilla on the wifi network list