[yocto] replace udhcpc

Fri May 9 08:27:17 PDT 2014

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
>
>