Hi Jukka, thanks for your reply!
2012/7/18 Jukka Rissanen <[email protected]>: > Hi Erik, > > > > On 07/18/2012 03:06 PM, Erik Bernoth wrote: >> >> Hi Marcel, >> >> thanks for your reply! >> >> 2012/7/18 Marcel Holtmann <[email protected]>: >>> >>> Hi Erik, >>> >>> >>> actually ConnMan creates a local DNS proxy and cache at localhost. And >>> it should put 127.0.0.1 nameserver in /etc/resolv.conf. The -r option >>> forces ConnMan to disable the DNS proxy. >>> >>> So what you are talking about is the search domain option. And we are >>> not doing that via our internal DNS proxy? >>> >>> Regards >>> >>> Marcel >>> >> >> Without "-r" ConnMan writes 127.0.0.1 as nameserver in the >> /etc/resolv.conf, as you say. And it resolves domains like gogle.com, >> but it doesn't resolve subdomains in the local network, even though >> ConnMan knows the domain name (see "list-services" result in the first >> message) >> >> >> normal start-up /etc/resolv.conf: >> # Generated by Connection Manager >> nameserver 127.0.0.1 >> >> -> "ping google.com" works >> -> "ping sub" doesn't work >> >> after udhcpc -i eth1: >> domain internal-server >> nameserver 192.168.1.1 >> >> -> "ping google.com" works >> -> "ping sub" works(!!) >> >> after hadware reset starting with /usr/sbin/connmand -n -r: >> # Generated by Connection Manager >> search internal-server >> nameserver 192.168.1.1 >> >> -> "ping google.com" works >> -> "ping sub" works, too >> > > > There have been some fixes to resolver regarding search domain handling in > May after your commit 6d6f312fb2b751b4cf70. Could you try to upgrade in > order to see if your problems are solved already? > > > Cheers, > Jukka > Because of your advice I cloned the repository outside of OE and found out, that gitk doesn't nessesarily show all commits but maybe just up to the one you checked out. So I updated the recipe to the 1.3 tag, compiled and installed 1.3 on my target. I checked that he really uses the 1.3 version with calling command directly and looking what he prints as the first line. It didn't help though. I am looking through the commits that gitk marks bold, when searching for resolver, domain nd. Most of them are between 1.0 and 1.1. But couldn't really learn much from that. As a site note I want to add it's not just this one target. The problem exists on all targets from this type. I still try to understand what the expected state of connman is. For example should it listen to any port? Does it require a user or a group? Could it be configured to just listen to one kind of request but not another? -- Mit freundlichen Grüßen / Kind Regards Erik Bernoth DResearch Fahrzeugelektronik GmbH Otto-Schmirgal-Str. 3, 10319 Berlin, Germany _______________________________________________ connman mailing list [email protected] http://lists.connman.net/listinfo/connman
