790054 - Disable WPA Enterprise support

Status: RESOLVED FIXED

(Firefox OS Graveyard :: General, defect, P2)

Description

[Andrew Overholt [:overholt]]

Brian states in bug #789217 comment #2 that until bugs #775499 and #789217 are fixed, we should disable WPA Enterprise support.  Is this better filed as a Gaia issue?

Comment 1

[Andrew Overholt [:overholt]]

Blake, is this something you can do?

Comment 2

[Daniel Coloma:dcoloma]

Before disabling this, can we check there is no other option?

Part of the development team is based in premises where this is the only WiFi security mechanism allowed (see https://bugzilla.mozilla.org/show_bug.cgi?id=775499#c17)

Comment 3

[Andrew Overholt [:overholt]]

What needs to be done here?  Who is the best person to do it?

Comment 4

[Blake Kaplan (:mrbkap) (inactive)]

(In reply to Andrew Overholt [:overholt] from comment #3)
> What needs to be done here?  Who is the best person to do it?

I'd prefer to see this fixed in Gaia. Basically we could disable WPA-EAP support in the backend entirely (which would also be easy) or remove the UI for it in the frontend. This would be a stopgap measure until we have the time and resources to fix bug 789217 which will involve firing events for unrecognized certs.

For developers who only have access to WPA-EAP networks, they could flash a wpa_supplicant.conf to their phone.

Comment 5

[Antonio Manuel Amaya Calvo (:amac)]

As Daniel said, we would prefer to fix bug 789217 instead of disabling WPA Enterprise. If it's a problem of resources, we can take over bug 789217 on TEF if you wish.

Comment 6

[Alex Keybl [:akeybl]]

Milestoning for C2 (deadline of 12/10), as this meets the criteria of "known P2 bugs found before or during C1".

Comment 7

[Dietrich Ayala (:dietrich)]

No update for nearly a month. What needs to happen to move this forward?

Comment 8

[Antonio Manuel Amaya Calvo (:amac)]

I posted a WIP patch for bug 775499 earlier today. I don't think we should disable EAP at all, we can land the patch for 77499 instead in time which will leave us on par with current Android systems in regard to EAP support and certificate verification. 

So in short, I think this bug should be resolved as invalid, and bug 775499 should be marked as blocking instead.

Comment 9

[Dietrich Ayala (:dietrich)]

I don't know enough to make that call. Blake?

Comment 10

[Alex Keybl [:akeybl]]

Let's move forward here. See https://bugzilla.mozilla.org/show_bug.cgi?id=775499#c37.

Comment 11

[Dietrich Ayala (:dietrich)]

Thanks Alex. Blake, when can you have a fix for this available?

Comment 12

[JP Rosevear [:jpr]]

Deferring, not really necessary for C2 but it would be good to get this off our list.

Comment 13

[Dietrich Ayala (:dietrich)]

No update from mrbkap since October. What needs to happen here?

Comment 14

[Dietrich Ayala (:dietrich)]

Mrbkap says can fix this week.

Comment 15

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: patch, v1

This patch no longer shows WPA-EAP networks in the available network list unless they were previously configured. Even after this patch, people can manually patch their wpa_supplicant.conf to connect to WPA-EAP networks.

Comment 16

[Chris Lee [:clee]]

Just spoke with Fabrice and here's the following suggestion to move forward on this bug:

*Let's land this bug once the patch has been r+'ed
*Can we add a pref to custom-prefs.js to allow developers/dogfooders to toggle this on if necessary?  (We have specific partner needs to be able to use WPA enterprise networks for testing purposes.)

Blake, could you confirm if this is feasible?  Thanks.

Comment 17

[Chris Lee [:clee]]

One additional note:

*Can we hold off landing this patch until we have a path forward on the 2nd bullet regarding the pref?  Thanks.

Comment 18

[Blake Kaplan (:mrbkap) (inactive)]

(In reply to Chris Lee [:clee] from comment #16)
> Blake, could you confirm if this is feasible?  Thanks.

Sure, that's easy.

Comment 19

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Allow WPA-EAP networks based on a gecko pref.

Note: this is untested (I'm at my parents' house and don't have an EAP network to test on. Fabrice, would you mind testing? Note that we read the pref in onsupplicantconnection, which means that it'll be necessary to turn wifi off and on for the pref to take effect. It's easy to fix that restriction, but I don't know if it's worth it.


Feedback: :fabrice

Comment 20

[[:fabrice] Fabrice Desré]

Comment on attachment 694692 [details] [diff] [review]
Allow WPA-EAP networks based on a gecko pref.

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

look good with a try { } catch(e){} to not blow up.

::: dom/wifi/WifiWorker.js
@@ +1784,5 @@
>        self._enableAllNetworks();
>        WifiManager.saveConfig(function() {})
>      });
>  
> +    self._allowWpaEap = Services.prefs.getBoolPref("b2g.wifi.allow_unsafe_wpa_eap");

I think that will throw if the pref is not defined at all.

Comment 21

[Vincent Chang[:vchang][changyihsin]]

Comment on attachment 694558 [details] [diff] [review]
patch, v1

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

Looks good.

Comment 22

[Vincent Chang[:vchang][changyihsin]]

(In reply to Vincent Chang[:vchang] from comment #21)
> Comment on attachment 694558 [details] [diff] [review]
> patch, v1
> 
> Review of attachment 694558 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Looks good.

I have verified this patch, it looks good.

Comment 23

[Vincent Chang[:vchang][changyihsin]]

Comment on attachment 694692 [details] [diff] [review]
Allow WPA-EAP networks based on a gecko pref.

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

It will throw if the pref is not defined.
Do we need to hook it to settings ?

Comment 24

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Pref patch, v2

This adds the needed try/catch. I don't want to make this a setting as I don't think this is a gaia-level decision. If the user wants to open him/herself up to bug 775499 that's something I'd prefer that they do themselves in a very out-of-the-ordinary way. We should also try to get this patch in sooner rather than later and if people want, adding a setting as well as (or in addition to) the pref can be done in a followup.

Comment 25

[Blake Kaplan (:mrbkap) (inactive)]

remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/b256fb454e3c
remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/911c7371b8b3

Comment 26

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

https://hg.mozilla.org/mozilla-central/rev/b256fb454e3c
https://hg.mozilla.org/mozilla-central/rev/911c7371b8b3

Comment 27

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/f734cc8be18f
https://hg.mozilla.org/releases/mozilla-aurora/rev/e30288e7b9c1

https://hg.mozilla.org/releases/mozilla-b2g18/rev/bcb4088c8ac1
https://hg.mozilla.org/releases/mozilla-b2g18/rev/98cf2a9809e1