We are using NetworkManager 0.8.6 on a device without the official NM applet, so we do all communication with NM over DBus ourselves. If there is no entry in the system-connections directory *and* no "no-auto-default" entry in NetworkManager.conf, then NetworkManager doesn't reply to the method call org.freedesktop.NetworkManager.ActivateConnection. NM *does* receive the method call and does apply the configuration, but simply doesn't reply; the caller eventually gets a DBus timeout. After this first call (which times out), NM has created its configuration file in system-connections, and the next call works correctly. I can consistently reproduce this behaviour by: * killing NM, * removing any "no-auto-default" entry in NetworkManager.conf, * removing everything in the system-connections directory; then * starting NM * and sending NM a series of method calls culminating in ActivateConnection. Logs: 1. dbus-monitor.log (attached). I have pruned out the DBus administrative method calls (AddMatch, NameOwnerChanged, etc). Method calls of interest (numbers in parentheses are the serial & reply_serial numbers in the log): * We ask for the ActiveConnection (4). * We ask for the ActiveConnection's Device (6). * We ask for the ActiveConnection's Connection (8). * We ask for the Connection's settings (20). * We update the Connection's settings (21). * We call ActivateConnection to apply the new settings (22). Then we see lots of messages on DBus as NetworkManager talks with the DHCP client etc... but no reply for ActivateConnection (22). 2. NetworkManager.log (attached). Contains output to the terminal from running: NetworkManager --log-level=DEBUG --no-daemon & and begins from the moment we begin sending the DBus messages, i.e. the same time as the top of dbus-monitor.log. 3. NetworkManager.conf: [main] plugins=ifupdown,keyfile [ifupdown] managed=true Are we missing something from the DBus messages we are sending? Or is it a bug in NetworkManager? (Our DBus messages work correctly for every subsequent call). Any ideas on where we could look in the source code? Attaching a debugger hasn't been fruitful, because NM isn't *hanging*... it will still process other requests. We thought we might work around this problem by creating the file "system-connections/Auto eth0" manually, but the same problem happens; and after the call (which times out) the "uuid" value in the file's "[connection]" section has changed value. Presumably NM doesn't recognise the uuid we gave it when we created the "Auto eth0" file ourselves. Does NM store this uuid value somewhere else? Is the "timestamp" value in the same file significant? Thanks, David Röthlisberger.
Attachment:
dbus-monitor.log
Description: Binary data
Attachment:
NetworkManager.log
Description: Binary data