[yocto] replace udhcpc

Fri May 9 09:51:24 PDT 2014

Hi Andrea

I'd like the idea of a somewhat smarter network daemon, but connman
slowly becomes a bit suspicious to me.

First, it is very bad documented and difficult to understand what it
does. Second, it needs iptables to work. Why? Third, it adds strange
static routes to my routing table and deletes them later
(87.106.208.187). What is it doing there? Sending pings to this server?

Hmm, anybody knows a reasonable alternative? Maybe I just start a
dhclient on my LAN interface and see if it stays in the background, when
disconnected.

Michael

Am 09.05.2014 17:27, schrieb Andrea Galbusera:
> Michael,
> 
> On Fri, May 9, 2014 at 3:21 PM, Auslands-KV <auslands-kv at gmx.de> wrote:
>> Thanks a lot. I will look through these links and hope I will understand
>> better then :-)
>>
>> I hope it works nicely with a read-only rootfs. It seems to write to its
>> own config data (which is a strange behaviour).
> 
> One of the reasons I started looking at connman was the hope to find a
> solution to the hell that comes with runtime configuration of network
> connections in embedded systems. What I had to address many and many
> time in the past was designing the glue logic sitting between the
> application specific way of saying "I want eth1 to have this address"
> instead of "add this DNS server" and the backend required to "deploy"
> such a new configuration. This usually involved poking with some
> configuration file and restarting/signaling a service to pickup the
> new configuration.
> 
> If I understand it correctly, one of the main goals of connman's
> design is to provide a backend functionality for handling
> configurations and deploying them all in a standard and well defined
> way. This is accomplished by implementing appropriate interfaces
> exposed over d-bus. It turns out to allows client application, either
> the provided connmanctl client or your application specific
> configuration frontend, to interact with the low-level configuration
> engine, connman daemon, which support plugins for different connection
> technologies specific needs.
> 
> So, yes, in my understanding, connman manages its own configuration
> files. You're supposed to interact with it at an higher level, through
> methods calls over d-bus: this allows, amongst other things, multiple
> applications to interact with connman in a safe and controlled way. I
> guess the design got highly inspired by network configuration tools
> included in modern Linux distros and the way they work, GNOME's
> networkmanager being probably one of them. Connman brings all this to
> the embedded by making it a little bit more lightweight and modular.
> Anyway, quite far from classic "write myriads of format-heterogeneous
> config files and fire up some hacked script for reconfiguration".
> 
> Read-only filesystem shouldn't be a problem itself. I guess you can
> configure connman to have its own configuration files placed on a
> tmpfs or similar. Of course, if you need to change configurations at
> runtime and persistency is required, you probably still need some
> writable filesystem. But this would be so, even without connman!
> 
>> Do you by chance know, why it depends on the xuser-account package? I
>> don't want any additional user accounts on my system. If it is not
>> essential I would remove it.
> 
> I'd guess depending on xuser-account grants providing the correct
> d-bus permissions for interacting with connman to processes which run
> under a GUI session (non-root). IMHO this RDEPEND should be somewhat
> conditional to X being enabled on your distro/image. I couldn't find
> any explicit reference to xuser in connman source code... Maybe
> someone more expert than me on the list can give a better explanation.
> 
>>
>> Thanks
>>
>> Michael
>>
>> Am 09.05.2014 15:06, schrieb Andrea Galbusera:
>>> Hi,
>>>
>>> On Fri, May 9, 2014 at 12:28 PM, Neuer User <auslands-kv at gmx.de> wrote:
>>>> Connman is really a problem without documentation. :-(
>>>>
>>>> I tried it out and first I noticed that it depends on the creation of an
>>>> xuser account. It also needs iptables, so probably can configure these, too.
>>>>
>>>> I also found that it does not correctly configure the dns entries:
>>>>
>>>> cat /etc/resolv.conf:
>>>> # Generated by Connection Manager
>>>> nameserver 127.0.0.1
>>>> nameserver ::1
>>> This is in fact a working configuration for the DNS proxy feature that
>>> connman offers built-in. See [1].
>>> I personally went through your same frustration when trying to
>>> understand how connman is supposed to work in order to evaluate its
>>> maturity. Not yet an expert at all, but [2] and [3] gave me a
>>> reasonable bootstrap into connman's main logic. Beside this, "git
>>> grepping" the source tree is your best friend.
>>> Angstrom distribution, i.e. available on the beaglebone boards is also
>>> a good example of a real connman based system.
>>>
>>>> I really would like to understand what it does with these and how I can
>>>> change or modify it's behaviour.
>>>>
>>>> It's definitely not just "when ethernet cable inserted, bring up the
>>>> interface using DHCP".
>>>>
>>>> I even can't find a config file for connman. Is there one?
>>> Yes, there usually is one for each service handled by connman. See [4]
>>> for details on configuration file format and their default location.
>>> As you can see from previously suggested references, you'll usually
>>> modify configurations by using the connmanctl client tool instead of
>>> editing those files by hand.
>>>
>>> [1] http://git.kernel.org/cgit/network/connman/connman.git/tree/README
>>> [2] http://derekmolloy.ie/set-ip-address-to-be-static-on-the-beaglebone-black/
>>> [3] http://www.ptrackapp.com/apclassys-notes/embedded-linux-using-connma/
>>> [4] http://git.kernel.org/cgit/network/connman/connman.git/tree/doc/config-format.txt
>>>
>>>> Thanks
>>>>
>>>> Michael
>>>>
>>>> Am 08.05.2014 12:27, schrieb Burton, Ross:
>>>>> On 8 May 2014 04:58, Neuer User <auslands-kv at gmx.de> wrote:
>>>>>> I had a brief look at connman half a year ago, but that time I was
>>>>>> unable to find a good documentation about it. Do you have by chance a
>>>>>> link to some tutorial or at least man entry for the configuration?
>>>>> What do you need to configure?  For "when ethernet cable inserted,
>>>>> bring up the interface using DHCP" this is default behaviour and won't
>>>>> need any configuring.  connman is sadly under-documented but the IRC
>>>>> channel is fairly responsive.
>>>>>
>>>>> Ross
>>>>>
>>>>
>>>> --
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto at yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>