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] technology: Deny P2P finding if technology is
disabled (Daniel Wagner)
2. Re: [PATCH] timeserver: Update nameservers when DNS changed.
(Daniel Wagner)
3. Re: [PATCH] gsupplicant: Do not modify ConfigMethods if they
are already set (Daniel Wagner)
4. Re: [PATCH] main: Make --noplugin option repeatable
(Daniel Wagner)
5. Re: [PATCH] ofono: Fix segfault during set_property
(Daniel Wagner)
6. Re: [PATCH] bluetooth: Check for network in callbacks
(Daniel Wagner)
7. Re: Connman Error wifi: Operation not permitted [HELP please]
(Daniel Wagner)
8. Re: Prevent scanning on tethering interface (Daniel Wagner)
9. Re: [PATCH] service: Add EnableOnlineCheck config option
(Daniel Wagner)
----------------------------------------------------------------------
Message: 1
Date: Sun, 12 Mar 2017 20:13:40 +0100
From: Daniel Wagner <[email protected]>
To: [email protected], [email protected]
Subject: Re: [PATCH] technology: Deny P2P finding if technology is
disabled
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Jose,
On 02/20/2017 11:23 AM, [email protected] wrote:
> 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.
I re-read this paragraph many times but I don't really understand what
the problem is you try to fix. From the code I can read that if the
technology type is p2p and is !enabled (== disabled) return a permission
denied... Ah, is this check added because we end up at the same D-Bus
object for both WiFi and P2P? And if WiFi is enabled but not P2P we
should just return ENOPERM? That would make sense indeed.
I wouldn't mind if you could reword your commit message a bit. It is
really hard to understand.
Thanks,
Daniel
> ---
> 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);
>
------------------------------
Message: 2
Date: Sun, 12 Mar 2017 20:21:14 +0100
From: Daniel Wagner <[email protected]>
To: Antoine Aubert <[email protected]>, 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; format=flowed
Hi Antoine,
On 02/20/2017 01:50 PM, Antoine Aubert wrote:
> 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)
I applied this patch after adding the above information to the commit
message.
Thanks,
Daniel
------------------------------
Message: 3
Date: Sun, 12 Mar 2017 20:30:47 +0100
From: Daniel Wagner <[email protected]>
To: [email protected], [email protected]
Subject: Re: [PATCH] gsupplicant: Do not modify ConfigMethods if they
are already set
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Jose,
On 02/23/2017 10:12 AM, [email protected] wrote:
> From: Jose Blanquicet <[email protected]>
>
> If ConnMan does not allow to configure the value to be set to ConfigMethods,
> then it should not modify the ones that were configured on wpa_s.
>
> With this patch ConnMan will first verify if the ConfigMethods were already
> set
> on wpa_s before setting its ones. Doing so, ConnMan will not change the
> configuration users already set at wpa_s level.
Patch applied after changing the '//' comment C99 style to old C comment
style '/* ... */'.
Thanks,
Daniel
------------------------------
Message: 4
Date: Sun, 12 Mar 2017 20:33:04 +0100
From: Daniel Wagner <[email protected]>
To: Slava Monich <[email protected]>, [email protected]
Subject: Re: [PATCH] main: Make --noplugin option repeatable
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Slava,
Patch applied.
Thanks,
Daniel
------------------------------
Message: 5
Date: Sun, 12 Mar 2017 20:44:46 +0100
From: Daniel Wagner <[email protected]>
To: Scott Valentine <[email protected]>, [email protected]
Subject: Re: [PATCH] ofono: Fix segfault during set_property
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Scott,
Only a couple of nitpicks.
On 03/06/2017 08:58 PM, Scott Valentine wrote:
> If the SIM card is ejected or the modem is reset / removed between the
> set_property call and the set_property_reply callback, connmand will generally
> abort, as the remove_all_contexts will get called, and the callback accesses a
> reference to a stale context via the property_info pointer.
>
> The following patch adds reference counting to the network_context struct to
> prevent the segfault:
Do you want to list something here? The colon indicates this :)
> diff -uNrp old/plugins/ofono.c new/plugins/ofono.c
> --- old/plugins/ofono.c 2016-04-17 21:04:30.000000000 -1000
> +++ new/plugins/ofono.c 2017-03-03 17:39:02.922101490 -1000
> @@ -143,6 +143,8 @@ struct network_context {
> struct connman_ipaddress *ipv6_address;
> char *ipv6_nameservers;
>
> + int refcount;
> +
> bool active;
> bool valid_apn; /* APN is 'valid' if length > 0 */
> };
> @@ -271,11 +273,24 @@ static struct network_context *network_c
> context->ipv6_address = NULL;
> context->ipv6_nameservers = NULL;
>
> + context->refcount = 1;
> +
> return context;
> }
>
> -static void network_context_free(struct network_context *context)
> +static void network_context_ref(struct network_context *context)
> +{
> + __sync_fetch_and_add(&context->refcount, 1);
> + DBG("refcount = %d", context->refcount);
> +}
We have a bunch of ref log in the code base and most of them use for the
DBG() something like DBG("%p ref %d", ...) I suggest you do it alike.
> +static void network_context_unref(struct network_context *context)
> {
> + DBG("refcount = %d", context->refcount);
> + if (__sync_fetch_and_sub(&context->refcount, 1) != 1)
> + return;
> +
> + DBG("free");
This one it not really necessary.
The rest of the patch looks good.
Thanks,
Daniel
------------------------------
Message: 6
Date: Sun, 12 Mar 2017 20:46:34 +0100
From: Daniel Wagner <[email protected]>
To: Patrik Flykt <[email protected]>, [email protected]
Subject: Re: [PATCH] bluetooth: Check for network in callbacks
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Patrik
On 03/09/2017 08:59 AM, Patrik Flykt wrote:
> If there is an ongoing connect or disconnect when the system is suspended,
> the Bluetooth PAN device might be gone when the system resumes. This can
> cause the network being removed before the connect or disconnect callback
> is called. As the connect or disconnect callback do not re-check for an
> existing pan->network, a crash will happen as a NULL network is accessed.
>
> Fix this by verifying that pan->network exists when the callback is called.
While I was at processing the inbox, I applied this patch as well.
Thanks,
Daniel
------------------------------
Message: 7
Date: Sun, 12 Mar 2017 20:51:50 +0100
From: Daniel Wagner <[email protected]>
To: Jared Harvey <[email protected]>, [email protected]
Subject: Re: Connman Error wifi: Operation not permitted [HELP please]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Jared,
On 03/09/2017 01:01 PM, Jared Harvey wrote:
> machinekit@beaglebone:~$ dmesg | grep 7601
> [ 1.176010] usbcore: registered new interface driver cdc_ncm
> [ 2.081250] usb 1-1: New USB device found, idVendor=148f, idProduct=7601
> [84932.378008] Modules linked in: mt7601Usta(O) omap_rng 8021q garp stp
> llc g_ether libcomposite
> [84932.378703] [<c032b6a3>] (usb_submit_urb+0x1cb/0x398) from
> [<bf86b7ab>] (BulkInCmdRspEvent+0x42/0x68 [mt7601Usta])
> [84932.379294] [<bf86b7ab>] (BulkInCmdRspEvent+0x42/0x68 [mt7601Usta])
> from [<bf86b8cd>] (RTUSBBulkCmdRspEventReceive+0x38/0x58 [mt7601Usta])
> [84932.379670] [<bf86b8cd>] (RTUSBBulkCmdRspEventReceive+0x38/0x58
> [mt7601Usta]) from [<bf84dabf>] (NICInitializeAsic+0xea/0x3c0 [mt7601Usta])
> [84932.379870] [<bf84dabf>] (NICInitializeAsic+0xea/0x3c0 [mt7601Usta])
> from [<e0d8a000>] (0xe0d8a000)
This looks like a stack trace from the kernel. And it looks like it
contains USB function. Since your device is USB based it might just be
the source of your problem. Can you look into the kernel log and see if
there is a complete stack trace?
Thanks,
Daniel
------------------------------
Message: 8
Date: Sun, 12 Mar 2017 20:53:53 +0100
From: Daniel Wagner <[email protected]>
To: Jose Blanquicet <[email protected]>, [email protected]
Subject: Re: Prevent scanning on tethering interface
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Jose,
I added Tomasz to CC list. He might have some input on this topic.
Thanks,
Daniel
On 03/09/2017 01:55 PM, Jose Blanquicet wrote:
> Hi,
>
> The first issue takes place when user asks for a Scan on P2P technology
> and Tethering is enabled for WiFi technology, ConnMan will reply with a
> success to the request even if the P2P find does not actually started.
> The second issue occurs when user asks for a Scan on WiFi technology and
> WiFi tethering is enabled, in such case, ConnMan will never emit the
> reply and client (e.g. connmanctl) will go in D-Bus time-out.
>
> I investigated first case and I saw that ConnMan's scan algorithm
> replies "success" to the request because ConnMan successfully makes the
> D-Bus call P2PDevice.Find() to ask wpa_supplicant to launch the P2P find
> even if wpa_supplicant will reply ?ScanError?.
>
> I suggest to check tethering state before calling P2PDevice.Find() as is
> done for Scan() to solve first issue and return -EBUSY instead of zero
> ("success") if tethering is enabled to solve the second issue, see an
> initial idea bellow. Doing so, ConnMan will save one useless D-Bus call
> toward wpa_s and will be able to correctly reply "Error" to the scan
> requests while tethering. We tested this in our systems and it seems to
> work but I was wondering if this solution could have problem in systems
> with other characteristics of WiFi interfaces/capabilities. What do
> people think?
>
> diff --git a/plugins/wifi.c b/plugins/wifi.c
> index f8d88fa..a49031c 100644
> --- a/plugins/wifi.c
> +++ b/plugins/wifi.c
> @@ -1802,14 +1802,14 @@ static int wifi_scan(enum connman_service_type type,
> if (wifi->p2p_device)
> return 0;
>
> + if (wifi->tethering)
> + return -EBUSY;
> +
> if (type == CONNMAN_SERVICE_TYPE_P2P)
> return p2p_find(device);
>
> DBG("device %p wifi %p hidden ssid %s", device, wifi->interface,
> ssid);
>
> - if (wifi->tethering)
> - return 0;
> -
> scanning = connman_device_get_scanning(device);
>
> if (!ssid || ssid_len == 0 || ssid_len > 32) {
>
>
> Regards,
>
> Jose Blanquicet
>
>
> _______________________________________________
> connman mailing list
> [email protected]
> https://lists.01.org/mailman/listinfo/connman
>
------------------------------
Message: 9
Date: Sun, 12 Mar 2017 20:56:12 +0100
From: Daniel Wagner <[email protected]>
To: Patrik Flykt <[email protected]>, Lukasz Nowak
<[email protected]>, [email protected]
Subject: Re: [PATCH] service: Add EnableOnlineCheck config option
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi,
On 03/09/2017 12:00 PM, Patrik Flykt wrote:
> On Thu, 2017-03-09 at 09:45 +0000, Lukasz Nowak wrote:
>> On 09/03/17 07:57, Patrik Flykt wrote:
>>> On Wed, 2017-03-08 at 17:37 +0000, Lukasz Nowak wrote:
>>>> From: Lukasz Nowak <[email protected]>
>>>>
>>>> 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.
>>>
>>> Why do we want such a feature? You can compile ConnMan with --
>>> disable-
>>> wispr if you don't want the functionality.
>>
>> I suppose that's what I get for taking a month to submit the patch...
>> https://lists.01.org/pipermail/connman/2017-February/021565.html
>>
>> and a decision to put it into the runtime config:
>> https://lists.01.org/pipermail/connman/2017-February/021603.html
>>
>> Short summary:
>> --disable-wispr does not disable the online check, which appears to
>> be
>> a problem for many people, who cannot have a dependency on a 3rd
>> party
>> web server for commercial deployments.
>
> Ok, I have been memory erased meanwhile. Need to check the other link
> as well, the first one ended a bit inconclusive.
>
> And true, --disable-wispr does not deliver here.
BTW, I had a chance to discuss this with Marcel in person during ELC.
And he was not against this. The only thing he would like to see that we
always log that we didn't do the online check.
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 17, Issue 8
**************************************
