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: [PATCH 1/3] session: Maintain bearer priority in session
policy file (Daniel Wagner)
2. Re: Aw: Re: [PATCH] service: Add EnableOnlineCheck config
option (Daniel Wagner)
3. Re: Wi-Fi specific information in connman (Marcel Holtmann)
4. Re: PacRunner DBus activation (Marcel Holtmann)
5. Re: [PATCH] service: Add EnableOnlineCheck config option
(Marcel Holtmann)
6. Re: [PATCH] service: Add EnableOnlineCheck config option
(Marcel Holtmann)
----------------------------------------------------------------------
Message: 1
Date: Sat, 4 Feb 2017 21:43:20 +0100
From: Daniel Wagner <[email protected]>
To: Daryl Nebrich <[email protected]>, [email protected]
Subject: Re: [PATCH 1/3] session: Maintain bearer priority in session
policy file
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Daryl,
All three patches pushed. I had to rebase and edit them by hand because
of Lukasz changes. While I was add it I dropped the comment. Please
check if I shrewd it up.
Thanks,
Daniel
------------------------------
Message: 2
Date: Sat, 4 Feb 2017 22:01:04 +0100
From: Daniel Wagner <[email protected]>
To: Ingo Albrecht <[email protected]>
Cc: [email protected]
Subject: Re: Aw: Re: [PATCH] service: Add EnableOnlineCheck config
option
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Ingo,
On 02/03/2017 07:46 PM, Ingo Albrecht wrote:
> While I appreciate the work, being able to --disable-wispr during
> configure unfortunately is a functionality trade-off for all end-users,
> who would rather be able to configure it at runtime.[1]
Oh well, I agree, runtime config it is...
> I actually agree with Marcel on the point that making the online
> check URL itself configurable introduces other problems.[2][3]
The server side of online check needs also be available as source code.
I don't think it is okay to rely on a black box for an open source project.
Thanks,
Daniel
------------------------------
Message: 3
Date: Sun, 5 Feb 2017 14:54:45 +0100
From: Marcel Holtmann <[email protected]>
To: Saurav Babu <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: Wi-Fi specific information in connman
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Saurav,
> Sorry for the late reply, it got lost somewhere.
>> On 01/11/2017 02:04 PM, Patrik Flykt wrote:
>>> On Wed, 2017-01-11 at 16:43 +0530, Saurav Babu wrote:
>>>> There are few applications which require Wi-Fi specific informations
>>>> like MAC Address, Frequency/Channel of AP. Is there any specific
>>>> reason that these informations are not stored by connman?
>
>> Can you elaborate a bit on your use case? I'd like to understand why you
>> want that information. One thing which comes to my mind is that you want
>> to show it to the user.
>
> For WPS PBC and PIN connection wpa_supplicant allows BSSID to be passed as
> argument. If BSSID is passed as argument to WPS Connection and any other
> device
> tries to use PBC then negotiation is rejected by wpa_supplicant.
>
> Currently ConnMan doesn't provide any way to perform channel based scan. It
> always performs full channel scan which takes more time compared to single
> channel scan. With knowledge of frequency application can decide to trigger
> full channel or channel based scan for greater authority in connection
> mechanism.
this does not belongs to ConnMan. This is something that we are doing inside
iwd. Main problem is just that wpa_supplicant is not WiFi daemon. It is a
supplicant that tries to be more, but fails at it badly. This will be all fixed
once we start switching to iwd as the only WiFi provider. And frankly, trying
to fix this inside ConnMan is just pushing the problems into higher layers that
have nothing to do with it. It will ultimately create a mess and break more
things than it fixes.
Regards
Marcel
------------------------------
Message: 4
Date: Sun, 5 Feb 2017 14:59:14 +0100
From: Marcel Holtmann <[email protected]>
To: Atul Anand <[email protected]>
Cc: David Woodhouse <[email protected]>, connman
<[email protected]>, Sriram Ramkrishna <[email protected]>, atuljhp
<[email protected]>, Colin Walters <[email protected]>
Subject: Re: PacRunner DBus activation
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Atul,
> Just for confirmation:
>
> On 2/3/17, David Woodhouse <[email protected]> wrote:
>> PacRunner is currently started by DBus activation by either clients
>> (the org.pacrunner.Client interface) or managers (the
>> org.pacrunner.Manager interface).
>>
>> ConnMan watches the bus, and when PacRunner is activated, will push the
>> proxy configuration into place. I don't think NetworkManager does this
>
> NM adopts the same model[1]. It keeps an eye on PacRunner and push
> configs as soon as it appears on Bus.
I actually wonder if we should design a PACrunner mode that allows it to run as
user on the session bus. So ever user has its own PACrunner instance and we
just activate it as needed. It also means that each user can have its own proxy
configuration and will not affect some other user.
However this means that PACrunner has to actively tell ConnMan, networkd etc.
that it is present. Which means in return all the network daemons have to
program the configurations multiple times (one time for each user).
Regards
Marcel
------------------------------
Message: 5
Date: Sun, 5 Feb 2017 15:06:02 +0100
From: Marcel Holtmann <[email protected]>
To: Ingo Albrecht <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] service: Add EnableOnlineCheck config option
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Ingo,
>>> Global config option, which allows to enable/disable (enabled by default)
>>> use of http get in wispr to transition a default service from READY to
>>> ONLINE state.
>>
>> Isn't
>>
>> ./configure --disable-wispr
>>
>> good enough?
>>
>> Thanks,
>> Daniel
>
> Hi,
>
> no it isn't.
> In fact the online check as it is done so far (default enabled, no option to
> turn it off, no mention of it in the manpage, no privacy policy available for
> the nginx server replying on how it cycles logs) can quickly get this project
> into trouble. The current implementation clearly violates privacy laws
> (EU-wide for starters).
you mean /dev/null which is the current log file storage and log rotation
policy. And for the open source version of ConnMan, you know exactly what it
sends and where. That is the point behind it.
If you want to change it, you have to modify it. And thanks to the GPL license
requirement, publish the source of that change. A configuration file will not
force that and then the ConnMan side can become the black box.
Regards
Marcel
------------------------------
Message: 6
Date: Sun, 5 Feb 2017 15:19:45 +0100
From: Marcel Holtmann <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: Ingo Albrecht <[email protected]>, [email protected]
Subject: Re: [PATCH] service: Add EnableOnlineCheck config option
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi Daniel,
>> While I appreciate the work, being able to --disable-wispr during
>> configure unfortunately is a functionality trade-off for all end-users,
>> who would rather be able to configure it at runtime.[1]
>
> Oh well, I agree, runtime config it is?
not without proper and detailed documentation. The potential for shooting
themselves in the foot is too high. Most companies will underestimate the
requirements for actually running the server.
And everybody will underestimate the reason for X-ConnMan-Status field. I had
these discussion before and most people do not understand the massive mess the
WiFi portals are causing. I am totally fine if someone wants to fully disable
this feature at compile time.
However all these half baked ideas and then broken instances of ConnMan is not
something I want to have ever being reported back to the mailing list. I even
say that ConnMan should print a warning at startup if the portal detection code
has been disabled.
>> I actually agree with Marcel on the point that making the online
>> check URL itself configurable introduces other problems.[2][3]
>
> The server side of online check needs also be available as source code. I
> don't think it is okay to rely on a black box for an open source project.
Frankly we had a project for the server side code as an independent self
written daemon. We never put that into production since all you need is nginx
and a dead simple config for it. As I said before, you do not store any logs
and you have to access to the file system and it just runs and runs and runs.
I could probably spent hours talking about the lessons learned from running
connman.net server. It is something interesting in what happens and what is
needed to make this fly.
One thing that might cause to re-activate the open source project of the server
is that fact that I think using HTTPS for the portal detection code might be
actually something to explore. About 6 month ago, I spent some time on this and
besides the extra workload for the server (or servers with dedicated SSL
hardware like QuickAssist), the real power only comes client certificates. And
that brings in other questions. If someone wants to discuss this, I happy to do
so, but that is no as easy as some people might think. Especially if you take
privacy serious.
Regards
Marcel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 16, Issue 10
***************************************
