I built a core-image-sato-sdk image for qemux86 from my dylan-next branch and it seems that DNS is not set up out of the box - I could ping internet IP addresses but not google.com etc. Adding a DNS server manually e.g. 8.8.8.8 to /etc/resolv.conf fixed the problem, but surely with connman I shouldn't need to do this?
This issue is related only to quemu machines.
Can you explain in more details? Is this fixable, is it really a connman issue or because we don't use connman for qemu images?
Connman is used for core-image-sato qemu images, for example. It is not a connman issue.
If some additional DNS servers need to be configured to ConnMan, one option is to add them to /etc/connman/main.conf FallbackNameservers option. <snip from main.conf> # List of fallback nameservers separated by "," appended # to the list of nameservers given by the service. The # nameserver entries must be in numeric format, host # names are ignored. # FallbackNameservers = </snip> The nameservers can also configured to provisioned .config file to Nameservers option. See http://git.kernel.org/cgit/network/connman/connman.git/tree/doc/config-format.txt for details. Normally ConnMan will get the DNS servers via DHCP but qemu uses static IP address so DNS servers are not set up.
I am facing a similar issue here. My setup involves booting from nfsroot. I am able to 'ping 8.8.8.8' but 'ping google.com' does not work. I think this might be related to the fact that the connman init script ignores ethX when it detects we're booting from nfsroot. Ignoring the interface must also skip the name resolving setup on this interface consequently. A simple solution in this case would be to link /proc/net/pnp to /etc/resolv.conf. It seems to work on my side. Someone could try it in the qemu case to see if it solves the issue.
I just sent a patch that only ignores the interface that is used by NFS root. See http://lists.openembedded.org/pipermail/openembedded-core/2013-September/083958.html for details.
Investigation started.
Bug is present also on current master. However, depends if one will consider this to be a bug. Meaning, the most probable technical solution will be to use a global DNS server. Which might be considered by some people a privacy issue, knowing that each page visited might be intercepted by a 3rd party, in this case, Google. On the other hand, given the restricted scope of the proposed technical solution, I consider this to be acceptable. This is happening only in two cases: 1. HW BSP that boots from NFS 2. QEMU machines all architectures Another necessary condition is that connman needs to get used as network manager in that specific image. Let's analyze them: 1. In case nfsroot is used to boot up the system, connman will be instructed to ignore the nfsroot-enabled interface; What can be done here is to configure a global DNS fallback server (Google's 8.8.8.8 is a good candidate) for connman 2. For qemu machines we can configure a global DNS server (same as above) in the wired config. Stage 2 will be implemented before Stage 1.
Global connman fallback DNS is used as a solution, by using a distro variable.
Blocked by: https://01.org/jira/browse/CM-652 Connman is malfunctioning regarding to FallbackNameservers configuration implementation.
Stage 1 implementation sent for review.
Alternate implementation has been used. Regarding the scope of this bug, the issue is fixed in the patch fix sent.
See bug 5322 for stage 2.
Fixed with commit: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=540c27906a3a946878989ee736f0576cccbc6336 .