Hi Patrik,


On Wed, Dec 14, 2016 at 7:07 PM, Patrik Flykt <Patrik.Flykt@linux.intel.com> wrote:

        Hi,

On Fri, 2016-12-09 at 19:07 +0530, Shrikant Bobade wrote:
> Checked with connman incrementally from v1.30 to v1.33, found out the
> delay behaviour almost similar on my setup.
> Also ensured systemd-networkd is not running on my setup.

> Further observed with less available entropy.. on the setup causing
> the delay. So continuing with v1.33.

What system was this again? Sounds like there is not enough entropy
when the system has booted.

Just for the sake of testing it, I see a number about 3-4k in
/proc/sys/kernel/random/entropy_avail.


It is yocto based embedded target..
Yes, the setup with almost no entropy available..
So using rngd http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-support/rng-tools/rng-tools_5.bb?h=morty to get the enough entropy available.

 
> Please advise, we suppose to use only /dev/random for better security

Better security, yes. But randomness is exhausted far more easily, and
there wasn't enough entropy on your system in the first place. So it
doesn't help at all in your case.

yes, with almost no entropy at first getting the entropy is priority.
 
> reasons and not /dev/urandom ? thoughts if any for other ways to deal
> with less/no entropy available with /dev/random?

Daniel posted a man page snippet describing urandom. Reading the man
page convinces me that /dev/urandom is decent enough for our purposes.
Besides it does not run out in the same way /dev/random does.


yes, Daniel's post was helpful, thanks for details.
 
ConnMan uses /dev/urandom by default, that file should always provide
"randomness" from the kernel. I didn't understand what you meant with
gnutls being involved in /dev/urandom.

> Any pointers or references will be a great help..

I haven't heard of this kind of problem before. I do have a
urandom.service enabled and started on my system. It saves and restores
a random seed over reboot. You might not have a service like this
running at bootup, and with a userless device it might take a while for
the device to generate enough randomness?


On similar lines.. using rngd.service w.r.to rng-tools at bootup, serving enough entropy ~3-4k, & then observed getrandom hang.
 
Cheers,

        Patrik

Thanks for the response.

-thanks
Shrikant