Hi,
On 04/25/2018 11:31 AM, Thomas Achleitner wrote:
i looked into it with one of our c programmers but unfortunately we
couldn't find out why this happens...
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