Hi Andre,

On Wed, Dec 14, 2016 at 7:49 PM, André Draszik <git@andred.net> wrote:

On Fri, 2016-12-09 at 19:07 +0530, Shrikant Bobade wrote:
> Further observed with less available entropy.. on the setup causing the
> delay. So continuing with v1.33.
> e.g.
> *:~# cat
> /proc/sys/kernel/random/entropy_avail
> 0*
> Getting connman waiting/stuck at
> *getrandom (_rnd_get_system_entropy_getrandom) (by default gnutls
> enabled)*
> So tried to increase entropy with help of /dev/urandom & and with
> sufficient ~3k+ entropy count observed the getrandom call completed
> successfully.
> Is this know behaviour Or experienced by anyone.. ?

I think I have seen something similar here, but never investigated in depth as of yet.

> [...]

> reasons and not /dev/urandom ? thoughts if any for other ways to deal with
> less/no entropy available with /dev/random?
> http://security.stackexchange.com/questions/122155/how-bad-it-is-to-feed-d
> ev-random-with-dev-urandom
> http://stackoverflow.com/questions/3690273/did-i-understand-dev-urandom#co
> mment30985465_3709644
> Any pointers or references will be a great help..

For me, the combination of removing GnuTLS usage in ConnMan (disable wispr)
as well as switching all applications to use OpenSSL rather than GnuTLS
(wpa-supplicant in particular) was sufficient to work around this for the
time being. Probably because OpenSSL handles /dev/random & /dev/urandom
differently than GnuTLS.

thanks for pointers..
but may be replacing gnutls may not be possible in short term on my setup.
I had also considered adding timer-entropyd https://www.vanheusden.com/te/
but didn't need to in the end.


Thanks for the response.