After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 624939 - Should auto-detect EAP authentication type
Should auto-detect EAP authentication type
Status: RESOLVED OBSOLETE
Product: NetworkManager
Classification: Platform
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Dan Williams
Dan Williams
Depends on:
Blocks:
 
 
Reported: 2010-07-21 15:49 UTC by Michael Biebl
Modified: 2020-11-12 14:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Dialogue box proposed for a new connection (41.79 KB, image/png)
2019-02-14 17:04 UTC, Eugen Dedu
Details
Dialogue box of eduroam (37.51 KB, image/png)
2019-02-14 17:05 UTC, Eugen Dedu
Details

Description Michael Biebl 2010-07-21 15:49:59 UTC
This bug was reported as http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586858

In talking with someone who uses wpa-supplicant directly to connect to a
WPA-EAP-protected network, they asked why NetworkManager needs to ask
for the EAP authentication type (TTLS, PEAP, etc), and why it needs to
ask for the inner authentication type.  Apparently, wpa-supplicant can
autodetect all of those from an EAP configuration packet.  It certainly
would make connecting to WPA networks easier if NetworkManager could
autodetect this as well (or let wpa-supplicant do so)


<dcbw> mbiebl: yes, that's possible.  what we need to do on the NM side is allow more than one EAP configuration in a connection
<dcbw> mbiebl: like Mac OS X and windows have basically checkbox lists that allow you to enable any number of EAP methods for a certain network
<dcbw> mbiebl: that means you still get to *configure* the methods you want to allow
<dcbw> mbiebl: but after having done so, we'd be able to connect to a network that might offer TTLS in one location and PEAP in another
Comment 1 Pavel Simerda 2012-07-24 19:44:33 UTC
Reopen if still applicable.
Comment 2 Michael Biebl 2012-07-24 20:23:00 UTC
(In reply to comment #1)
> Reopen if still applicable.

Is this supposed to be fixed?
Comment 3 Pavel Simerda 2012-07-25 11:15:36 UTC
It should have been marked OBSOLETE, sorry. Your report is against an
old version and nobody has replied for a long time. Please test with a recent version and we can reopen it.
Comment 4 Josh Triplett 2017-12-13 00:42:24 UTC
I don't know why this was closed as obsolete, but it still exists in current NetworkManager. Setting up an EAP connection still requires manually specifying the authentication type.
Comment 5 Andrej Shadura 2019-02-10 10:10:13 UTC
Any updates on this?
Comment 6 Eugen Dedu 2019-02-14 17:04:57 UTC
Created attachment 374197 [details]
Dialogue box proposed for a new connection
Comment 7 Eugen Dedu 2019-02-14 17:05:21 UTC
Created attachment 374198 [details]
Dialogue box of eduroam
Comment 8 Eugen Dedu 2019-02-14 17:09:51 UTC
I have a working connection to eduroam.

374197 attachment shows the fields proposed when I connect to it as a new connection.  374198 attachment shows the fields as they should be to have a working connection.

We can see that Authentication is identical in both cases (I do not know if this is because Tuneled TLS is chosen by default or if it was discovered).  As for Inner authentication, it is different: it proposes MSCHAPv2 (no EAP), whereas it should be PAP.

I use network-manager 1.14.4-4 in debian.

HTH
Comment 9 André Klapper 2020-11-12 14:29:52 UTC
bugzilla.gnome.org is being shut down in favor of a GitLab instance. 
We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time.

If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/

Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).