Hi, On 04/25/2018 11:31 AM, Thomas Achleitner wrote: Okay, I think I also pointed you in the wrong direction. I looked again on the log files a bit closer. I am not sure anymore if the interaction between ConnMan and the VPN daemon is right. It looks like the first attempt leads to the situation that a service is created but not configured. The second attempt gives ConnMan the missing information to create the service. So this is the current theorie. Can you try to log the interaction between the two daemons? Just let monitor-connman and monitor-vpn run. Best with some timestamps added, though you need to add a sys.stdout.flush() after the print in monitor-connman and the same thing for monitor-vpn. diff --git a/test/monitor-connman b/test/monitor-connman index 1b3b84c74970..b51cc88b3f3a 100755 --- a/test/monitor-connman +++ b/test/monitor-connman @@ -2,6 +2,7 @@ import gobject +import sys import dbus import dbus.mainloop.glib @@ -55,6 +56,7 @@ from dbus.lowlevel import MethodCallMessage, HANDLER_RESULT_NOT_YET_HANDLED val = extract(name, value) print "{%s} [%s] %s = %s" % (iface, path, name, val) + sys.stdout.flush() def message_filter(connection, message): if not isinstance(message, MethodCallMessage): monitor-connman | ts '[%H:%M:%.S]' | tee connman.log Thanks, Daniel