After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 565008 - unrequested reply sent from nm-system-settings
unrequested reply sent from nm-system-settings
Product: NetworkManager
Classification: Platform
Component: general
Other Linux
: Normal normal
: ---
Assigned To: Dan Williams
Dan Williams
Depends on:
Reported: 2008-12-18 15:45 UTC by Colin Walters
Modified: 2010-12-17 05:03 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Colin Walters 2008-12-18 15:45:00 UTC
Getting these denials on system startup:

Dec 18 10:28:50 space-ghost dbus: Rejected send message, 1 matched rules; type="method_return", sender=":1.15" (uid=0 pid=2575 comm="/usr/sbin/nm-system-settings -
-config /etc/Network") interface="(unset)" member="(unset)" error name="(unset)" requested_reply=0 destination=":1.14" (uid=0 pid=2531 comm="NetworkManager --pid-f

There is also one from wpa-supplicant:

Dec 18 10:28:48 space-ghost dbus: Rejected send message, 1 matched rules; type="error", sender=":1.16" (uid=0 pid=2573 comm="/usr/sbin/wpa_supplicant -c /etc/wpa_s
upplicant/wp") interface="(unset)" member="(unset)" error name="fi.epitest.hostap.WPASupplicant.InvalidInterface" requested_reply=0 destination=":1.14" (uid=0 pid=
2531 comm="NetworkManager --pid-file=/var/run/NetworkManager/"))

My current theory is that these are actually duplicate replies, and thus the second one becomes unrequested.
Comment 1 Colin Walters 2009-01-07 02:02:18 UTC
Looked at this first one:

Jan  5 11:35:04 space-ghost dbus: Rejected send message, 1 matched rules; type="method_return", sender=":1.114" (uid=0 pid=13769 comm="/usr/libexec/nm-dispatcher.action ") interface="(un
set)" member="(unset)" error name="(unset)" requested_reply=0 destination=":1.14" (uid=0 pid=2596 comm="NetworkManager --pid-file=/var/run/NetworkManager/"))

The cause here is pretty simple I think.  In src/NetworkManagerUtils.c:nm_call_utils_dispatcher, we do dbus_g_proxy_call_no_reply.  But the glib bindings used for the dispatcher are going to send a reply regardless.

A possible fix is to change the invocation to use dbus_g_proxy_begin_call with a NULL notify.

We should probably warn in the API docs for dbus_g_proxy_call_no_reply that it should only be used for methods which actually send no reply.
Comment 2 Colin Walters 2009-01-07 18:31:59 UTC
The dispatcher and system settings ones are a dbus-glib bug, patch here:

That still leaves the supplicant error.  Looking at that now.
Comment 3 Colin Walters 2009-01-07 18:38:25 UTC
Ah, easy enough.  In src/supplicant-manager/nm-supplicant-manager.c:poke_supplicant_cb, we do 

dbus_g_proxy_call_no_reply (proxy, "getInterface", G_TYPE_STRING, "ignoreme", G_TYPE_INVALID);

This is pretty ugly.  Maybe we can use the org.freedesktop.DBus.Peer.Ping method?
Comment 4 Colin Walters 2009-02-25 18:16:43 UTC
This one is worked around in wpa_supplicant for now by not sending a reply in this case, but I think we should do the right thing here in NM and use the StartServiceByName bus method.
Comment 5 Dan Williams 2010-02-01 21:50:33 UTC
We'll be fixing the dispatcher one by actually caring about the return value for the dispatcher method soon.
Comment 6 Dan Williams 2010-12-17 05:03:07 UTC
The supplicant issue is no longer the case in master, that code has been rewritten.