Send connman mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.01.org/mailman/listinfo/connman
or, via email, send a message with subject or body 'help' to
        [email protected]

You can reach the person managing the list at
        [email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."


Today's Topics:

   1. Re: Improve support for 802.1X? (Mike Purvis)
   2. DHCP renewal failure (Naveen Singh)


----------------------------------------------------------------------

Message: 1
Date: Thu, 3 Dec 2015 15:33:28 -0500
From: Mike Purvis <[email protected]>
To: Patrik Flykt <[email protected]>
Cc: [email protected]
Subject: Re: Improve support for 802.1X?
Message-ID:
        <cacsjt9nhud9-htgrr-c2mm8ga+o3fqggk-wrc9c-djoajdu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

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 <[email protected]>
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.01.org/pipermail/connman/attachments/20151203/424723ae/attachment-0001.html>

------------------------------

Message: 2
Date: Fri, 4 Dec 2015 07:28:48 -0800
From: Naveen Singh <[email protected]>
To: [email protected]
Subject: DHCP renewal failure
Message-ID:
        <cafk1zrbgbpi1znxj9t1nd88rcj0nyzmkhc8hha1jrkpm013...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi All
In case of DHCP server not being available and eventually device failing to
renew its IP address, I am observing following:

1. Connman service state is left to online.

2. Although the connman_ipconfig structure entries for ipv4 address is
cleared out, connman never generated service property changed event. This
probably is because DHCP renewal process never feeds back to service state
machine from where we generate these events. At this point if we run
connmanctl, for ipv4 configuration it will still show the old IP address.

3. I am not sure how IPV4LL would be handled.

Not sure if we can do anything for 1 or not as connman service state is an
OR of ipv4 service state and ipv6 service state. But for sure 2 looks like
an issue. Currently there is no API to indicate clearing of IP address. I
am working on a patch to have an API which would indicate generating of a
Service property changed API when IP address is set to NULL. But before
that I wanted to get the feedback on the current behavior and find out if
this is an intended behavior or a bug?

Regards
Naveen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.01.org/pipermail/connman/attachments/20151204/c6777737/attachment-0001.html>

------------------------------

Subject: Digest Footer

_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman


------------------------------

End of connman Digest, Vol 2, Issue 5
*************************************

Reply via email to