3227 2012-10-04 06:58:54 +0000 connman sanity tests fail (autobuilder) 2013-03-08 08:24:40 +0000 1 1 7 Build System, Metadata & Runtime OE-Core connectivity 1.3 x86 Multiple RESOLVED FIXED Medium+ normal 1.4 M4 3804 3843 1 constantinx.musca cristian.iorga alexandru.damian cristian.iorga laurentiu.serban meta.mr.watcher meta.watcher mihai.lindner nitin.a.kamble sgw --- --- --- oldest_to_newest 26192 0 constantinx.musca 2012-10-04 06:58:54 +0000 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 26193 1 constantinx.musca 2012-10-04 07:30:42 +0000 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. 27023 2 sgw 2012-10-30 05:41:28 +0000 *** Bug 3354 has been marked as a duplicate of this bug. *** 27705 3 sgw 2012-11-26 23:09:31 +0000 Status Check? We are still seeing failures on Connman? 27757 4 mihai.lindner 2012-11-27 23:23:53 +0000 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]: +++++++++++++++++++++++++++ """ 27802 5 mihai.lindner 2012-11-28 17:02:03 +0000 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. 27960 6 cristian.iorga 2012-12-04 15:41:50 +0000 Hi Mihai, What version of connman exhibits the stated behavior? Version 1.4? 27961 7 mihai.lindner 2012-12-04 15:45:54 +0000 (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. 29999 8 cristian.iorga 2013-02-21 09:47:17 +0000 Technical solution is found. Implementation is in the work. 30001 9 cristian.iorga 2013-02-21 13:25:11 +0000 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. 30002 10 cristian.iorga 2013-02-21 13:38:02 +0000 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. 30003 11 cristian.iorga 2013-02-21 13:40:04 +0000 Technical solution: 1. Extract network interface settings transmitted by runqemu script via kernel cmdline params 2. Set this params using connmanctl CLI interface 30333 12 cristian.iorga 2013-03-01 16:52:15 +0000 Actually, the second part is done using Ethernet provisioning from Connman 1.12 30565 13 cristian.iorga 2013-03-08 08:23:06 +0000 Fixed with commit 6159ad1063f4be518d8f0a1c024f12fc16d13592. 30566 14 cristian.iorga 2013-03-08 08:24:40 +0000 http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=6159ad1063f4be518d8f0a1c024f12fc16d13592