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] wifi: Don't perform handle_wps_completion() when
p2p is connecting (Daniel Wagner)
2. Re: race between __connman_service_connect and
config_notify_handler (Daniel Wagner)
3. [PATCH] peer: Do not notify state changes when peer is not
registered yet (Daniel Wagner)
4. Re: issue when resolving NTP servers (Daniel Wagner)
5. Re: race between __connman_service_connect and
config_notify_handler (Vasyl Vavrychuk)
6. Re: [PATCH] peer: Do not notify state changes when peer is
not registered yet (Vasyl Vavrychuk)
----------------------------------------------------------------------
Message: 1
Date: Wed, 6 Dec 2017 21:47:03 +0100
From: Daniel Wagner <[email protected]>
To: [email protected], Jose Blanquicet <[email protected]>
Cc: Saurav Babu <[email protected]>, [email protected]
Subject: Re: [PATCH] wifi: Don't perform handle_wps_completion() when
p2p is connecting
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Jose,
On 12/01/2017 07:31 AM, Saurav Babu wrote:
> Hello Jose,
> Sorry for the late reply.
>
>> Digging into this issue I reached the conclusion that when P2P is
>> connecting, we actually do not need to handle interface state changes
>> G_SUPPLICANT_STATE_*. Instead, the connection success is completely
>> based on the peer state CONNMAN_PEER_STATE_*.
>
>> Therefore, we should ignore all the interface state changes during the
>> P2P connection, otherwise it could result in an inconsistency. In
>> fact, I tested your patch and it solves the connection problem but at
>> the end of the connection the service belonging to the just created
>> P2P group, goes in "association" state and we do not want this.
Could you add your excellent analysis to commit message and resend the
patch with it?
Thanks,
Daniel
------------------------------
Message: 2
Date: Wed, 6 Dec 2017 22:12:31 +0100
From: Daniel Wagner <[email protected]>
To: Vasyl Vavrychuk <[email protected]>
Cc: [email protected]
Subject: Re: race between __connman_service_connect and
config_notify_handler
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Vasyl,
On 12/06/2017 06:20 AM, Vasyl Vavrychuk wrote:
> Hi, Daniel,
>
> I found an attempt to implement EAP parameters via D-Bus api
> https://lists.01.org/pipermail/connman/2010-August/002420.html.
Thanks for digging up this patch. I could remember there was a proposal
but didn't find it. Anyway, as Marcel suggest, it would be better to
have an upload config file D-Bus API instead of the proposed API.
> Could you merge proposed patch to resolve my issue or this patch should
> be reworked according to some way suggested in mailing list?
I was trying to come up with an proposal for an API right now. But I
don't this would be a good idea to do this:
Manager:
void LoadProvisioning(object service, string provisioning)
Upload a provisioning for given service.
Some more pondering is needed :)
Thanks,
Daniel
------------------------------
Message: 3
Date: Wed, 6 Dec 2017 22:39:11 +0100
From: Daniel Wagner <[email protected]>
To: [email protected]
Cc: [email protected], Daniel Wagner <[email protected]>
Subject: [PATCH] peer: Do not notify state changes when peer is not
registered yet
Message-ID: <[email protected]>
ConnMan crashes when turn off Wi-Fi during P2P connection
establishing:
g_str_hash (v=0x0) at
/usr/src/debug/glib-2.0/1_2.50.3-r0/glib-2.50.3/glib/ghash.c:1876
1876 for (p = v; *p != '\0'; p++)
(gdb) bt
#0 g_str_hash (v=0x0) at
/usr/src/debug/glib-2.0/1_2.50.3-r0/glib-2.50.3/glib/ghash.c:1876
#1 0xb6f026a0 in g_hash_table_lookup_node (hash_return=<synthetic
pointer>, key=0x0, hash_table=0xe0288) at
/usr/src/debug/glib-2.0/1_2.50.3-r0/glib-2.50.3/glib/ghash.c:375
#2 g_hash_table_lookup_extended (hash_table=0xe0288, lookup_key=0x0,
orig_key=orig_key@entry=0x0, value=0xe2680, value@entry=0x0) at
/usr/src/debug/glib-2.0/1_2.50.3-r0/glib-2.50.3/glib/ghash.c:1184
#3 0x0008e378 in allow_property_changed (peer=0xe3fe0) at
/usr/src/debug/connman/1.35-r1/connman-1.35/src/peer.c:275
#4 state_changed (peer=0xe3fe0) at
/usr/src/debug/connman/1.35-r1/connman-1.35/src/peer.c:429
#5 connman_peer_set_state (peer=peer@entry=0xe3fe0,
new_state=new_state@entry=CONNMAN_PEER_STATE_DISCONNECT) at
/usr/src/debug/connman/1.35-r1/connman-1.35/src/peer.c:930
#6 0x0008e7c4 in peer_disconnect (peer=peer@entry=0xe3fe0) at
/usr/src/debug/connman/1.35-r1/connman-1.35/src/peer.c:633
#7 0x0008e85c in report_error_cb (user_context=0xe3fe0, retry=<optimized
out>, user_data=<optimized out>) at
/usr/src/debug/connman/1.35-r1/connman-1.35/src/peer.c:852
#8 0x00060ea8 in report_error_reply (reply=0x1015c8, user_data=0xd12c8) at
/usr/src/debug/connman/1.35-r1/connman-1.35/src/agent.c:369
#9 0x00060fc4 in agent_finalize_pending (reply=reply@entry=0x1015c8,
agent=<optimized out>) at
/usr/src/debug/connman/1.35-r1/connman-1.35/src/agent.c:121
#10 0x00061120 in agent_receive_message (call=0xfb9e0, user_data=0xfc4f0)
at /usr/src/debug/connman/1.35-r1/connman-1.35/src/agent.c:208
#11 0xb6e8d8bc in ?? () from /usr/lib/libdbus-1.so.3
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
Reported-by: Vasyl Vavrychuk <[email protected]>
---
Hi,
I think there are more ways where we end up trying to lookup up a NULL
key. Maybe we should just do a NULL check on default. What do you think?
Thanks,
Daniel
src/peer.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/peer.c b/src/peer.c
index 1b9b80e37169..05bc9929cce0 100644
--- a/src/peer.c
+++ b/src/peer.c
@@ -381,7 +381,7 @@ static void append_properties(DBusMessageIter *iter, struct
connman_peer *peer)
static void settings_changed(struct connman_peer *peer)
{
- if (!allow_property_changed(peer))
+ if (!peer->path || !allow_property_changed(peer))
return;
connman_dbus_property_changed_dict(peer->path,
@@ -426,7 +426,7 @@ static void state_changed(struct connman_peer *peer)
const char *state;
state = state2string(peer->state);
- if (!state || !allow_property_changed(peer))
+ if (!state || !peer->path || !allow_property_changed(peer))
return;
connman_dbus_property_changed_basic(peer->path,
@@ -964,7 +964,7 @@ void connman_peer_reset_services(struct connman_peer *peer)
void connman_peer_services_changed(struct connman_peer *peer)
{
- if (!peer || !peer->registered || !allow_property_changed(peer))
+ if (!peer || !peer->path || !peer->registered ||
!allow_property_changed(peer))
return;
connman_dbus_property_changed_array(peer->path,
--
2.14.3
------------------------------
Message: 4
Date: Wed, 6 Dec 2017 22:47:42 +0100
From: Daniel Wagner <[email protected]>
To: "l.genevet" <[email protected]>, [email protected]
Subject: Re: issue when resolving NTP servers
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Lidwine,
On 12/01/2017 05:27 PM, l.genevet wrote:
> Hi,
>
> We have an issue regarding the use of the NTP to get time from our servers.
>
> Indeed, when the route is updated between a ntp resolving, seems return
> G_RESOLV_RESULT_STATUS_SUCCESS, but without any NAME in results.
>
> In this case, it looks like we do not try the other possible servers in
> the time servers list.
>
> 2017-11-02 18:06:21.200 [Repeated x2]
> ../git/src/ntp.c:__connman_ntp_stop()
> 2017-11-02 18:06:21.200
> ../git/src/timeserver.c:__connman_timeserver_sync_next()
> 2017-11-02 18:06:21.200 eth0 {add} route 192.168.1.0 gw 0.0.0.0 scope
> 253 <LINK>
> 2017-11-02 18:06:21.200 eth0 {add} route 192.168.1.1 gw 0.0.0.0 scope
> 253 <LINK>
> 2017-11-02 18:06:21.200 eth0 {add} route 0.0.0.0 gw 192.168.1.1 scope
> 0 <UNIVERSE>
> 2017-11-02 18:06:21.200 eth0 {add} route 169.254.0.0 gw 0.0.0.0 scope
> 253 <LINK>
> 2017-11-02 18:06:26.392 ../git/src/timeserver.c:resolv_result() status 0
> 2017-11-02 18:06:26.392 ../git/src/timeserver.c:resolv_result() Using
> timeserver (null)
> 2017-11-02 18:06:26.392 ../git/src/ntp.c:__connman_ntp_start() (null)
>
>
> A simple check would be to check null value, but the issue could be in
> g_resolv_lookup_hostname.
> Any ideas ?
Hmm, not really. I am working on fixing a the retry issue with NTP.
Since this sounds like a race issue I am even more convinced to
restructure the NTP code slightly. Currently we have global variables
and the whole code expects a nice linear state changes. That worked
pretty well but now it seems we need to make the code a bit more robust
with regard state changes etc. So my plan is to move the global vars
into a data structure and attach the data to the current state. We do
that in the rest of the code base and it seems to work pretty good. In
short, just say no to global state variables.
Hopefully I find some time to work on it. Currently, I am not finding
enough spare cycles to do real work on ConnMan. So if you want to work
on this I can send you my current hack.
Thanks,
Daniel
------------------------------
Message: 5
Date: Thu, 7 Dec 2017 00:07:57 +0200
From: Vasyl Vavrychuk <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Subject: Re: race between __connman_service_connect and
config_notify_handler
Message-ID:
<CAGj4m+4qKHn8RhGkRK3dyJngbRHXn4w0DoQAYdb8irJqMKFo=w...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi, Daniel,
Thanks for feedback. Please find my comment below.
On Wed, Dec 6, 2017 at 11:12 PM, Daniel Wagner <[email protected]> wrote:
>
> Manager:
>
> void LoadProvisioning(object service, string provisioning)
> Upload a provisioning for given service.
>
I think that besides setting this parameters to connman, we should provide
possibility to get this parameter from connman. It is because user may want
to find out what is current settings.
How about just to have in service api property
string Provisioning.
which is in XML (or maybe JSON) format. This is very simple rework of what
Lucio implemented and looks like it suits requirements of Marcel.
Kind regards,
Vasyl
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20171207/81f7981b/attachment-0001.html>
------------------------------
Message: 6
Date: Thu, 7 Dec 2017 01:38:56 +0200
From: Vasyl Vavrychuk <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] peer: Do not notify state changes when peer is
not registered yet
Message-ID:
<CAGj4m+4siU+WurTY6VUzD5Zo4QWv4foxa7bWW4P=eqexdfo...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Since peer->path is putted to NULL only in peer_free, this seems to be
dangling pointer (connman_peer *peer) situation. Therefore checking for
peer->path is not enough.
I am not sure what is better solution to deal with it:
1. Add connman_peer_ref to manage_peer_error and connman_peer_unref
to report_error_cb.
2. Add to peer_free code that looks into agent's pending and queue fields
and finds connman_agent_request associated with removed peer and cancels
either request or processing of its response.
3. As a user_context pass to connman_agent_report_error_full method peer ID
instead of pointer to peer and in report_error_cb_t lookup peer by this ID.
Could you please suggest what is better option.
On Wed, Dec 6, 2017 at 11:39 PM, Daniel Wagner <[email protected]> wrote:
> ConnMan crashes when turn off Wi-Fi during P2P connection
> establishing:
>
> g_str_hash (v=0x0) at /usr/src/debug/glib-2.0/1_2.
> 50.3-r0/glib-2.50.3/glib/ghash.c:1876
> 1876 for (p = v; *p != '\0'; p++)
> (gdb) bt
> #0 g_str_hash (v=0x0) at /usr/src/debug/glib-2.0/1_2.
> 50.3-r0/glib-2.50.3/glib/ghash.c:1876
> #1 0xb6f026a0 in g_hash_table_lookup_node (hash_return=<synthetic
> pointer>, key=0x0, hash_table=0xe0288) at /usr/src/debug/glib-2.0/1_2.
> 50.3-r0/glib-2.50.3/glib/ghash.c:375
> #2 g_hash_table_lookup_extended (hash_table=0xe0288, lookup_key=0x0,
> orig_key=orig_key@entry=0x0, value=0xe2680, value@entry=0x0) at
> /usr/src/debug/glib-2.0/1_2.50.3-r0/glib-2.50.3/glib/ghash.c:1184
> #3 0x0008e378 in allow_property_changed (peer=0xe3fe0) at
> /usr/src/debug/connman/1.35-r1/connman-1.35/src/peer.c:275
> #4 state_changed (peer=0xe3fe0) at /usr/src/debug/connman/1.35-
> r1/connman-1.35/src/peer.c:429
> #5 connman_peer_set_state (peer=peer@entry=0xe3fe0,
> new_state=new_state@entry=CONNMAN_PEER_STATE_DISCONNECT) at
> /usr/src/debug/connman/1.35-r1/connman-1.35/src/peer.c:930
> #6 0x0008e7c4 in peer_disconnect (peer=peer@entry=0xe3fe0) at
> /usr/src/debug/connman/1.35-r1/connman-1.35/src/peer.c:633
> #7 0x0008e85c in report_error_cb (user_context=0xe3fe0,
> retry=<optimized out>, user_data=<optimized out>) at
> /usr/src/debug/connman/1.35-r1/connman-1.35/src/peer.c:852
> #8 0x00060ea8 in report_error_reply (reply=0x1015c8,
> user_data=0xd12c8) at /usr/src/debug/connman/1.35-
> r1/connman-1.35/src/agent.c:369
> #9 0x00060fc4 in agent_finalize_pending (reply=reply@entry=0x1015c8,
> agent=<optimized out>) at /usr/src/debug/connman/1.35-
> r1/connman-1.35/src/agent.c:121
> #10 0x00061120 in agent_receive_message (call=0xfb9e0,
> user_data=0xfc4f0) at /usr/src/debug/connman/1.35-
> r1/connman-1.35/src/agent.c:208
> #11 0xb6e8d8bc in ?? () from /usr/lib/libdbus-1.so.3
> Backtrace stopped: previous frame identical to this frame (corrupt
> stack?)
> (gdb)
>
> Reported-by: Vasyl Vavrychuk <[email protected]>
> ---
>
> Hi,
>
> I think there are more ways where we end up trying to lookup up a NULL
> key. Maybe we should just do a NULL check on default. What do you think?
>
> Thanks,
> Daniel
>
> src/peer.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/peer.c b/src/peer.c
> index 1b9b80e37169..05bc9929cce0 100644
> --- a/src/peer.c
> +++ b/src/peer.c
> @@ -381,7 +381,7 @@ static void append_properties(DBusMessageIter *iter,
> struct connman_peer *peer)
>
> static void settings_changed(struct connman_peer *peer)
> {
> - if (!allow_property_changed(peer))
> + if (!peer->path || !allow_property_changed(peer))
> return;
>
> connman_dbus_property_changed_dict(peer->path,
> @@ -426,7 +426,7 @@ static void state_changed(struct connman_peer *peer)
> const char *state;
>
> state = state2string(peer->state);
> - if (!state || !allow_property_changed(peer))
> + if (!state || !peer->path || !allow_property_changed(peer))
> return;
>
> connman_dbus_property_changed_basic(peer->path,
> @@ -964,7 +964,7 @@ void connman_peer_reset_services(struct connman_peer
> *peer)
>
> void connman_peer_services_changed(struct connman_peer *peer)
> {
> - if (!peer || !peer->registered || !allow_property_changed(peer))
> + if (!peer || !peer->path || !peer->registered ||
> !allow_property_changed(peer))
> return;
>
> connman_dbus_property_changed_array(peer->path,
> --
> 2.14.3
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20171207/6fc403f6/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 26, Issue 5
**************************************
