Send connman mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.01.org/mailman/listinfo/connman
or, via email, send a message with subject or body 'help' to
        [email protected]

You can reach the person managing the list at
        [email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."


Today's Topics:

   1. Re: Connman v1.33 with systemd v230 : experiencing delay in
      IP assignment (Shrikant Bobade)
   2. Re: Connman v1.33 with systemd v230 : experiencing delay in
      IP assignment (Daniel Wagner)
   3. Re: Connman v1.33 with systemd v230 : experiencing delay in
      IP assignment (Shrikant Bobade)
   4. Re: Getting of ethernet MAC (Patrik Flykt)


----------------------------------------------------------------------

Message: 1
Date: Wed, 11 Jan 2017 11:41:06 +0530
From: Shrikant Bobade <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Subject: Re: Connman v1.33 with systemd v230 : experiencing delay in
        IP assignment
Message-ID:
        <CALwQErrNCoeZyx0KG=8sEc8+PTh=0kd2rywpsnfmsiew8u7...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi Daniel,

On Tue, Jan 10, 2017 at 2:37 AM, Daniel Wagner <[email protected]> wrote:
>
> Hi Shrikant,
>
> On 01/09/2017 11:22 AM, Shrikant Bobade wrote:
> > seems the connmand hangs much earlier..
>
> And so goes my theory down the toilet. Well, so there is something
> calling gnutls_global_init really early on.
>
> >>> #4  0x76d64dfc in _gnutls_global_init (constructor=constructor@entry
=1)
> >>> at ../../gnutls-3.5.3/lib/global.c:307
>
> This time I think I got it(TM). On load of the library the 'constructor'
> of the library is called (see man pages for details: man dlopen) and
> gnutls calls under certain condition _gnutls_global_init() itself.
> That also explains why you don't see an proper stack trace in gdb.
>
ok.
> From lib/global.c:
>
>
> static void _CONSTRUCTOR lib_init(void)
> {
> int ret;
> const char *e;
>
>         if (_gnutls_global_init_skip() != 0)
>                 return;
>
>         e = secure_getenv("GNUTLS_NO_EXPLICIT_INIT");
>         if (e != NULL) {
>                 ret = atoi(e);
>                 if (ret == 1)
>                         return;
>         }
>
>         ret = _gnutls_global_init(1);
>         if (ret < 0) {
>                 fprintf(stderr, "Error in GnuTLS initialization: %s\n",
gnutls_strerror(ret));
>                 _gnutls_switch_lib_state(LIB_STATE_ERROR);
>         }
> }
>
> if you start ConnMan with 'GNUTLS_NO_EXPLICIT_INIT=1 ./connmand -n -d' it
should work.
>
> Now I cross my fingers :D

