On Fri, 2016-12-09 at 19:07 +0530, Shrikant Bobade wrote:
Checked with connman incrementally from v1.30 to v1.33, found out
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
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.
reasons and not /dev/urandom ? thoughts if any for other ways to
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.
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?