replace udhcpc

replace udhcpc

[Neuer User]

Hi

I encounter a problem with the DHCP network setup during boot:

System starts. During start ifup is called. ifup calls udhcpc. Network
is, however, not yet up! udhcpc exits with failure. Then network is up.
But, of course, no connection, because no IP address.

In earlier times I used debian based system, which seem to rely on
dhclient3. My experiences here were that dhclient remained as a deamon
continuing trying to get a dhcp address.

What should I do best on Yocto? Replace udhcpc with dhclient? If so, how
should that be done?

Or can udhcpc be configured to remain in the background and try to get
an IP address when network is finally up?

Thanks for any help

Michael

Re: replace udhcpc

[Søren Holm]

Use ifplugd recipe I just submitted.

Onsdag den 7. maj 2014 10:57:22 skrev Neuer User:
> Hi
> 
> I encounter a problem with the DHCP network setup during boot:
> 
> System starts. During start ifup is called. ifup calls udhcpc. Network
> is, however, not yet up! udhcpc exits with failure. Then network is up.
> But, of course, no connection, because no IP address.
> 
> In earlier times I used debian based system, which seem to rely on
> dhclient3. My experiences here were that dhclient remained as a deamon
> continuing trying to get a dhcp address.
> 
> What should I do best on Yocto? Replace udhcpc with dhclient? If so, how
> should that be done?
> 
> Or can udhcpc be configured to remain in the background and try to get
> an IP address when network is finally up?
> 
> Thanks for any help
> 
> Michael

-- 
Søren Holm

Re: replace udhcpc

[Neuer User]

Am 07.05.2014 11:27, schrieb Søren Holm:
> Use ifplugd recipe I just submitted.
> 

Very nice idea. Where do I find the recipe?

> Onsdag den 7. maj 2014 10:57:22 skrev Neuer User:
>> Hi
>>
>> I encounter a problem with the DHCP network setup during boot:
>>
>> System starts. During start ifup is called. ifup calls udhcpc. Network
>> is, however, not yet up! udhcpc exits with failure. Then network is up.
>> But, of course, no connection, because no IP address.
>>
>> In earlier times I used debian based system, which seem to rely on
>> dhclient3. My experiences here were that dhclient remained as a deamon
>> continuing trying to get a dhcp address.
>>
>> What should I do best on Yocto? Replace udhcpc with dhclient? If so, how
>> should that be done?
>>
>> Or can udhcpc be configured to remain in the background and try to get
>> an IP address when network is finally up?
>>
>> Thanks for any help
>>
>> Michael
> 

Re: replace udhcpc

[Joe MacDonald]

[-- Attachment #1: Type: text/plain, Size: 1282 bytes --]

[Re: [yocto] replace udhcpc] On 14.05.08 (Thu 05:54) Neuer User wrote:

> Am 07.05.2014 11:27, schrieb Søren Holm:
> > Use ifplugd recipe I just submitted.
> > 
> 
> Very nice idea. Where do I find the recipe?

Søren withdrew the submission to meta-networking following further
discussion.

http://permalink.gmane.org/gmane.comp.handhelds.openembedded/63249

-J.

> 
> > Onsdag den 7. maj 2014 10:57:22 skrev Neuer User:
> >> Hi
> >>
> >> I encounter a problem with the DHCP network setup during boot:
> >>
> >> System starts. During start ifup is called. ifup calls udhcpc. Network
> >> is, however, not yet up! udhcpc exits with failure. Then network is up.
> >> But, of course, no connection, because no IP address.
> >>
> >> In earlier times I used debian based system, which seem to rely on
> >> dhclient3. My experiences here were that dhclient remained as a deamon
> >> continuing trying to get a dhcp address.
> >>
> >> What should I do best on Yocto? Replace udhcpc with dhclient? If so, how
> >> should that be done?
> >>
> >> Or can udhcpc be configured to remain in the background and try to get
> >> an IP address when network is finally up?
> >>
> >> Thanks for any help
> >>
> >> Michael
> > 
> 
> 
-- 
-Joe MacDonald.
:wq

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: replace udhcpc

[Burton, Ross]

On 7 May 2014 09:57, Neuer User <auslands-kv@gmx.de> wrote:
> What should I do best on Yocto? Replace udhcpc with dhclient? If so, how
> should that be done?

Personally I prefer using connman for this, it does all the usual
hotplug and connect magic.  If size is an issue, you can disable the
3g and wifi DISTRO_FEATURES if you don't need support for that.

Ross

Re: replace udhcpc

[Neuer User]

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?

Am 07.05.2014 12:24, schrieb Burton, Ross:
> On 7 May 2014 09:57, Neuer User <auslands-kv@gmx.de> wrote:
>> What should I do best on Yocto? Replace udhcpc with dhclient? If so, how
>> should that be done?
> 
> Personally I prefer using connman for this, it does all the usual
> hotplug and connect magic.  If size is an issue, you can disable the
> 3g and wifi DISTRO_FEATURES if you don't need support for that.
> 
> Ross
> 

Re: replace udhcpc

[Burton, Ross]

On 8 May 2014 04:58, Neuer User <auslands-kv@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

Re: replace udhcpc

[Neuer User]

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

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?

Thanks

Michael

Am 08.05.2014 12:27, schrieb Burton, Ross:
> On 8 May 2014 04:58, Neuer User <auslands-kv@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
> 

Re: replace udhcpc

[Andrea Galbusera]

Hi,

On Fri, May 9, 2014 at 12:28 PM, Neuer User <auslands-kv@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@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@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: replace udhcpc

[Auslands-KV]

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

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.

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@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@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@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto

Re: replace udhcpc

[Andrea Galbusera]

Michael,

On Fri, May 9, 2014 at 3:21 PM, Auslands-KV <auslands-kv@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@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@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@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>
>

Re: replace udhcpc

[Neuer User]

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@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@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@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@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>

Re: replace udhcpc

[Neuer User]

Seems, I am not the only one wondering why connman phones home:

https://bbs.archlinux.org/viewtopic.php?id=181038

The address is 87.106.208.187, which is the IP of
"senator.holtmann.net". The author of the connman package seems to be
Marcel Holtmann <marcel AT holtmann.org>.

Honestly, without a reasonable explanation why this package adds this
route, I wouldn't use this package on my systems.

Am 09.05.2014 18:51, schrieb Neuer User:
> 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@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@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@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@yoctoproject.org
>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>>
> 
> 

Re: replace udhcpc

[Burton, Ross]

On 9 May 2014 17:57, Neuer User <auslands-kv@gmx.de> wrote:
> Seems, I am not the only one wondering why connman phones home:

The "ask the author" approach works quite well.  The hostname it's
looking up is connman.net.  This is the captive portal detection:
pretty much every major platform does something similar and it's to
detect the situation that you have something that looks like a network
connection, but actually you're not routed anywhere (i.e. you're in a
hotel and need to pay for connectivity).  ConnMan makes a trivial
request to it's home page and if it gets back the response it was
expecting you have internet, captive portals tend to include
machine-readable links in the response that ConnMan will tell the UI
to open.  If you've ever joined an iOS (and probably Android, but I've
not got one) device to a hotel's wifi and seen a login page open
immediately the same you've seen this behaviour in action.

