Autobuilder log: Buildslave for this Build: *ab02.i.yoctoproject.org* Complete logs for all build steps: http://autobuilder.yoctoproject.org:8010/builders/nightly-mips/builds/648 Build Reason: Triggerable(nightly-mips) Build Source Stamp: *[branch master] 8609051d8d4f9fa565eb48418a87fa0048613374* /Detailed log of last build step:/ http://autobuilder.yoctoproject.org:8010/builders/nightly-mips/builds/648/steps/shell_38/logs/stdio Last 20 lines of "shell_38.stdio" Error log: | The authenticity of host '192.168.7.2 (192.168.7.2)' can't be established. | RSA key fingerprint is 64:f2:9b:ff:86:aa:02:17:e6:f8:24:7a:59:60:3f:ad. | Are you sure you want to continue connecting (yes/no)? yes | Warning: Permanently added '192.168.7.2' (RSA) to the list of known hosts. | root@192.168.7.2's password: | Test_Info: Shutdown Test PASS | NOTE: Test Result for qemumips core-image-sato | NOTE: Testcase PASS FAIL NORESULT | NOTE: SSH 1 0 0 | NOTE: SCP 1 0 0 | NOTE: dmesg 1 0 0 | NOTE: zypper_help 1 0 0 | NOTE: zypper_search 1 0 0 | NOTE: rpm_query 1 0 0 | NOTE: connman 0 1 0
I can't reproduce this locally. The connman sanity test fails if connmand doesn't exist in the `ps -ef` output . This might happen if the test is run before connmand is started.
*** Bug 3354 has been marked as a duplicate of this bug. ***
Status Check? We are still seeing failures on Connman?
It seems that there's a conflict between `avahi-daemon` and `connmand` over the ipv6 address of the network interface. Pasting relevant logs from /var/log/messages capturing backtrace of `connmand`: """ Nov 27 23:12:29 qemux86-64 user.debug kernel: eth0: no IPv6 routers present Nov 27 23:13:49 qemux86-64 daemon.err connmand[416]: connman_inet_clear_address: Invalid argument Nov 27 23:13:49 qemux86-64 daemon.err connmand[416]: connman_inet_clear_address: Invalid argument Nov 27 23:13:49 qemux86-64 daemon.err connmand[416]: connman_inet_clear_address: Invalid argument Nov 27 23:13:49 qemux86-64 daemon.err connmand[416]: connman_inet_clear_ipv6_address: Invalid argument Nov 27 23:13:49 qemux86-64 daemon.info avahi-daemon[476]: Withdrawing address record for fe80::5054:ff:fe12:3456 on eth0. Nov 27 23:13:49 qemux86-64 daemon.err connmand[416]: connman_inet_clear_address: Invalid argument Nov 27 23:13:49 qemux86-64 daemon.err connmand[416]: connman_inet_clear_ipv6_address: Invalid argument Nov 27 23:13:49 qemux86-64 daemon.err connmand[416]: Aborting (signal 11) [/usr/sbin/connmand] Nov 27 23:13:49 qemux86-64 daemon.err connmand[416]: ++++++++ backtrace ++++++++ Nov 27 23:13:49 qemux86-64 daemon.err connmand[416]: #0 0x7f5b08829b20 in /lib/libpthread.so.0 Nov 27 23:13:49 qemux86-64 daemon.err connmand[416]: #1 0x7f5b091971ae in /usr/lib/libglib-2.0.so.0 Nov 27 23:13:49 qemux86-64 daemon.err connmand[416]: #2 0x44fc02 in /usr/sbin/connmand Nov 27 23:13:49 qemux86-64 daemon.err connmand[416]: #3 0x414ed0 in /usr/sbin/connmand Nov 27 23:13:49 qemux86-64 daemon.err connmand[416]: #4 0x7f5b091794e5 in /usr/lib/libglib-2.0.so.0 Nov 27 23:13:49 qemux86-64 daemon.err connmand[416]: #5 0x7f5b09179818 in /usr/lib/libglib-2.0.so.0 Nov 27 23:13:49 qemux86-64 daemon.err connmand[416]: #6 0x7f5b09179c12 in /usr/lib/libglib-2.0.so.0 Nov 27 23:13:49 qemux86-64 daemon.err connmand[416]: #7 0x40e616 in /usr/sbin/connmand Nov 27 23:13:49 qemux86-64 daemon.err connmand[416]: #8 0x7f5b08076755 in /lib/libc.so.6 Nov 27 23:13:49 qemux86-64 daemon.err connmand[416]: +++++++++++++++++++++++++++ """
After more runs on this, i can say this is producible only on hosts with Debian. And mostly when an image is at its first boot. Assigning to Cristi, for connman update, which might fix the `connmand` crash.
Hi Mihai, What version of connman exhibits the stated behavior? Version 1.4?
(In reply to comment #6) > Hi Mihai, > > What version of connman exhibits the stated behavior? > > Version 1.4? Yes. The abort was produced on Connman version 1.4, running under QEMU on a Debian OS host.
Technical solution is found. Implementation is in the work.
Issue: connman overwrites all previous net interface settings for wired connection (eth0). Afterwards, connman tries to obtain a valid IP address via DHCP, fails, eventually settling for a Zeroconf IP address, which prevents qemu machine from getting connectivity.
Possible technical solutions according to Marcel Holtmann: Hello all; I have this situation; connman is used in a qemu machine, so no DHCP or any other autoconfiguration mechanism is present <cristianiorga> qemu linux machine (guest) starts, connman enters the scene, and it wipes the static config done for eth0 <cristianiorga> but it can obtain anything else but a zeroconf addres <holtmann> That is expected behavior. <cristianiorga> I tried to solve this one by blacklisting eth <cristianiorga> but, in that case, i cannot control at all eth0 via connman <holtmann> Also expected behavior. <cristianiorga> yes <cristianiorga> I know that :-D <cristianiorga> How can I solve this one? <holtmann> Configure static IP for eth0. Hope that the MAC address stays the same and is not changed on every boot. <cristianiorga> The intention is in the beginning connman should see that eth0 already has an address assigned, but it should still be able to control that interface <holtmann> No. That intention is wrong. <holtmann> ConnMan has full control over the interface and will clear all IPs. <cristianiorga> OK. Where that static address should be configured? <cristianiorga> in main.conf? <holtmann> If you have other network configuration scripts in the background, then ConnMan will not play with them. We are not trying to make that work at all. <holtmann> Right now, only over D-Bus or with connmanctl. <cristianiorga> But if I configure a static IP address via other means than connman, will connman still be avle to provide an offline mode? <holtmann> Nope. <holtmann> It is not designed for that. If you want to manually go behind ConnMan's back, all bets are off. <holtmann> I would just run Qemu with providing a network with DHCP server. That is how I start my KVMs. <cristianiorga> OK, but I can configure eth0 with a static address via connman and still be able to activate offline mode? <holtmann> Once you set static addresses via ConnMan D-Bus API, then yes, you can use offline/online mode settings. <cristianiorga> we are using TUN, and we don't want our machine to depend on a specific network config <cristianiorga> (I am working on YP on INtel's behalf) <holtmann> You need to have network config somewhere. <holtmann> If it is static on the client or central as DHCP server does not matter much. Unless zeroconf is good enough for you. Which you get with ConnMan in case DHCP fails. <cristianiorga> Right. Thanks you Marcel. I guess that "set static addresses vpy " is the right answer for me <holtmann> Most likely it is. <holtmann> Ethernet provisioning is on the TODO list.
Technical solution: 1. Extract network interface settings transmitted by runqemu script via kernel cmdline params 2. Set this params using connmanctl CLI interface
Actually, the second part is done using Ethernet provisioning from Connman 1.12
Fixed with commit 6159ad1063f4be518d8f0a1c024f12fc16d13592.
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=6159ad1063f4be518d8f0a1c024f12fc16d13592