Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe 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. Race condition in iwd plugin between addition of Network and Device
objects
(Alvin Šipraga)
----------------------------------------------------------------------
Date: Wed, 10 Jun 2020 17:00:46 +0200
From: Alvin Šipraga <[email protected]>
Subject: Race condition in iwd plugin between addition of Network and
Device objects
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hello,
I am using connman 0.38 and iwd 1.7. This problem is in relation to the
iwd plugin of connman.
I have observed a race condition in the initialization of the connman
iwd plugin, where the D-Bus proxy handler object_add() gets invoked on
the net.connman.iwd.Network interface before a relevant device object
has been created through an invocation on the net.connman.iwd.Device
interface.
This is problematic because in the create_network function, it is
possible that the iwd_network object is created and added to the
networks list, but whose network member is NULL. To see how this can
happen, observe that create_network() creates an iwd_network object and
adds it to the list, but relies on add_network() to populate the
object's network member.
This is dangerous for two reasons. Firstly, I cannot see how this
network member of iwd_network can get populated later on. But secondly,
it can cause a crash as indicated in the stack trace at the end of this
mail.
I looked briefly into fixing this, but I am not familiar with the
codebase or the g_dbus API. Specifically, I could not see how I could
prioritize invocation of object_add() on Device interfaces before
handling the Network interfaces. Other quick fixes seem to be "hacks" at
best, which might lead to information loss and other weird bugs.
I am therefore posting here to ask for some guidance on how I can fix
this issue, or provide assistance if anybody has the time to fix it
themselves.
Thanks in advance.
Kind regards,
Alvin
(gdb) bt
#0 connman_network_set_connected (network=0x0, connected=false) at
../connman-1.38/src/network.c:1682
#1 0x0000aaaadb288f80 in network_property_change (proxy=<optimized out>,
name=0xaaab143bcb3c "Connected", iter=0xfffffe3d8d90,
user_data=<optimized out>)
at ../connman-1.38/plugins/iwd.c:944
#2 0x0000aaaadb2eae80 in add_property (proxy=proxy@entry=0xaaab143b9500,
name=0xaaab143bcb3c "Connected", iter=iter@entry=0xfffffe3d8e70,
send_changed=send_changed@entry=0)
at ../connman-1.38/gdbus/client.c:243
#3 0x0000aaaadb2eb09c in update_properties (send_changed=0,
iter=<optimized out>,
proxy=0xaaab143b9500) at ../connman-1.38/gdbus/client.c:275
#4 update_properties (proxy=0xaaab143b9500, iter=<optimized out>,
send_changed=0)
at ../connman-1.38/gdbus/client.c:253
#5 0x0000aaaadb2eb40c in parse_properties (iter=0xfffffe3d8f70,
interface=0xaaab143bcafc "net.connman.iwd.Network",
path=0xaaab143bcac4 "/net/connman/iwd/0/3/42454f4755455354_open",
client=0xaaab143b21d0)
at ../connman-1.38/gdbus/client.c:944
#6 parse_interfaces (client=client@entry=0xaaab143b21d0,
path=path@entry=0xaaab143bcac4
"/net/connman/iwd/0/3/42454f4755455354_open",
iter=iter@entry=0xfffffe3d90d0) at ../connman-1.38/gdbus/client.c:982
#7 0x0000aaaadb2ec954 in parse_interfaces (iter=0xfffffe3d90d0,
path=0xaaab143bcac4 "/net/connman/iwd/0/3/42454f4755455354_open",
client=0xaaab143b21d0)
at ../connman-1.38/gdbus/client.c:965
#8 parse_managed_objects (msg=0xaaab143b56d0, client=0xaaab143b21d0)
at ../connman-1.38/gdbus/client.c:1074
#9 get_managed_objects_reply (call=<optimized out>,
user_data=0xaaab143b21d0)
at ../connman-1.38/gdbus/client.c:1095
#10 0x0000ffff9dc59034 in complete_pending_call_and_unlock (
connection=connection@entry=0xaaab143a9820, pending=0xaaab143ad0f0,
message=message@entry=0xaaab143b56d0) at
../../dbus-1.12.16/dbus/dbus-connection.c:2332
#11 0x0000ffff9dc5ce4c in dbus_connection_dispatch
(connection=0xaaab143a9820)
at ../../dbus-1.12.16/dbus/dbus-connection.c:4653
#12 dbus_connection_dispatch (connection=connection@entry=0xaaab143a9820)
at ../../dbus-1.12.16/dbus/dbus-connection.c:4576
#13 0x0000aaaadb2e5f78 in message_dispatch (data=0xaaab143a9820) at
../connman-1.38/gdbus/mainloop.c:72
#14 0x0000ffff9dcf9b64 in g_main_dispatch (context=0xaaab143a8970) at
../glib-2.60.7/glib/gmain.c:3189
#15 g_main_context_dispatch (context=context@entry=0xaaab143a8970) at
../glib-2.60.7/glib/gmain.c:3854
#16 0x0000ffff9dcf9f20 in g_main_context_iterate
(context=0xaaab143a8970, block=block@entry=1,
dispatch=dispatch@entry=1, self=<optimized out>) at
../glib-2.60.7/glib/gmain.c:3927
#17 0x0000ffff9dcfa2d8 in g_main_loop_run (loop=0xaaab143a82e0) at
../glib-2.60.7/glib/gmain.c:4123
#18 0x0000aaaadb278c4c in main (argc=<optimized out>, argv=<optimized out>)
at ../connman-1.38/src/main.c:863
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- [email protected]
To unsubscribe send an email to [email protected]
------------------------------
End of connman Digest, Vol 56, Issue 2
**************************************
