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 v2 0/3] add option to enable auto connection for
roaming (Daniel Wagner)
2. Re: wifi scan failing on ubuntu (Daniel Wagner)
3. Re: How can one specify what wired and wireless interfaces to
use? (Daniel Wagner)
4. Re: [PATCH 2/2] Don't forceably overwrite /etc/resolv.conf
(Daniel Wagner)
5. Re: [PATCH] gresolv: ignore valid dns response with no answer
(Daniel Wagner)
6. Re: [PATCH 0/4] d-bus reply to "scan p2p" is not send if
wifi/p2p scanning interleave in some unlucky way (Daniel Wagner)
7. [PATCH 1/2] device: fix enable/disable return code (Jonas Bonn)
8. [PATCH 0/2] Resend of patches... (Jonas Bonn)
9. [PATCH 2/2] ofono: removing contexts requires a careful list
walk (Jonas Bonn)
----------------------------------------------------------------------
Message: 1
Date: Thu, 4 Jan 2018 07:54:12 +0100
From: Daniel Wagner <[email protected]>
To: Christophe Ronco <[email protected]>
Cc: [email protected], Jonas Bonn <[email protected]>
Subject: Re: [PATCH v2 0/3] add option to enable auto connection for
roaming
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Christophe,
On 12/15/2017 10:34 AM, Christophe Ronco wrote:
> Hi,
>
> I need to auto-connect cellular services even if they are roaming.
> So I added an option in main.conf to enable that (or not).
> I don't know if this can be useful for other Connman users.
Finally found some time to do my job. I am not really fond adding new
config switches to main.conf, but this one at least is consistent with
the ones we have already. So I added it after changing patch #2 as Jonas
has suggested.
Thanks,
Daniel
------------------------------
Message: 2
Date: Thu, 4 Jan 2018 07:58:07 +0100
From: Daniel Wagner <[email protected]>
To: Klaus Anderson <[email protected]>
Cc: Julien Massot <[email protected]>, [email protected]
Subject: Re: wifi scan failing on ubuntu
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Klaus,
On 12/18/2017 08:59 PM, Klaus Anderson wrote:
> one more thing I should have probably mentioned: before switching to
> connman (with basicly apt install connman), I had a working network
> setup with Network Manager. So I presume the wifi HW and drivers are
> working ok.
One thing you could try, is to use a newer/different version of
wpa_supplicant. Wouldn't be the first time that wpa_supplicant's API or
behavior changed and ConnMan get's confused.
Thanks,
Daniel
------------------------------
Message: 3
Date: Thu, 4 Jan 2018 08:06:20 +0100
From: Daniel Wagner <[email protected]>
To: KARBOWSKI Piotr <[email protected]>
Cc: [email protected]
Subject: Re: How can one specify what wired and wireless interfaces to
use?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Piotr,
On 12/19/2017 07:33 PM, KARBOWSKI Piotr wrote:
> Hello,
>
> I'd like to ask, how can one specify what interfaces should be used?
>
> I see that I can start `connmand` with `-i` and `-I` switches and I
> could use that to omit devices, but that's a bit problematic.
>
> If I have two wireless cards, wlan0 and wlan1, how can I choose which to
> use to connect? I'd like to connect with wlan0 to one network and with
> wlan1 to another.
ConnMan handles the devices internal as separate entities. Though there
is no D-Bus API for exposing devices. There is the Service API which
gives you the network view. The main use case for ConnMan was to support
handheld devices with only one device available. So in short you can not
really control which device is used to connect. IIRC, some one reported
that he was able to use one device as client controlled by ConnMan and
the other one by hostapd. Don't know if that would work for your use
case though.
Thanks,
Daniel
------------------------------
Message: 4
Date: Thu, 4 Jan 2018 08:25:34 +0100
From: Daniel Wagner <[email protected]>
To: Jonas Bonn <[email protected]>, [email protected]
Subject: Re: [PATCH 2/2] Don't forceably overwrite /etc/resolv.conf
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Jonas,
On 12/20/2017 11:24 AM, Jonas Bonn wrote:
> Using L+ in the tmpfiles.d snippet is overly aggressive. These snippets
> are evaluated on every boot and may be evaluated on package upgrade.
> It's fine to check that the file /etc/resolv.conf exists, but forceably
> overwriting an existing file or link makes it difficult for connman to
> co-exist with other potential managers of /etc/resolv.conf.
I guess the L+ is to make sure that ConnMan wins. But yes, your argument
makes sense. It makes hard to co-exist.
Anyway, both patches applied.
Thanks,
Daniel
------------------------------
Message: 5
Date: Thu, 4 Jan 2018 08:47:24 +0100
From: Daniel Wagner <[email protected]>
To: Eliott Dumeix <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] gresolv: ignore valid dns response with no answer
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Eliott,
On 12/20/2017 05:28 PM, Eliott Dumeix wrote:
> +++ b/gweb/gresolv.h
> @@ -44,6 +44,11 @@ typedef enum {
> G_RESOLV_RESULT_STATUS_NAME_ERROR,
> G_RESOLV_RESULT_STATUS_NOT_IMPLEMENTED,
> G_RESOLV_RESULT_STATUS_REFUSED,
> + /*
> + * It means one or more resource records exist for this domain but there
> + * isn?t a record matching the resource record type.
> + */
> + G_RESOLV_RESULT_STATUS_NO_ANSWER,
I dropped the comment because it stands out. I am not against comentig
the flags but all not just one.
Also updated tools/resolv-test.c accordingly and applied everything.
Thanks,
Daniel
------------------------------
Message: 6
Date: Thu, 4 Jan 2018 09:07:08 +0100
From: Daniel Wagner <[email protected]>
To: Vasyl Vavrychuk <[email protected]>
Cc: [email protected], [email protected],
[email protected]
Subject: Re: [PATCH 0/4] d-bus reply to "scan p2p" is not send if
wifi/p2p scanning interleave in some unlucky way
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Vasyl,
On 12/26/2017 11:45 PM, Vasyl Vavrychuk wrote:
> * On connman start there is wifi scan started
> https://gitlab.com/snippets/1690556#L472.
> * Then suppose we call "scan p2p" from connmanctl.
> * Suppose `scan_callback` from wifi scan is received sooner than
> `p2p_find_stop` called.
> This callback will put device scanning property to 0.
> https://gitlab.com/snippets/1690556#L896
> * Then after p2p_find_stop callback https://gitlab.com/snippets/1690556#L978
> call to `connman_device_set_scanning` will not send reply_scan_pending for
> p2p technology because scanning property was already set to 0.
>
> On connmanctl side error is
>
> Error /net/connman/technology/p2p: Did not receive a reply. Possible
> causes include: the remote application did not send a reply, the message bus
> security policy blocked the reply, the reply timeout expired, or the network
> connection was broken.
>
> This is happening because we can start/stop scanning for device in
> per-service-type manner but this is not taken into account in
> `connman_device_set_scanning` code chunk
>
> if (device->scanning == scanning)
> return -EALREADY;
I suppose everyone had enough time to review it :) I was pondering if we
need the to extend connman_device_get_scanning() to except the SERVICE
type or just a bool saying it is a wifi or p2p service because the
function is only used for wifi or p2p. But then I think I would just do
shedding :)
So I went ahead and applied it after changing a few nitpicks (just
formatting) and adding the log snippets directly into the commit message
in patch #2. The commit message should be self contained. We have no
influence on the external resources and the links might just go stale
after a while.
My normal wifi stuff still works, so any p2p complains will be forwarded
to you :D
Thanks,
Daniel
------------------------------
Message: 7
Date: Thu, 4 Jan 2018 11:23:23 +0100
From: Jonas Bonn <[email protected]>
To: [email protected]
Subject: [PATCH 1/2] device: fix enable/disable return code
Message-ID: <[email protected]>
The powered_pending status is an indication that the powered status is
in the process of being changed; the correct return code here should be
"in progress".
Without this patch, setting a technology "Powered" for a slow ofono
device in the process of powering up results in an immediate DBus
response even though the device is far from being ready.
With this patch, setting a technology "Powered" returns first when the
property has actually changed which is the desired behaviour.
---
src/device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/device.c b/src/device.c
index a563f464..10fa64ac 100644
--- a/src/device.c
+++ b/src/device.c
@@ -179,7 +179,7 @@ int __connman_device_enable(struct connman_device *device)
return -EBUSY;
if (device->powered_pending == PENDING_ENABLE)
- return -EALREADY;
+ return -EINPROGRESS;
if (device->powered_pending == PENDING_NONE && device->powered)
return -EALREADY;
@@ -230,7 +230,7 @@ int __connman_device_disable(struct connman_device *device)
return -EBUSY;
if (device->powered_pending == PENDING_DISABLE)
- return -EALREADY;
+ return -EINPROGRESS;
if (device->powered_pending == PENDING_NONE && !device->powered)
return -EALREADY;
--
2.14.1
------------------------------
Message: 8
Date: Thu, 4 Jan 2018 11:23:22 +0100
From: Jonas Bonn <[email protected]>
To: [email protected]
Subject: [PATCH 0/2] Resend of patches...
Message-ID: <[email protected]>
...I think these might have gotten missed with the long quiescent period
over the holidays. These were originally sent on December 9 but received
no feedback.
/Jonas
Jonas Bonn (2):
device: fix enable/disable return code
ofono: removing contexts requires a careful list walk
plugins/ofono.c | 5 ++++-
src/device.c | 4 ++--
2 files changed, 6 insertions(+), 3 deletions(-)
--
2.14.1
------------------------------
Message: 9
Date: Thu, 4 Jan 2018 11:23:24 +0100
From: Jonas Bonn <[email protected]>
To: [email protected]
Subject: [PATCH 2/2] ofono: removing contexts requires a careful list
walk
Message-ID: <[email protected]>
The function remove_cm_context() modifies the context_list so the
list->next pointer is no longer valid on its return.
With this patch, we _carefully_ iterate over the context_list, assuming
that it may have been modified on each iteration.
Without this patch, only the first context in the list is successfully
removed; after that the behaviour is somewhat unpredictable! What I was
seeing was that services coupled to the second context were never
destroyed resulting in available services without a proper backing
device.
---
plugins/ofono.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/plugins/ofono.c b/plugins/ofono.c
index 78f8f196..82413b6e 100644
--- a/plugins/ofono.c
+++ b/plugins/ofono.c
@@ -1301,10 +1301,13 @@ static void remove_all_contexts(struct modem_data
*modem)
if (modem->context_list == NULL)
return;
- for (list = modem->context_list; list; list = list->next) {
+ list = modem->context_list;
+ while (list) {
struct network_context *context = list->data;
remove_cm_context(modem, context);
+
+ list = modem->context_list;
}
g_slist_free(modem->context_list);
modem->context_list = NULL;
--
2.14.1
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 27, Issue 1
**************************************
