I am running LMS (squeezebox) on my readynas ultra. There is a problem with the Random mix. The problem is that it isn't very random. The problem could be this that I have read about:
http://www.issihosts.com/haveged/
Is it possible to get Haveged to run on a ReadyNas. And if. How ?
If this really is a problem in the kernel software. Will this not be fixed ????
I am running LMS (squeezebox) on my readynas ultra. There is a problem with the Random mix. The problem is that it isn't very random. The problem could be this that I have read about: http://www.issihosts.com/haveged/
I thought that that was unlikely, and I was about to post a response saying so... But then I checked my Pro Pioneer's available entropy and discovered that it was REALLY low -- single digits or low double digits -- and I took those measurements while I was logged in and right after I'd performed some filesystem commands that should have produced a large increase in available entropy.
Maybe there's something on my system that is voraciously consuming entropy; I'll have to investigate further. But I guess it is possible that an additional entropy source like havege could be helpful.
On my Pro Pioneer running 4.2.24, after 7 hours of uptime, my first read was 3 and I never got a value above 120 bits even after lots of file-access-induced hardware randomness.
Chirpa, I notice that even with haveged running, each of your "cat" invocations seemed to consume around 100 bits of entropy. If you do something like "watch cat /proc/sys/kernel/random/entropy_avail" with haveged running, does the available entropy stay high (or refill when it gets below the read threshold), or does it fall all the way to single digits as it would without haveged?
/dev/random blocks while the entropy pool is low, so if haveged is not running you'll see random bytes being generated VERY slowly: a burst of 8 characters every few seconds, or even slower. With haveged running, random characters will be generated almost as fast as your terminal can display them.
Oh, and by the way... Going back to your original problem, it still seems odd that LMS should be affected by this issue.
I use MusicIP or Michael Herger's SmartMix plugins for my "random" mixes, so I haven't seen the problem you've described, but I would expect LMS to get its random numbers from /dev/urandom, which should be basically unaffected by the available entropy. The behavior you were seeing, though, seems to indicate that LMS is getting its random stream from /dev/random instead.
It might be worth posting a bug on the slimdevices (or logitech or whatever) bug tracker.
This is Slimdevices bug id 8310: http://bugs.slimdevices.com/show_bug.cgi?id=8310 With LMS 7.6.x I went trough the code and it used a default MySQL random feature, which (I'm sure) uses /dev/random or /dev/urandom. LMS 7.7.x and 7.8.x use SQLite, and I haven't checked how the random playlists are created.
Using /dev/urandom instead of /dev/random does not give you more randomness. If not enough random bits are available /dev/urandom will reuse the random bits to generate more pseudo random bits. This will likely cause repeats like the ones we were seeing with LMS. See http://en.wikipedia.org/wiki//dev/random
I have been running haveged on my QNAP TS-459 Pro+ for a week now, and it positively solves this issue.
Using /dev/urandom instead of /dev/random does not give you more randomness.
Thank you, RichieB. I shouldn't post at 4:00 in the morning.
I think that what I wanted (and failed) to say was that I would expect LMS to seed its own (long period) PRNG from dev/random or dev/urandom just once, but that instead it looks as though it is using dev/urandom directly, or maybe re-seeding its PRNG repeatedly with the same value from /dev/random.
RichieB wrote:
With LMS 7.6.x I went trough the code and it used a default MySQL random feature, which (I'm sure) uses /dev/random or /dev/urandom. LMS 7.7.x and 7.8.x use SQLite, and I haven't checked how the random playlists are created. .... I have been running haveged on my QNAP TS-459 Pro+ for a week now, and it positively solves this issue.
If 7.7 and 7.8 use sqlite's built-in random() function to select a random sequence of rows, I don't see how increasing the available entropy would fix the problem. As far as I know, the random() function returns the output of a PRNG based on RC4 which is seeded only once from /dev/urandom.
But I'm no expert on any of this. I guess the important thing is that it works, not why it works.
I took another look at the code (current 7.8 nightly). In Slim/Plugin/RandomPlay/Plugin.pm on line 571 this funtion is called: Slim::Utils::OSDetect->getOS()->sqlHelperClass()->randomFunction() In Slim/Utils/SQLiteHelper.pm on line 229 this funtion is defined as 'RANDOM()'. So it indeed (still) uses the internal SQL random function. A quick look at the sqlite 3.8.1 source code indeed mentions a PRNG implementation in the comments. Very strange.
Ok, got it. winRandomness() in sqlite3.c is a PRNG, but unixRandomness() uses /dev/urandom every time. This makes sense to me.. why use your own PRNG when the OS provides one that potentially is a lot better.
I don't have an OS6 box, so I can't tell. (And, of course, the addon I built for OS4 won't work on OS6 anyway; if you wanted to install haveged, you'd have to do so manually or by building an OS6 addon.)
F.L. wrote:
Running cat on entropy_avail I´m getting pretty high values compared to what I had on OS4 before.
or run this and see whether the stream of random hex values scrolls continuously up the screen:
hexdump /dev/random
If the number displayed by the first test falls to a low number and stays down in a low range, or if the stream in the second test pauses for a second or more after every line, your machine's entropy pool is easily depleted and might benefit from the installation of haveged.
gives me low values too. Wonder why I had high values before...
If nothing is using dev/random or dev/urandom, the entropy pool gradually fills. Presumably, your system wasn't doing much that needed random numbers, so the pool filled to 2000+ bits.
Every time a new process is launched, the operating system reads from dev/urandom in order to randomize the process's address space layout (to protect from buffer overflow attacks), so when you repeatedly invoked cat once per second with that watch command, the available entropy decreased faster than it could be replenished.
gives me low values too. Wonder why I had high values before...
If nothing is using dev/random or dev/urandom, the entropy pool gradually fills. Presumably, your system wasn't doing much that needed random numbers, so the pool filled to 2000+ bits.
Every time a new process is launched, the operating system reads from dev/urandom in order to randomize the process's address space layout (to protect from buffer overflow attacks), so when you repeatedly invoked cat once per second with that watch command, the available entropy decreased faster than it could be replenished.