yes, with zero entropy and GNUTLS_NO_EXPLICIT_INIT=1
:~# cat /proc/sys/kernel/random/entropy_avail
0
:~#
:~# GNUTLS_NO_EXPLICIT_INIT=1 ./connmand -n -d
connmand[801]: Connection Manager version 1.33
connmand[801]: ../connman-1.33/src/dbus.c:__connman_dbus_init()
connmand[801]: ../connman-1.33/src/inotify.c:__connman_inotify_init()
connmand[801]: ../connman-1.33/src/technology.c:__connman_technology_init()
connmand[801]: ../connman-1.33/src/storage.c:storage_load() Loading
/var/lib/connman/settings
connmand[801]: ../connman-1.33/src/storage.c:storage_load() Loading
/var/lib/connman/settings
connmand[801]: ../connman-1.33/src/notifier.c:__connman_notifier_init()
connmand[801]: ../connman-1.33/src/agent.c:__connman_agent_init()
connmand[801]: ../connman-1.33/src/service.c:__connman_service_init()
connmand[801]: ../connman-1.33/src/agent.c:connman_agent_driver_register()
Registering driver 0xbd1a0 name service
connmand[801]:
../connman-1.33/src/peer_service.c:__connman_peer_service_init()
connmand[801]: ../connman-1.33/src/peer.c:__connman_peer_init()
connmand[801]: ../connman-1.33/src/provider.c:__connman_provider_init()
connmand[801]: ../connman-1.33/src/notifier.c:connman_notifier_register()
notifier 0xbd1c4 name provider
connmand[801]: ../connman-1.33/src/network.c:__connman_network_init()
connmand[801]: ../connman-1.33/src/config.c:__connman_config_init()
connmand[801]: ../connman-1.33/src/inotify.c:create_watch() Add directory
watch for /var/lib/connman
connmand[801]: ../connman-1.33/src/config.c:read_configs()
connmand[801]: ../connman-1.33/src/device.c:__connman_device_init()
connmand[801]: ../connman-1.33/src/ippool.c:__connman_ippool_init()
connmand[801]: ../connman-1.33/src/iptables.c:__connman_iptables_init()
connmand[801]: ../connman-1.33/src/firewall.c:__connman_firewall_init()
connmand[801]: ../connman-1.33/src/iptables.c:iptables_init() filter
connmand[801]: ../connman-1.33/src/iptables.c:__connman_iptables_commit()
filter
connmand[801]: ../connman-1.33/src/iptables.c:iptables_init() mangle
connmand[801]: ../connman-1.33/src/iptables.c:__connman_iptables_commit()
mangle
connmand[801]: ../connman-1.33/src/iptables.c:iptables_init() nat
connmand[801]: ../connman-1.33/src/iptables.c:__connman_iptables_commit()
nat
connmand[801]: ../connman-1.33/src/nat.c:__connman_nat_init()
connmand[801]: ../connman-1.33/src/notifier.c:connman_notifier_register()
notifier 0xbd444 name nat
connmand[801]: ../connman-1.33/src/tethering.c:__connman_tethering_init()
connmand[801]: ../connman-1.33/src/counter.c:__connman_counter_init()
connmand[801]: ../connman-1.33/src/manager.c:__connman_manager_init()
connmand[801]: ../connman-1.33/src/notifier.c:connman_notifier_register()
notifier 0xbd174 name manager
connmand[801]: ../connman-1.33/src/stats.c:__connman_stats_init()
connmand[801]: ../connman-1.33/src/clock.c:__connman_clock_init()
connmand[801]: ../connman-1.33/src/timezone.c:__connman_timezone_init()
connmand[801]: ../connman-1.33/src/timezone.c:__connman_timezone_lookup()
sysconfig zone (null)
connmand[801]: ../connman-1.33/src/timezone.c:__connman_timezone_lookup()
localtime zone Etc/UTC
connmand[801]: ../connman-1.33/src/storage.c:storage_load() Loading
/var/lib/connman/settings
connmand[801]: ../connman-1.33/src/ipconfig.c:__connman_ipconfig_init()
connmand[801]: ../connman-1.33/src/rtnl.c:__connman_rtnl_init()
connmand[801]: ../connman-1.33/src/task.c:__connman_task_init()
connmand[801]: ../connman-1.33/src/proxy.c:__connman_proxy_init()
connmand[801]: ../connman-1.33/src/detect.c:__connman_detect_init()
connmand[801]: ../connman-1.33/src/rtnl.c:connman_rtnl_register() rtnl
0xbd1f0 name detect
connmand[801]: ../connman-1.33/src/session.c:__connman_session_init()
.
.
.
got successful ip assignment.

do I need to post complete log some where to share.. or its fine.. as we
are getting now expected ip. please advice..

So will move ahead with explicit GNUTLS_NO_EXPLICIT_INIT=1 & remove the
rngd dependency(added earlier for ~3k entropy available), will it be  fine ?

>
> cheers,
> daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.01.org/pipermail/connman/attachments/20170111/6c3fb581/attachment-0001.html>

------------------------------

Message: 2
Date: Wed, 11 Jan 2017 09:16:04 +0100
From: Daniel Wagner <[email protected]>
To: Shrikant Bobade <[email protected]>
Cc: [email protected]
Subject: Re: Connman v1.33 with systemd v230 : experiencing delay in
        IP assignment
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8

Good Morning Shrikant,

On 01/11/2017 07:11 AM, Shrikant Bobade wrote:
>> if you start ConnMan with 'GNUTLS_NO_EXPLICIT_INIT=1 ./connmand -n -d'
> it should work.
>>
>> Now I cross my fingers :D
> 
> yes, with zero entropy and GNUTLS_NO_EXPLICIT_INIT=1

