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] doc: add --nobacktrace option to connman.8 manpage
(Alexander Sack)
2. [PATCH] gsupplicant: Ensure callback is called after
disconnection in WPS use cases (Jose Blanquicet)
3. Re: [PATCH] gsupplicant: Ensure callback is called after
disconnection in WPS use cases (Tomasz Bursztyka)
4. Re: [PATCH] timezone: Add support for setting timezone using
timedated (Slava Monich)
5. Connman spinning (Frederic Dalleau)
6. dnsproxy feature doesn't resolve for local domain (Leo Mar)
7. Re: Connman spinning (Patrik Flykt)
8. Re: [PATCH] doc: add --nobacktrace option to connman.8
manpage (Patrik Flykt)
9. Re: [PATCH] gsupplicant: Ensure callback is called after
disconnection in WPS use cases (Patrik Flykt)
----------------------------------------------------------------------
Message: 1
Date: Wed, 7 Sep 2016 23:16:49 +0200
From: Alexander Sack <[email protected]>
To: [email protected]
Subject: [PATCH] doc: add --nobacktrace option to connman.8 manpage
Message-ID: <[email protected]>
---
doc/connman.8.in | 3 +++
1 file changed, 3 insertions(+)
diff --git a/doc/connman.8.in b/doc/connman.8.in
index 9b71779..ddfba09 100644
--- a/doc/connman.8.in
+++ b/doc/connman.8.in
@@ -80,6 +80,9 @@ Never load these plugins. The option can be a pattern
containing
Wifi driver that WiFi/Supplicant should use. If this flag is omitted,
then the value "nl80211,wext" is used by default.
.TP
+.BR \-n ", " \-\-nobacktrace
+Don't print out backtrace information.
+.TP
.BR \-n ", " \-\-nodaemon
Do not daemonize. This is useful for debugging, and directs log output to
the controlling terminal in addition to syslog.
--
2.9.3
------------------------------
Message: 2
Date: Thu, 8 Sep 2016 11:27:24 +0200
From: Jose Blanquicet <[email protected]>
To: [email protected]
Subject: [PATCH] gsupplicant: Ensure callback is called after
disconnection in WPS use cases
Message-ID: <[email protected]>
In 7784ca7234be2b854f298f4e150ecaa5212c0301 was added a patch to not perform
"RemoveNetwork" in interface_disconnect_result() for WPS use cases because
"AddNetwork" is not done in these cases. However, the disconnection callback is
not called when there was not error(result == 0). Therefore, flags are not clean
and feature initially introduced in 43e6e141ee352e77fdb894b918f280024785f3df to
make sure disconnection is completed before trying to connect a new network will
not work in WPS use cases.
This patch ensures disconnection callback is always called in WPS use cases.
Reported by Eunok Lee <[email protected]> while testing RFC for WPS proposal
---
gsupplicant/supplicant.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index 4cb533d..0a3815d 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -4952,20 +4952,24 @@ static void interface_disconnect_result(const char
*error,
result = -ECONNABORTED;
}
- if (result < 0 && data->callback) {
- data->callback(result, data->interface, data->user_data);
- data->callback = NULL;
- }
-
/* If we are disconnecting from previous WPS successful
* association. i.e.: it did not went through AddNetwork,
* and interface->network_path was never set. */
if (!data->interface->network_path) {
+ if (data->callback)
+ data->callback(result, data->interface,
+ data->user_data);
+
g_free(data->path);
dbus_free(data);
return;
}
+ if (result < 0 && data->callback) {
+ data->callback(result, data->interface, data->user_data);
+ data->callback = NULL;
+ }
+
if (result != -ECONNABORTED) {
if (network_remove(data) < 0) {
g_free(data->path);
--
1.9.1
------------------------------
Message: 3
Date: Thu, 8 Sep 2016 11:44:23 +0200
From: Tomasz Bursztyka <[email protected]>
To: Jose Blanquicet <[email protected]>, [email protected]
Subject: Re: [PATCH] gsupplicant: Ensure callback is called after
disconnection in WPS use cases
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Jose,
ACK from me.
Tomasz
------------------------------
Message: 4
Date: Thu, 8 Sep 2016 14:06:34 +0300
From: Slava Monich <[email protected]>
To: Philip Withnall <[email protected]>
Cc: Marcel Holtmann <[email protected]>, [email protected]
Subject: Re: [PATCH] timezone: Add support for setting timezone using
timedated
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Philip,
On 07/09/16 13:07, Philip Withnall wrote:
> Hi,
>
> On Sun, 2016-08-28 at 12:24 +0300, Slava Monich wrote:
>> ...
>> It?s more effort than I have time to put in at the moment, sorry.
>> Hardcoding D-Bus APIs is (I believe) an acceptable approach, since the D-
>> Bus API itself provides the indirection layer ? the API can be implemented
>> by any system process. The ?fallback? (/etc/localtime) should work in 90%
>> of cases at the moment (as it always has done).
>>
>> +1
>>
>> Sailfish OS is using timed which has a D-Bus API of its own.
> Unless I?ve misunderstood, Sailfish also uses systemd extensively ? why not
> use systemd-timedated?
Partly it's Meego legacy. Also I think systemd wasn't used by Sailfish
at the beginning, it appeared later in the game. Most importantly for a
mobile phone, timed is integrated with ofono, it can deduce current time
zone based on the network registration and handles NITZ updates from the
operator. On top of that, it maintains all kinds of alarms, e.g.
calendar and clock.
In any case, even if systemd-timedated can do all that too, it's too
much of an effort to take it out at this point.
Cheers,
-Slava
------------------------------
Message: 5
Date: Thu, 8 Sep 2016 13:43:27 +0200
From: Frederic Dalleau <[email protected]>
To: [email protected]
Subject: Connman spinning
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hello,
I am using connman to setup some bluetooth pan connections.
Sometimes things don't do well, it can be disconnected, or the
connection may not be setup, or setup and immediately disconnected.
I ran several times into the problem that connmand starts to spin as
follow :
plugins/bluetooth.c:bluetooth_pan_disconnect() network 0xfb8510
plugins/bluetooth.c:pan_disconnect_cb() network 0xfb8510
org.bluez.Error.NotConnected
plugins/bluetooth.c:pan_disconnect_cb() network 0xfb8510
src/network.c:connman_network_set_connected() network 0xfb8510 connected
0/0 connecting 0 associating 1
src/network.c:connman_network_set_error() network 0xfb8510 error 4
src/service.c:__connman_service_indicate_error() service 0xfb88e0 error 4
src/network.c:__connman_network_disconnect() network 0xfb8510
plugins/bluetooth.c:bluetooth_pan_disconnect() network 0xfb8510
plugins/bluetooth.c:pan_disconnect_cb() network 0xfb8510
org.bluez.Error.NotConnected
plugins/bluetooth.c:pan_disconnect_cb() network 0xfb8510
src/network.c:connman_network_set_connected() network 0xfb8510 connected
0/0 connecting 0 associating 1
src/network.c:connman_network_set_error() network 0xfb8510 error 4
src/service.c:__connman_service_indicate_error() service 0xfb88e0 error 4
src/network.c:__connman_network_disconnect() network 0xfb8510
plugins/bluetooth.c:bluetooth_pan_disconnect() network 0xfb8510
plugins/bluetooth.c:pan_disconnect_cb() network 0xfb8510
org.bluez.Error.NotConnected
And so on, and so forth... Has anyone seen that? or better, does
somebody already have the patch :) in which case i'd be happy to test,
or just a hint about what fix should be needed.
Thanks,
Fred
------------------------------
Message: 6
Date: Thu, 8 Sep 2016 17:30:53 +0530
From: Leo Mar <[email protected]>
To: [email protected]
Subject: dnsproxy feature doesn't resolve for local domain
Message-ID:
<CAGoKKOFVrdip8yFw=v8hm86fx65anj3kxft_wrjs9sc8hrm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi All,
I would like to know whether "search domain option" is being handled from
connman's internal dns proxy?
As connman by default runs with dnsproxy enabled, /etc/resolv.conf entries
will be like below
# Generated by Connection Manager
nameserver 127.0.0.1
nameserver ::1
So even domain names got from DHCP server is not added in /etc/resolv.conf.
But this domain name can be seen in service configuration settings from
list-services which connman handled internally
Timeservers.Configuration = [ ]
Domains = [ mydomain.example ]
Domains.Configuration = [ ]
When we try to ping to subdomains in local network, It will not work as
expected like for example if we have a server "mydomain.example" at
192.168.1.10 with a subdomain "myhost.mydomain.example". It is expected to
"ping myhost" to send it's packages to 192.168.1.10 which is not happening
in connman. if connman is started with -r option (disable dnsproxy) "ping
myhost" is working properly.
I have tried using connman 1.25 and now with 1.33 also same behavior.
Can someone help me in explaining is it the expected behavior or an issue
in connman dnsproxy handling?
Regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20160908/c019a3b2/attachment-0001.html>
------------------------------
Message: 7
Date: Thu, 08 Sep 2016 15:07:36 +0300
From: Patrik Flykt <[email protected]>
To: Frederic Dalleau <[email protected]>,
[email protected]
Subject: Re: Connman spinning
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Thu, 2016-09-08 at 13:43 +0200, Frederic Dalleau wrote:
> Hello,
>
> I am using connman to setup some bluetooth pan connections.
> Sometimes things don't do well, it can be disconnected, or the?
> connection may not be setup, or setup and immediately disconnected.
> I ran several times into the problem that connmand starts to spin as?
> follow :
>
> plugins/bluetooth.c:bluetooth_pan_disconnect() network 0xfb8510
> plugins/bluetooth.c:pan_disconnect_cb() network 0xfb8510?
> org.bluez.Error.NotConnected
> plugins/bluetooth.c:pan_disconnect_cb() network 0xfb8510
> src/network.c:connman_network_set_connected() network 0xfb8510
> connected?
> 0/0 connecting 0 associating 1
> src/network.c:connman_network_set_error() network 0xfb8510 error 4
> src/service.c:__connman_service_indicate_error() service 0xfb88e0
> error 4
> src/network.c:__connman_network_disconnect() network 0xfb8510
> plugins/bluetooth.c:bluetooth_pan_disconnect() network 0xfb8510
> plugins/bluetooth.c:pan_disconnect_cb() network 0xfb8510?
> org.bluez.Error.NotConnected
> plugins/bluetooth.c:pan_disconnect_cb() network 0xfb8510
> src/network.c:connman_network_set_connected() network 0xfb8510
> connected?
> 0/0 connecting 0 associating 1
> src/network.c:connman_network_set_error() network 0xfb8510 error 4
> src/service.c:__connman_service_indicate_error() service 0xfb88e0
> error 4
> src/network.c:__connman_network_disconnect() network 0xfb8510
> plugins/bluetooth.c:bluetooth_pan_disconnect() network 0xfb8510
> plugins/bluetooth.c:pan_disconnect_cb() network 0xfb8510?
> org.bluez.Error.NotConnected
>
> And so on, and so forth...??Has anyone seen that? or better, does?
> somebody already have the patch :) in which case i'd be happy to
> test, or just a hint about what fix should be needed.
Haven't see this one before. I assume you are using a recent version of
ConnMan?
Cheers,
Patrik
------------------------------
Message: 8
Date: Thu, 08 Sep 2016 15:20:35 +0300
From: Patrik Flykt <[email protected]>
To: Alexander Sack <[email protected]>, [email protected]
Subject: Re: [PATCH] doc: add --nobacktrace option to connman.8
manpage
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Wed, 2016-09-07 at 23:16 +0200, Alexander Sack wrote:
> ---
> ?doc/connman.8.in | 3 +++
> ?1 file changed, 3 insertions(+)
Applied, thanks!
Patrik
------------------------------
Message: 9
Date: Thu, 08 Sep 2016 15:20:53 +0300
From: Patrik Flykt <[email protected]>
To: Jose Blanquicet <[email protected]>, [email protected]
Subject: Re: [PATCH] gsupplicant: Ensure callback is called after
disconnection in WPS use cases
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Thu, 2016-09-08 at 11:27 +0200, Jose Blanquicet wrote:
> In 7784ca7234be2b854f298f4e150ecaa5212c0301 was added a patch to not
> perform
> "RemoveNetwork" in interface_disconnect_result() for WPS use cases
> because
> "AddNetwork" is not done in these cases. However, the disconnection
> callback is
> not called when there was not error(result == 0). Therefore, flags
> are not clean
> and feature initially introduced in
> 43e6e141ee352e77fdb894b918f280024785f3df to
> make sure disconnection is completed before trying to connect a new
> network will
> not work in WPS use cases.
>
> This patch ensures disconnection callback is always called in WPS use
> cases.
>
> Reported by Eunok Lee <[email protected]> while testing RFC for WPS
> proposal
Applied, thanks!
Patrik
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 11, Issue 8
**************************************
