What status error are you getting in CWM? Tried replacing the update binary?
Works great using TWRP
Sent from my SAMSUNG-SGH-I717 using xda premium
What status error are you getting in CWM? Tried replacing the update binary?
Should I uninstall the apk before flashing the zip?
Sent from my GT-I9000
Came across this today. Looks really promising.
Interesting thing is we had an issue in office where Oracle database connections were getting hung due to same reason, waiting on /dev/random as entropy pool wouldn't get filled up in a VM in a data center. Entropy gets generated from noise which is hard to find in a data center. We had to use a similar solution.
What we had done is link /dev/urandom to /dev/random.
I'm curious, maybe is a better solution than this script... Can you make a script that work the same way you fix the problem in oracle database connections, but for android?
installed v5 via cwm.
how can i check if its running or not via terminal emulator?
Not sure if that's a good idea for several reasons:
- /dev/urandom is actually a "non-blocking pseudo-random" virtual device; in other words, the entropy generated by /dev/urandom is *much* more guessable than the entropy from /dev/random.
rngd's purpose is to -- every now and then (set by the -t parameter) -- pulls a number of bits from /dev/urandom (set by the -s parameter) and feed those bits into /dev/random. Since /dev/random is *still* being repopulated on its own (even slowly), there is still a quite strong 'mixing' of strong-random-numbers (by /dev/random itself) and weak-pseudorandom-numbers (pulled by rngd from /dev/urandom).
So, linking /dev/random to /dev/urandom will render your phone much more 'tappable' ('tap' as in 'wiretap', except we're talking radio waves here, so 'wirelesstap').
.
- I'm not really sure about it, but we can be in for a *lot* of trouble if some security-oriented Android Framework component 'balks' if it detects that /dev/random is not really a 'device node' but a symlink. You'll effectively soft-brick your phone.
nice update Ryuinferno.
thanks..from v4 o v
Great script v3 worked great but v5 is even better with ability to check it out in terminal emulator just typing"seeder"
Thanks! Clear answer! But if i don't care about being 'tappable' can i give it a try? How can i make a symlink of /dev/random to /dev/urandom?
Btw, the soft-brick isn't so dangerous because i can simply flahs the backup over..
ln -s /dev/urandom /dev/random
No luck...I tried
Both at runtime and as a init.d script...does not work...Code:ln -s /dev/urandom /dev/random
Ok guys...I changed the way the zip mounts system...it now uses temporary busybox...should suit more devices now...but if nothing is applied (e.g. you type "su", "seeder" in terminal but error shows), then you have to mount system manually in recovery...Here's the new Seeder_v5.zip, no changes, no need to reflash for the current users...
Download: http://www.androidfilehost.com/?fid=9390248398092763238
No luck...I tried
Both at runtime and as a init.d script...does not work...Code:ln -s /dev/urandom /dev/random
Ok guys...I changed the way the zip mounts system...it now uses temporary busybox...should suit more devices now...but if nothing is applied (e.g. you type "su", "seeder" in terminal but error shows), then you have to mount system manually in recovery...Here's the new Seeder_v5.zip, no changes, no need to reflash for the current users...
Download: http://www.androidfilehost.com/?fid=9390248398092763238
I get this after flashing the latest version .
Seeder entropy generator n
run at boot?:yes
Init d:seeder (exist)
Does this mean its working ?by the way i also have v6 & kick ass in my init d any conflicts or should i remove them ?
Thank you
It really works
Most of time no lag when I open messages.
Sometimes still a short time to load. (reason?)
Definitely faster than before.
Thanks :thumbup:
send from HTC Sensation XE on ViperS 1.5.2 ROM 32gb class10 using Tapatalk
su
seeder
su
cd /sdcard/install
sh install.sh
su
cd /sdcard
sh uninstall.sh
watch -n 1 cat /proc/sys/kernel/random/entropy_avail
pgrep rngd
su
seeder
su
cd /sdcard/install
sh install.sh
su
cd /sdcard
sh uninstall.sh
busybox sysctl -e -w kernel.random.read_wakeup_threshold=128;
busybox sysctl -e -w kernel.random.write_wakeup_threshold=256;
while :; do cat /proc/sys/kernel/random/entropy_avail; sleep 1;done
busybox sysctl -w kernel.random.read_wakeup_threshold=2048
echo 1366 > /proc/sys/kernel/random/read_wakeup_threshold
busybox sysctl -w kernel.random.read_wakeup_threshold=1366
busybox sysctl -e -w kernel.random.read_wakeup_threshold=1024;
busybox sysctl -e -w kernel.random.write_wakeup_threshold=2048;
Ok, I have a question for the OP:
I would like to know your through process that led up to the development of this patch. Was this just instinct or did you have a hint? Did you use a profiler of some sort? I'm just incredibly curious how on earth you arrived at the 'problem' before developing your 'solution'!