The response also includes some basic geo-ip so your machine knows
roughly where it is, useful for automatic timezone updating.

Ross

Re: replace udhcpc

[Neuer User]

Thanks for the informative answer.

As I said, I like the idea of a small and lightweigth, but still
powerful daemon. But in addition to the described behaviour and the lack
of documentation, it is also not working correctly on my system. After
the first dhcp lease is expired, connman segfaults and the system is
again without ip.

Found this on the internet:
https://www.mail-archive.com/connman@connman.net/msg15637.html


Am 09.05.2014 20:37, schrieb Burton, Ross:
> On 9 May 2014 17:57, Neuer User <auslands-kv@gmx.de> wrote:
>> Seems, I am not the only one wondering why connman phones home:
> 
> The "ask the author" approach works quite well.  The hostname it's
> looking up is connman.net.  This is the captive portal detection:
> pretty much every major platform does something similar and it's to
> detect the situation that you have something that looks like a network
> connection, but actually you're not routed anywhere (i.e. you're in a
> hotel and need to pay for connectivity).  ConnMan makes a trivial
> request to it's home page and if it gets back the response it was
> expecting you have internet, captive portals tend to include
> machine-readable links in the response that ConnMan will tell the UI
> to open.  If you've ever joined an iOS (and probably Android, but I've
> not got one) device to a hotel's wifi and seen a login page open
> immediately the same you've seen this behaviour in action.
> 
> The response also includes some basic geo-ip so your machine knows
> roughly where it is, useful for automatic timezone updating.
> 
> Ross
> 

Re: replace udhcpc

[Neuer User]

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

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.

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@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@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@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto

Re: replace udhcpc

[Burton, Ross]

On 9 May 2014 16:15, Neuer User <auslands-kv@gmx.de> wrote:
> 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.

If you're applications are running as root then you can remove the
dependency on that package and the patch that changes the security
policy.  The reasoning is complicated but basically so that the "user"
can manipulate the network settings.

Ross

Re: replace udhcpc

[Neuer User]

Great, then I will remove it.

My app does not run as root, but all system configuration tasks are only
available for root on my system.

Am 09.05.2014 17:22, schrieb Burton, Ross:
> On 9 May 2014 16:15, Neuer User <auslands-kv@gmx.de> wrote:
>> 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.
> 
> If you're applications are running as root then you can remove the
> dependency on that package and the patch that changes the security
> policy.  The reasoning is complicated but basically so that the "user"
> can manipulate the network settings.
> 
> Ross
> 

[solved] Re: replace udhcpc

[Neuer User]

Found a very simple solution to the original problem (after reading
through the busybox source code). Just add this small recipe to your
layer, and udhcpc will fork in to the background to gain the IP as soon
as the network is available:

diff --git a/recipes-core/busybox/busybox_%.bbappend
b/recipes-core/busybox/busybox_%.bbappend
new file mode 100644
index 0000000..14e4e37
--- /dev/null
+++ b/recipes-core/busybox/busybox_%.bbappend
@@ -0,0 +1,4 @@
+FILESEXTRAPATHS_append := "${THISDIR}/files:"
+
+SRC_URI += "file://udhcpc-opts.cfg \
+           "
diff --git a/recipes-core/busybox/files/udhcpc-opts.cfg
b/recipes-core/busybox/files/udhcpc-opts.cfg
new file mode 100644
index 0000000..d02ba19
--- /dev/null
+++ b/recipes-core/busybox/files/udhcpc-opts.cfg
@@ -0,0 +1 @@
+CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS="-R -b"


Am 07.05.2014 10:57, schrieb Neuer User:
> Hi
> 
> I encounter a problem with the DHCP network setup during boot:
> 
> System starts. During start ifup is called. ifup calls udhcpc. Network
> is, however, not yet up! udhcpc exits with failure. Then network is up.
> But, of course, no connection, because no IP address.
> 
> In earlier times I used debian based system, which seem to rely on
> dhclient3. My experiences here were that dhclient remained as a deamon
> continuing trying to get a dhcp address.
> 
> What should I do best on Yocto? Replace udhcpc with dhclient? If so, how
> should that be done?
> 
> Or can udhcpc be configured to remain in the background and try to get
> an IP address when network is finally up?
> 
> Thanks for any help
> 
> Michael
>