Hi, so it is already over 2 weeks since I last heard something about this topic. My last understanding was that we have very likely a bug, that responses for subdomain resolve requests aren't formatted correctly. How to procede? Can you reproduce it? Do you expect more work from me?
2012/7/19 Erik Bernoth <[email protected]>: > Hi Daniel, > > 2012/7/19 Daniel Wagner <[email protected]>: >> Hi Erik, >> >> >> On 18.07.2012 17:02, Erik Bernoth wrote: >>> >>> 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. >> >> >> If you have the project cloned and just need to update it to lastest version >> (assuming you don't have branches etc), just do a >> >> git pull >> >> that will do all the needed stuff. If you are paranoid before recompile run >> ./bootstrap-configure and then make. >> >> >>> As a site note I want to add it's not just this one target. The >>> problem exists on all targets from this type. >> >> >> What do you mean with 'target'. I don't follow. >> >> >>> 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? >> >> >> ConnMan writes into /etc/resolv.conf that there is a DNS server >> listening on localhost (127.0.0.1). >> >> $ cat /etc/resolv.conf >> >> # Generated by Connection Manager >> nameserver 127.0.0.1 >> >> If that entry is missing then check if you have some other daemon blocking >> the port, e.g. dnsmasq. >> >> When libc wants to resolve a domain name, it will ask ConnMan. ConnMan will >> forward that request to the real DNS server. So it acts as proxy. You can >> check this with running a tcpdump on localhost interface and your uplink. >> Then you see what's happening. >> >> HTH, >> daniel > > 1) Git pulling. Yeah, the problem was, that in OE you don't do the git > stuff yourself, OE wants to do it for you. Nice little framework but > because of the additional layer of abstraction it's easy to confuse > things sometimes. > > 2) 'target': A 'target' is a word from embedded systems development. > Normally you don't develop on your embedded system because > traditionally they are not as capable as desktops or laptops. Think > netbook or mobile phone, but without keyboard and screen. If you > develop on those things you need to distinguish between your > development computer, where you write your code and cross compile it > and the computer you are actually developing for. So the dev machine, > the powerful desktop, is called 'host' and the small thing you are > programming for, which might end up in a wall, a car or as a small > part inside other computers, that's your 'target'. So I say that, to > make clear that my dev computer has no problems with DHCP and > subdomains, but the small machine I am developing for,the target, > can't resolve subdomains with ConnMan. The big one uses a standard > Ubuntu with Network Manager. If I don't find anything else to do, then > my task today will be to install ConnMan on my 'host' and see if he > will have the same problem as my 'target'. > > 3) That nameserver entry is not missing. My resolv.conf is exactly as > you say it should be. Also I'm quite sure (not 100%, though), that > there is no other program that would try to do the same job. > > 4) I used tcpdump this morning. A very good advice! I wrote the > results into a file and compared the results with the same requests on > the Ubuntu 'host' machines. The comparing was done with Wireshark. > > On my host machine (Ubuntu 12.04 vanilla) I have the following resolv.conf: > # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) > # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN > nameserver 127.0.0.1 > search internal-server > > I share this resolv.conf with every Linux machine in the network > (beside the target computers who all use ConnMan). > The following are the results of a "tcpdump -i lo -w tcp.dump -s 0" > request on 2 computers. One is a normal Ubuntu 12.04 vanilla machine > were everything works fine and the other is the target machine with > the self compiled Linux and ConnMan on board. > > If I do a DNS lookup on my host with "ping sub", the DNS request will > automatically ask for "sub.internal-server", which is expected because > of the "search" line in my resolv.conf. The result will be well formed > Response telling the IP adress, which is then used by ping without > problems. > When I do a lookup on my Ubuntu host after REMOVING the search line, > then I the DNS request will be for "sub" and the DNS reply will be the > reply code for "No such name" and no RR's will be appended. > That's it for the host "lo" interface. > > On the target, the machine using ConnMan (and without "search" or > "domain" in the resolv.conf), "ping sub" will request "sub" and the > response will be the same as on my Ubuntu machine, just without the > appended "internal-server". So he asks for "sub" and he recieves a > correct IP adress, but everywhere there is no "sub.internal-server". > There are also some additional RR's in the end which can't be read > correctly by wireshark. I tested that in many different variations and > many times, so I am sure that is always the case. The ping will still > fail, with telling that "sub" is unknown. > > This is confusing, because on one side he recieves the correct > information (the IP adress) and doesn't use it, on the other hand he > asks for the wrong thing ("sub" and not "sub.internal-server") and > still gets a response instead of a "No such name" as on the other > computers. Last but not least only in this scenario the DNS response > seems to be broken. > > Of course I have no clue, but to me it looks like ConnMan recieves the > DNS requests correctly over the localhost interface, then he requests > correctly ("sub.internal-server") from the DNS server and recieves a > correct response (how else can he know the IP of > "sub.internal-server"?) and then he writes his own response. That > makes sense, because without a "search" or "domain" line in > resolv.conf only ConnMan knows that "sub" is actually a subdomain of > "internal-server", every other tool on the machine will think "sub" is > a domain by itself. So he translates "sub" to "sub.internal-server" > when he requests the IP adress and then translates it back to "sub" > for his own response on the localhost-interface to ping. But while > doing that he something happens, which results in a malformed package. > Maybe something very simple as one of the many length and count fields > is just copied from the original response, which is bad because > "sub.internal-server" is obv. longer then "sub". > > > > Do I understand correctly what should be happening? Does my reasoning > for the problem sounds logical? How can I check if that reasoning is > correct? Any other suggestions? > > > -- > Mit freundlichen Grüßen / Kind Regards > Erik Bernoth > > DResearch Fahrzeugelektronik GmbH > Otto-Schmirgal-Str. 3, 10319 Berlin, Germany -- 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
