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
_______________________________________________
connman mailing list
[email protected]
http://lists.connman.net/listinfo/connman
