The applet has a new D-Bus method, "ConnectTo8021xNetwork" which takes the arguments "oo" (device object path, AP object path) and will show the UI if that AP is a WPA 802.1x capable AP, and then call NM's AddAndActivate method.

The indicator should do the following things before calling that method:

1) make sure to only call it for 802.1x capable APs
2) make sure to only call it for APs that have no existing connections that could be used with that AP (ConnectTo8021xNetwork does no dupe checking)

To figure out whether an AP is a WPA 802.1x capable AP, do this:

if (   (nm_access_point_get_wpa_flags (ap) & NM_802_11_AP_SEC_KEY_MGMT_802_1X)
    || (nm_access_point_get_rsn_flags (ap) & NM_802_11_AP_SEC_KEY_MGMT_802_1X)) {

note that this doesn't take into account Dynamic WEP APs, which are APs that use WEP encryption but use 802.1x for authentication.  These APs are harder to identify, because they exactly the same as a WEP key (ie non-802.1x access point).  These configurations are fortunately rare, and I'd feel comfortable about requiring the user of a Dynamic WEP network to visit the control center panel once to set up the network using the "Options..." button.  I don't think we need to handle connecting to Dynamic WEP networks automatically using the Dialog Of Doom from the indicator, given that we cannot distinguish between Dynamic WEP and standard WEP key/passphrase.

If nobody gets to the shell before I get up tomorrow, I'll do a quick patch.

(In reply to comment #1)
> If nobody gets to the shell before I get up tomorrow, I'll do a quick patch.

Yeah, I wouldn't be able to test it now anyway, so...

(In reply to comment #1)
> The applet has a new D-Bus method, "ConnectTo8021xNetwork" which takes the
> arguments "oo" (device object path, AP object path) and will show the UI if
> that AP is a WPA 802.1x capable AP, and then call NM's AddAndActivate method.
> 
> The indicator should do the following things before calling that method:
> 
> 1) make sure to only call it for 802.1x capable APs
> 2) make sure to only call it for APs that have no existing connections that
> could be used with that AP (ConnectTo8021xNetwork does no dupe checking)

Why is this needed? Can't NetworkManager just Do The Right Thing: fill the security settings with the most secure possible configuration (unless a security setting is already present), and then call out to the secret agent?

(In reply to comment #3)
> (In reply to comment #1)
> > The applet has a new D-Bus method, "ConnectTo8021xNetwork" which takes the
> > arguments "oo" (device object path, AP object path) and will show the UI if
> > that AP is a WPA 802.1x capable AP, and then call NM's AddAndActivate method.
> > 
> > The indicator should do the following things before calling that method:
> > 
> > 1) make sure to only call it for 802.1x capable APs
> > 2) make sure to only call it for APs that have no existing connections that
> > could be used with that AP (ConnectTo8021xNetwork does no dupe checking)
> 
> Why is this needed? Can't NetworkManager just Do The Right Thing: fill the
> security settings with the most secure possible configuration (unless a
> security setting is already present), and then call out to the secret agent?

Because at the moment, the secret agents are for *secrets* only, and before you try to connect (for the moment at least) you need to know what EAP methods the RADIUS server behind the AP supports, and you need to know things like username, password, certificates, PEAP version, etc for the RADIUS server, and none of that is broadcast in the AP's beacon at all, since it has nothing to do with WiFi.  The Access Point just says "hey, when you connect you need to authenticate with EAP" but it says nothing about *how* to authenticate, and in many instances the user simply has to know what the configuration is, it's not something we can autodetect at all.

There are ways to make this better in the future, like connecting to the AP initially and retrieving the default EAP method that the RADIUS server says it wants, then asking the user for the details of those, but that's still a ways off and we need supplicant changes to expose that sort of information to NM in the first place.  Until then, the user just has to fill out the Dialog of Doom.

Created attachment 187136 [details] [review]
Fix handling of AP security flags and enhance for 802.1x

Review of attachment 187136 [details] [review]:

You're the one who knows what all those flags mean, so I can only comment on code, and I can't find anything wrong with it.

::: js/ui/status/network.js
@@ +1136,3 @@
         let wpa_flags = accessPoint.wpa_flags;
         let rsn_flags = accessPoint.rsn_flags;
+        let type = NM80211ApSecurityFlags.UNKNOWN;

NMAccessPointSecurity.UNKNOWN
(doesn't make much difference because it is 0 anyway)

(In reply to comment #4)
> (In reply to comment #3)
> [...]
> 
> Because at the moment, the secret agents are for *secrets* only, and before you
> try to connect (for the moment at least) you need to know what EAP methods the
> RADIUS server behind the AP supports, and you need to know things like
> username, password, certificates, PEAP version, etc for the RADIUS server, and
> none of that is broadcast in the AP's beacon at all, since it has nothing to do
> with WiFi.  The Access Point just says "hey, when you connect you need to
> authenticate with EAP" but it says nothing about *how* to authenticate, and in
> many instances the user simply has to know what the configuration is, it's not
> something we can autodetect at all.
> 
> There are ways to make this better in the future, like connecting to the AP
> initially and retrieving the default EAP method that the RADIUS server says it
> wants, then asking the user for the details of those, but that's still a ways
> off and we need supplicant changes to expose that sort of information to NM in
> the first place.  Until then, the user just has to fill out the Dialog of Doom.

Understood. But in any case, ConnectTo8021xNetwork is too late for 3.0.1, and for 3.2 we've planned integrated network dialogs (pending missing designs), which should remove the need for calling nm-applet.

(In reply to comment #7)
> (In reply to comment #4)
> > (In reply to comment #3)
> > [...]
> > 
> > Because at the moment, the secret agents are for *secrets* only, and before you
> > try to connect (for the moment at least) you need to know what EAP methods the
> > RADIUS server behind the AP supports, and you need to know things like
> > username, password, certificates, PEAP version, etc for the RADIUS server, and
> > none of that is broadcast in the AP's beacon at all, since it has nothing to do
> > with WiFi.  The Access Point just says "hey, when you connect you need to
> > authenticate with EAP" but it says nothing about *how* to authenticate, and in
> > many instances the user simply has to know what the configuration is, it's not
> > something we can autodetect at all.
> > 
> > There are ways to make this better in the future, like connecting to the AP
> > initially and retrieving the default EAP method that the RADIUS server says it
> > wants, then asking the user for the details of those, but that's still a ways
> > off and we need supplicant changes to expose that sort of information to NM in
> > the first place.  Until then, the user just has to fill out the Dialog of Doom.
> 
> Understood. But in any case, ConnectTo8021xNetwork is too late for 3.0.1, and
> for 3.2 we've planned integrated network dialogs (pending missing designs),
> which should remove the need for calling nm-applet.

There is actually a GNOME 3.0.2 scheduled; while this isn't really along the lines of things I've wanted for 3.0.x, it's pretty critical (maybe I'm a little biased because we use WPA Enterprise internally here at Red Hat), and I'd like to see if we can get something in the 3-0 branch for this... I'll look at patching the Fedora packages in any case, and it doesn't really make sense to say that I'd put a patch in Fedora but it's too risky for upstream.

Created attachment 187142 [details] [review]
Call out to nm-applet to do the 802.1x dirty work

*** Bug 647114 has been marked as a duplicate of this bug. ***

Review of attachment 187142 [details] [review]:

From the point of view of implementation, it is perfect, and I think it can go in, at least in master.

ae0652d13fc2d7caa3d64f2b87d174253cae5901