Thanks for the response.

In my immediate case, I'm dealing with an 802.1X network which required only username and password, not a cert, so I was surprised to find out 802.1X was supported when I had received a cryptic error message upon trying to connect, rather than the expected username/password prompt.

At the very least, the error message be improved from "Invalid arguments" to something more like:

"Connection to EAP networks is supported, but you must create an additional configuration file, and specify the appropriate SSL certificate supplied by your system administrator. Please see the following webpage for information on connecting to EAP with connman: https://....."



On 30 November 2015 at 04:41, Patrik Flykt <Patrik.Flykt@linux.intel.com> wrote:
On Fri, 2015-11-27 at 16:42 -0500, Mike Purvis wrote:
> My experience with connman 1.30 mirrors this one:
>
> https://github.com/andrew-bibb/cmst/issues/2#issuecomment-40088345
>
> According to the linked ticket (https://01.org/jira/browse/CM-569),
> it's totally possible, but nothing about the supplied error message
> hints at this possibility. The ideal would be if this could be dealt
> with interactively, but the next best thing would be "Hey, looks like
> you're connecting to an 802.1X network— please see here for
> instructions on creating the necessary authentication file:
> http://.... "
>
> There's also some coverage on the Arch wiki which I found helpful:
>
> https://wiki.archlinux.org/index.php/WPA2_Enterprise#connman
>
> Thoughts?

There you have it in a nutshell. The eduroam config that comes with
ConnMan works for those universities that use peap for authentication.
Now those universities that use ttls to do the same authentication need
to configure their eduroam networks according to the arch linux web
page. EAP methods to use are defined by the end system authentication
setup handled by the university in question. The Access Point has no
idea what authentication will be requested, it only relays the EAP
authentication between the client and the back-end system. As a result
it will be told a set of keys to be used but nothing else.

The easiest way to set this one up is unfortunately a helpful system
admin handing out proper configuration files for ConnMan. Since we all
know this won't happen, the second easiest solution is to have the user
to run a wizard UI app to set up the connection. A decent wizard
application is not easy to do and moves all of the configuration pain to
the user.

ConnMan isn't of any helpful use here. All of the EAP communication
happen between the EAP authentication system and wpa_supplicant (and
relayed by the Access Point). So if someone needs a accurate on-the-fly
configuration app that asks only the needed questions, someone needs to
provide that feature to wpa_supplicant. ConnMan can fill in with a user
name and passphrase, should those be the only things missing.

But none of the above will work unless the user has already obtained the
necessary credentials and certificates beforehand, as is so well
depicted in the example on the arch linux web page with that CaCertFile
configuration option. This is really the main issue with setting up an
EAP connection - the user needs to be given a user id and passphrase and
usually also a certificate before attempting a connection. No amount of
configuration options will be enough if certificates and/or
ids/passphrases are missing.

For practical purposes it should be documented which universities use
peap and which ttls, so that there is one less point of confusion...
Also, if it is easier to understand(?) one can always think of changing
the returned error value in case of EAP. If it gives a better clue on
what is going on, I'm all for it.


Cheers,

        Patrik