Hello everyone,
I am currently trying to get ConnMan to work on an embedded system
with OpenEmbedded. ConnMan itself seems to start fine and knows all
the relevant information. Yet using other tools like wget or curl
doesn't work as expected. For example I have a server
"internal-server" at 192.168.1.99 with a subdomain
"sub.internal-server". I'd expect to "ping sub" to send it's packages
to 192.168.1.99, yet it says it doesn't know any domain called "sub".
It would be nice if someone could check my work up to now and help me
pin down the problem. To begin with, I don't really know what should
be the expected state of ConnMan and the system, that other tools can
use ConnMan's DNS proxy capabilities instead of /etc/resolv.conf. It's
kind of hard to find the problem, if you don't know which state is
good and which is bad.
To understand ConnMan better I tried to figure out part of the source
code, ran the connmand with different args, looked at it's output with
and without -d and tried to use tools that are delivered with and for
ConnMan.
E.g. asking the "list-services" script ConnMan seems to know
everything he should (IPs, IDs and names changed):
[ ethernet_<ID>_cable ]
IPv6.Configuration = { Method=auto Privacy=disabled }
AutoConnect = true
Name = Wired
Nameservers = [ 192.168.1.1 ]
Provider = { }
Favorite = true
Domains.Configuration = [ ]
Timeservers.Configuration = [ ]
State = online
Proxy = { Method=direct }
Nameservers.Configuration = [ ]
IPv4 = { Netmask=255.255.255.0 Gateway=192.168.1.1 Method=dhcp
Address=192.168.1.118 }
Timeservers = [ 192.168.1.1 ]
IPv6 = { }
Domains = [ internal-server ]
Ethernet = { Interface=eth1 MTU=1500 Method=auto Address=<a MAC> }
Security = [ ]
Proxy.Configuration = { }
Type = ethernet
Immutable = false
IPv4.Configuration = { Method=dhcp }
I don't have anything listening on port 53 (DNS Server), but I don't
know if ConnMan should listen there or not. I also don't think there
are other tools installed that could stop ConnMan from using port 53.
But if that's a problem I can check in depth what tools are installed.
The same goes for user/group related stuff. I don't know which user
and groups he should run as. Starting it manually as root doesn't
improve the situation, though.
There was a shell script called connman_test.sh or something like
that. It printed everything works correctly.
If I start connmand -r he writes the correct lines to /etc/resolv.conf
and afterwards every other tool can work properly. (That one is my
work around for now, but not really the best result, right?)
I am using a self-built 1.0-tagged revision (6d6f312fb2b751b4cf70...)
from git://git.kernel.org/pub/scm/network/connman/connman.git
OE also applies 2 patch files after git clone, named
"0001-plugin.h-Cange-visibility-to-default-for-debug-symb.patch" and
"add_xuser_dbus_permission.patch", which's contents I can supply later
if needed.
>From what I can tell, there is no non-default configuration beside
these 2 patch files, but I could be wrong.
Because you might need it, I will also add the output for a starting
"/usr/sbin/connmand -n" (replaced names, IPs, IDs and MACs):
1 connmand[266]: Connection Manager version 1.0
2 connmand[266]: Checking loopback interface settings
3 connmand[266]: System hostname is mysys
4 connmand[266]: System domainname is internal-server
5 connmand[266]: Failed to open RFKILL control device
<- something fails here
6 connmand[266]: lo {newlink} index 1 operstate 0 <UNKNOWN>
7 connmand[266]: eth0 {create} index 2 type 1 <ETHER>
8 connmand[266]: eth0 {update} flags 4098 <DOWN>
9 connmand[266]: eth0 {newlink} index 2 operstate 2 <DOWN>
10 connmand[266]: Adding interface eth0 [ ethernet ]
11 connmand[266]: eth1 {create} index 3 type 1 <ETHER>
12 connmand[266]: eth1 {RX} 266 packets 53142 bytes
13 connmand[266]: eth1 {TX} 85 packets 14092 bytes
14 connmand[266]: eth1 {update} flags 4098 <DOWN>
15 connmand[266]: eth1 {newlink} index 3 address $MAC$ mtu 1500
16 connmand[266]: eth1 {newlink} index 3 operstate 2 <DOWN>
17 connmand[266]: Adding interface eth1 [ ethernet ]
18 connmand[266]: eth1 {RX} 266 packets 53142 bytes
19 connmand[266]: eth1 {TX} 85 packets 14092 bytes
20 connmand[266]: eth1 {update} flags 4099 <UP>
21 connmand[266]: eth1 {newlink} index 3 address $MAC$ mtu 1500
22 connmand[266]: eth1 {newlink} index 3 operstate 2 <DOWN>
23 connmand[266]: eth1 {add} route ff00:: gw :: scope 0 <UNIVERSE>
24 connmand[266]: eth1 {add} route fe80:: gw :: scope 0 <UNIVERSE>
25 connmand[266]: eth1 {RX} 266 packets 53142 bytes
26 connmand[266]: eth1 {TX} 85 packets 14092 bytes
27 connmand[266]: eth1 {update} flags 69699 <UP,RUNNING,LOWER_UP>
28 connmand[266]: eth1 {newlink} index 3 address $MAC$ mtu 1500
29 connmand[266]: eth1 {newlink} index 3 operstate 6 <UP>
30 connmand[266]: eth1 {del} route fe80:: gw :: scope 0 <UNIVERSE>
31 connmand[266]: eth1 {del} route ff00:: gw :: scope 0 <UNIVERSE>
32 connmand[266]: Skipping disconnect of carrier, network is connecting.
33 connmand[266]: eth1 {add} route ff00:: gw :: scope 0 <UNIVERSE>
34 connmand[266]: eth1 {add} route fe80:: gw :: scope 0 <UNIVERSE>
35 connmand[266]: Setting domainname to internal-server
36 connmand[266]: Deleting host route failed (No such process)
<- something fails here
37 connmand[266]: Adding DNS server 192.168.1.1
38 connmand[266]: Enabling DNS server 192.168.1.1
39 connmand[266]: eth1 {add} address 192.168.1.118/24 label eth1 family 2
40 connmand[266]: eth1 {add} route192.168.1.0 gw 0.0.0.0 scope 253 <LINK>
41 connmand[266]: eth1 {add} route 192.168.1.1 gw 0.0.0.0 scope 253 <LINK>
42 connmand[266]: eth1 {add} route 0.0.0.0 gw 192.168.1.1 scope 0 <UNIVERSE>
43 connmand[266]: Setting default gateway route failed (File exists)
<- something fails here
44 connmand[266]: eth1 {add} route 11.111.222.333 gw 192.168.1.1
scope 0 <UNIVERSE>
45 connmand[266]: Client-IP: 123.123.123.123
46 connmand[266]: Client-Country: DE
47 connmand[266]: eth1 {del} route 11.111.222.333 gw 192.168.1.1
scope 0 <UNIVERSE>
Googling resulted in finding this mailing list and a PDF that
explained the basic structure of ConnMan, probably from a presentation
by Marcel Holtmann for Intel. This way I found out that ConnMan
actually tries to do the DNS himself instead of writing it's knowledge
into /etc/resolv.conf and that modern network experts don't like
/etc/resolv.conf, for whatever reason.
That's what I got so far.
Every help is needed and appreciated!
--
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
