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. [PATCH] technology: Deny P2P finding if technology is
disabled ([email protected])
2. Re: [PATCH] timeserver: Update nameservers when DNS changed.
(Patrik Flykt)
3. Re: [PATCH 0/5] Avoid to keep service in list if AP is not
found during scan (Patrik Flykt)
4. Re: [PATCH] timeserver: Update nameservers when DNS changed.
(Antoine Aubert)
5. Re: [PATCH v2 1/1] doc: add online check information
(Daniel Wagner)
6. Re: Service remains on service list even if it is not longer
available (Daniel Wagner)
----------------------------------------------------------------------
Message: 1
Date: Mon, 20 Feb 2017 10:23:17 +0000
From: [email protected]
To: [email protected]
Subject: [PATCH] technology: Deny P2P finding if technology is
disabled
Message-ID:
<1487586197-19142-1-git-send-email-jose.blanquicet-melen...@magnetimarelli.com>
From: Jose Blanquicet <[email protected]>
Currently, when a scan is requested, it is only check if device is powered. It
prevents to start scanning or finding if WiFi technology is disabled. However,
when WiFi technolgy is enabled but P2P technology is not, the P2P finding
can be started anyway. This patch prevents it by adding an additional control
on the technology status only in case the technology where scan was requested is
P2P, doing so the return values for WiFi technology will not change.
---
src/technology.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/technology.c b/src/technology.c
index 4574f1e..d2f0ae2 100644
--- a/src/technology.c
+++ b/src/technology.c
@@ -1077,6 +1077,10 @@ static DBusMessage *scan(DBusConnection *conn,
DBusMessage *msg, void *data)
DBG("technology %p request from %s", technology,
dbus_message_get_sender(msg));
+ if (technology->type == CONNMAN_SERVICE_TYPE_P2P &&
+ !technology->enabled)
+ return __connman_error_permission_denied(msg);
+
dbus_message_ref(msg);
technology->scan_pending =
g_slist_prepend(technology->scan_pending, msg);
--
1.9.1
------------------------------
Message: 2
Date: Mon, 20 Feb 2017 14:12:53 +0200
From: Patrik Flykt <[email protected]>
To: Antoine Aubert <[email protected]>, [email protected]
Subject: Re: [PATCH] timeserver: Update nameservers when DNS changed.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Fri, 2017-02-17 at 14:37 +0100, Antoine Aubert wrote:
> When the IP address changes, DNS provided by the DHCP may change.
> We should update namerver list.
>
> Bug seen on various internet provider box. During xDSL
> syncronisation,
> the first DNS server is a fake one. Later, a renew set another DNS.
There is already commit c7fbfdf976a0133e53ac35d5bd653f734772a994 doing
this, so that change did not work after all?
Cheers,
Patrik
> ---
> ?src/timeserver.c | 13 +++++++++++++
> ?1 file changed, 13 insertions(+)
>
> diff --git a/src/timeserver.c b/src/timeserver.c
> index f0d33e5..0e555a7 100644
> --- a/src/timeserver.c
> +++ b/src/timeserver.c
> @@ -291,6 +291,8 @@ static void ts_recheck_enable(void)
> ?int __connman_timeserver_sync(struct connman_service
> *default_service)
> ?{
> ? struct connman_service *service;
> + char **nameservers;
> + int i;
> ?
> ? if (default_service)
> ? service = default_service;
> @@ -314,6 +316,17 @@ int __connman_timeserver_sync(struct
> connman_service *default_service)
> ? if (resolv_id > 0)
> ? g_resolv_cancel_lookup(resolv, resolv_id);
> ?
> + g_resolv_flush_nameservers(resolv);
> +
> + nameservers = connman_service_get_nameservers(service);
> + if (!nameservers)
> + return -EINVAL;
> +
> + for (i = 0; nameservers[i]; i++)
> + g_resolv_add_nameserver(resolv, nameservers[i], 53,
> 0);
> +
> + g_strfreev(nameservers);
> +
> ? g_slist_free_full(ts_list, g_free);
> ?
> ? ts_list = __connman_timeserver_get_all(service);
------------------------------
Message: 3
Date: Mon, 20 Feb 2017 14:14:15 +0200
From: Patrik Flykt <[email protected]>
To: [email protected], [email protected]
Cc: [email protected], [email protected], Jose
Blanquicet <[email protected]>
Subject: Re: [PATCH 0/5] Avoid to keep service in list if AP is not
found during scan
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Fri, 2017-02-17 at 14:03 +0000, [email protected] wrote:
> From: Jose Blanquicet <[email protected]>
>
> This patch set does not remove any auto-connect/roaming
> functionality,
> it aims to avoit keeping service in the list after AP deauthenticate?
> us and it is not found in the scan.
>
> The first three patches revert the patches that add the connectable
> flag because such implementation prevents ConnMan to remove the
> service
> from the services list when it is no longer in range, resulting in a
> confusion for users because they will continue seeing a service in
> their
> list when it is not actually available.
>
> Doing so, ConnMan will remove the service as other services and then,
> once it comes back, wpa_s will notify ConnMan about it through a
> "BSSAdded" signal which will start auto-connect procedure and state
> machines would continue correctly. In case wpa_s does not send such
> signal before notifying we got connected, which should not happen,
> the
> last two patches of this set introduce a notification named
> "network_associated" which should handle this border case. I tested
> it
> by simulating ConnMan do not process "BSSAdded" signals and it
> worked,
> it means that state machines moved correctly and connection trigger
> from wpa_s completed successfully.
>
> I do not think I could trigger all use cases thus I would appreciate
> if
> people could test auto-connect and roaming use cases. Mainly
> auto-connect when AP is who deauthenticate STA. For instance, Saurav
> Babu in the scenario he recently mentioned when AP blocks STA's MAC
> address.
Thanks! Compiled ConnMan with these and the P2P technology patch. So
far so good, but let me leave this running for a while still...
Cheers,
Patrik
>
> Jose Blanquicet (5):
> ? Revert "device: Use network's connectable flag"
> ? Revert "plugins/wifi: Marking network's Connectable flag as true."
> ? Revert "network: connectable flag in network structure"
> ? gsupplicant: Add callback to notify the associated network
> ? wifi: Set current network in case of reconnection
>
> ?gsupplicant/gsupplicant.h |??1 +
> ?gsupplicant/supplicant.c??| 25 +++++++++++++++
> ?include/network.h?????????|??5 ---
> ?plugins/wifi.c????????????| 82 +++++++++++++++++++++++++++++------
> ------------
> ?src/device.c??????????????|??6 +---
> ?src/network.c?????????????| 13 --------
> ?6 files changed, 78 insertions(+), 54 deletions(-)
>
------------------------------
Message: 4
Date: Mon, 20 Feb 2017 13:50:46 +0100
From: Antoine Aubert <[email protected]>
To: Patrik Flykt <[email protected]>, [email protected]
Subject: Re: [PATCH] timeserver: Update nameservers when DNS changed.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Le 20/02/2017 ? 13:12, Patrik Flykt a ?crit :
> On Fri, 2017-02-17 at 14:37 +0100, Antoine Aubert wrote:
>> When the IP address changes, DNS provided by the DHCP may change.
>> We should update namerver list.
>>
>> Bug seen on various internet provider box. During xDSL
>> syncronisation,
>> the first DNS server is a fake one. Later, a renew set another DNS.
> There is already commit c7fbfdf976a0133e53ac35d5bd653f734772a994 doing
> this, so that change did not work after all?
>
> Cheers,
>
> Patrik
>
>> ---
>> src/timeserver.c | 13 +++++++++++++
>> 1 file changed, 13 insertions(+)
>>
>> diff --git a/src/timeserver.c b/src/timeserver.c
>> index f0d33e5..0e555a7 100644
>> --- a/src/timeserver.c
>> +++ b/src/timeserver.c
>> @@ -291,6 +291,8 @@ static void ts_recheck_enable(void)
>> int __connman_timeserver_sync(struct connman_service
>> *default_service)
>> {
>> struct connman_service *service;
>> + char **nameservers;
>> + int i;
>>
>> if (default_service)
>> service = default_service;
>> @@ -314,6 +316,17 @@ int __connman_timeserver_sync(struct
>> connman_service *default_service)
>> if (resolv_id > 0)
>> g_resolv_cancel_lookup(resolv, resolv_id);
>>
>> + g_resolv_flush_nameservers(resolv);
>> +
>> + nameservers = connman_service_get_nameservers(service);
>> + if (!nameservers)
>> + return -EINVAL;
>> +
>> + for (i = 0; nameservers[i]; i++)
>> + g_resolv_add_nameserver(resolv, nameservers[i], 53,
>> 0);
>> +
>> + g_strfreev(nameservers);
>> +
>> g_slist_free_full(ts_list, g_free);
>>
>> ts_list = __connman_timeserver_get_all(service);
nameserver_add_all, doesn't affect gresolv object.
so, c7fbfdf976a0133e53ac35d5bd653f734772a994 work for dnsproxy, but not
for timeserver. (using g_resolv)
------------------------------
Message: 5
Date: Mon, 20 Feb 2017 15:40:59 +0100
From: Daniel Wagner <[email protected]>
To: Ingo Albrecht <[email protected]>, [email protected]
Subject: Re: [PATCH v2 1/1] doc: add online check information
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Ingo,
On 02/14/17 11:56, Ingo Albrecht wrote:
> Add new info from connman.net server admin to README.
> Mention the online check in the manual so that end users have a reference why
> the client
> opens an external route.
Thanks for your patch. I tried to apply it but it failed. Did you create
this patch via 'git commit -m "bla bla"; git send-patch HEAD~'?
Anyway I can apply it manually next week. I am traveling and don't have
access to my devel manchine. I wouldn't mind if you find time to update
your patch :)
Thanks,
Daniel
------------------------------
Message: 6
Date: Mon, 20 Feb 2017 15:44:23 +0100
From: Daniel Wagner <[email protected]>
To: Jose Blanquicet <[email protected]>
Cc: [email protected], [email protected], Patrik Flykt
<[email protected]>
Subject: Re: Service remains on service list even if it is not longer
available
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Jose,
On 02/17/17 14:53, Jose Blanquicet wrote:
> On Wed, Feb 8, 2017 at 8:55 AM, Jose Blanquicet wrote:
>>>>> When we get disconnected because of AP we are connected to goes out of
>>>>> range. ConnMan keeps showing such AP in the services list even though
>>>>> it is not longer available (We cannot connect to it). In addition,
>>>>> such AP will continue in our service list even if we connect to a new
>>>>> one. What is the propose of keeping that AP in the services list? From
>>>>> our point of view it creates confusion to the user. We would prefer to
>>>>> not do that, what do people think?
>
> Well, it has not been easy to follow the code but I think I got
> something. Now, looking into details what Naveen developed, I noticed
> that the connectable flag he introduced is exactly what prevents
> ConnMan to remove the service from the services list. He described the
> issue as:
>
> "On receiving a deauth with reason code 6, 7 or 4 wpa_supplicant will
> immediately try to connect back. Now with current implementation of
> connman, a disconnect notification will cause network to get disabled
> and connection procedure would stop. This also impacts the roaming
> time in case disconnect is because of any other reason code. The act
> of disabling network severly affects wpa_s connection state machine as
> it would generate a deauth to current network when half way the
> connection was done."
>
> I completely agree and he solved it in commit
> 6245582d0dc9a3f47a6880dabf437ee7c351caef by avoiding to disable the
> network profile on wpa_s, which indeed decreased the re-connection
> time and save D-Bus calls as he said (I saw in the mailing list
> archives that it was a long discussion with Patrik).
>
> From my point of view, the issue was completely solved at that point
> and there was not need of the next patches where he introduced the
> connectable flag which prevent service to be removed even though it is
> not found in the scan. Trying to understand why he did so, I followed
> the discussion on the mailing list archives [1] (Then the patch was
> split into three). I more or less agree with such patch, well more
> less than more because there should be no way that wpa_s tells ConnMan
> it is connected to a BSS which it has not already sent a "BSSAdded"
> signal indicating such BSS entered into the range. Therefore, by the
> time of a success connection, the service state machine will indeed
> move because ConnMan is already aware of such BSS thus the service
> will already exist and ConnMan is prepared for a soon success
> connection. However, if we want to be very very precise, we could add
> a callback from gsupplicant to WiFi plugin when wpa_s notifies we are
> associated in order to ensure the state machines are prepared for a
> soon connection BUT without avoiding to remove the service. I will
> send a patch set doing so, we tested it and it works for us. Please
> let me know what do you think.
>
> [1] https://lists.01.org/pipermail/connman/2016-April/000583.html
Thanks for you analysis. I'll look into your patch next week. I don't
have access to my machine due to traveling right now. Maybe Patrik finds
time to look at it.
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 16, Issue 21
***************************************