Yay!

[...]

> got successful ip assignment.
> 
> do I need to post complete log some where to share.. or its fine..

No there is no need for it anymore. We know now what it happening.

> as we are getting now expected ip. please advice..

So this is a configuration issue. I think the best thing we can do here
is update your README file and let people know what to look out for.

Additionally we should also change urandom users in our code base to
random. Will send patches for both.

Obviously, with GNUTLS_NO_EXPLICIT_INIT=1 we just do lazy initialization
and we still might hang later. Not really sure what the best approach
is. It depends on the use cases etc. On my desktop system I never have
seen this problem. The main reason is, that my system does on default
lazy initialization and I don't have a portal in front of my.

> So will move ahead with explicit GNUTLS_NO_EXPLICIT_INIT=1 & remove the
> rngd dependency(added earlier for ~3k entropy available), will it be  fine ?

If you don't need wipsr really early on, you should be fine without
rngd. But testing might reveal that I am wrong. Hard to say :)

cheers,
daniel


------------------------------

Message: 3
Date: Wed, 11 Jan 2017 14:03:56 +0530
From: Shrikant Bobade <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Subject: Re: Connman v1.33 with systemd v230 : experiencing delay in
        IP assignment
Message-ID:
        <calwqerr53z9ngovjyc86zosyvf6q35bn7_e2w-tydn4lev6...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi Daniel, Good Morning,


On Wed, Jan 11, 2017 at 1:46 PM, Daniel Wagner <[email protected]> wrote:
>
> Good Morning Shrikant,
>
> On 01/11/2017 07:11 AM, Shrikant Bobade wrote:
> >> if you start ConnMan with 'GNUTLS_NO_EXPLICIT_INIT=1 ./connmand -n -d'
> > it should work.
> >>
> >> Now I cross my fingers :D
> >
> > yes, with zero entropy and GNUTLS_NO_EXPLICIT_INIT=1
>
> Yay!
>
> [...]
>
> > got successful ip assignment.
> >
> > do I need to post complete log some where to share.. or its fine..
>
> No there is no need for it anymore. We know now what it happening.
>
> > as we are getting now expected ip. please advice..
>
> So this is a configuration issue. I think the best thing we can do here
> is update your README file and let people know what to look out for.

sounds fine..
>
> Additionally we should also change urandom users in our code base to
> random. Will send patches for both.
>
> Obviously, with GNUTLS_NO_EXPLICIT_INIT=1 we just do lazy initialization
> and we still might hang later. Not really sure what the best approach
> is. It depends on the use cases etc. On my desktop system I never have
> seen this problem. The main reason is, that my system does on default
> lazy initialization and I don't have a portal in front of my.

ok, I will run some regressions to confirm it.
>
> > So will move ahead with explicit GNUTLS_NO_EXPLICIT_INIT=1 & remove the
> > rngd dependency(added earlier for ~3k entropy available), will it be
 fine ?
>
> If you don't need wipsr really early on, you should be fine without
> rngd. But testing might reveal that I am wrong. Hard to say :)

yes, agree..

I am running the regressions with GNUTLS_NO_EXPLICIT_INIT=1,
will revert back with the observations.


>
> cheers,
> daniel

Thanks for your continuous help.

Thanks
Shrikant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.01.org/pipermail/connman/attachments/20170111/ef4f97a5/attachment-0001.html>

------------------------------

Message: 4
Date: Wed, 11 Jan 2017 10:54:11 +0200
From: Patrik Flykt <[email protected]>
To: Vladimir Davydov <[email protected]>,
        [email protected]
Subject: Re: Getting of ethernet MAC
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"

On Tue, 2017-01-10 at 20:20 +0300, Vladimir Davydov wrote:
> How to get MAC address of ethernet device if network cable is NOT
> plugged?

The MAC address is/was only available via the service that got removed
when the cable was unplugged.

Cheers,

        Patrik



------------------------------

Subject: Digest Footer

_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman


------------------------------

End of connman Digest, Vol 15, Issue 10
***************************************

Reply via email to