• Home
  • Help
  • Search
  • Login
  • Register
  Show Posts
Pages: [1]
1  Linux Stuff / Kernel / Re: Problem with /dev/random ? on: August 02, 2009, 03:19:09 AM
Thanks for the suggestion. I still see two problems with, though: the overhead (perl) and the need to patch/recompile/reconfigure any application in need of entropy. I had found other similar projects since yesterday, that almost all had the same issues. Some were interesting, though.

I think I have found a nice solution, in the form of a small daemon that directly feeds the system driver with entropy bits. They are generated from small variations in timing measures. It is written in C, has a very small memory footprint, and seems to work well. The same guy also proposes similar drivers using audio or video data as input, but since I'd rather not add hardware to the setup...

Main site: http://www.vanheusden.com
Timer based daemon: http://www.vanheusden.com/te/  << the winner
Audio based daemon: http://www.vanheusden.com/aed/
Video based daemon: http://www.vanheusden.com/ved/

So, as far as I am concerned, I have found a solution to my problem. The underlying issue of a stock kernel driver not being fit for embedded systems remains, though...
2  Linux Stuff / Kernel / Re: Problem with /dev/random ? on: August 01, 2009, 01:47:04 PM
Wow! Not cheap, indeed... And maybe a bit overkill. Isn't there really any compromise between no randomness and tripling the price of the hardware?!

I mean, this will become a real issue for this kind of embedded devices, since I predict a massive growth in the use of encryption technology by Joe Average, due to the arrival of IPv6 (IPSec, DNSSEC...) and of a bunch of upcoming braindead laws that mistake the knife (P2P) with the criminal.

At least, could someone explain to me how I can find whether this situation is due to a lack of network activity or a random device badly configured by default?
3  Linux Stuff / Kernel / Re: Problem with /dev/random ? on: July 31, 2009, 03:51:56 PM
Unfortunately, the fact that /dev/urandom always spit out as many bytes as it is asked does not mean that it works correctly. I had thought about that after I started reading about /dev/random and /dev/urandom, but as a matter of fact it is not a real solution: no entropy means the output of /dev/urandom would be anything but random. It would not be merely inferior to /dev/random, it would be theorically useless.

Further reading suggests that my setup (more precisely named) burns its entropy bits faster than it produces them. And that it may be a recurrent issue with such embedded systems. As it is, it may only rely on network activity for its entropy source: no keyboard, no mouse, etc... And I am not even sure that it does tap network. I also found a package adding the sound card as an entropy source. I might do just that, eventually: a USB sound card with a mic somewhere near the kitchen appliances...

But since it is a well known issuer, I trust people to give me pointers to the well known solutions Wink
4  Linux Stuff / Kernel / Re: Problem with /dev/random ? on: July 31, 2009, 03:14:14 PM
xavier@majipoor:/# cat /proc/sys/kernel/random/entropy_avail
0

Well, this does explain a lot. I read a bit about the functiong of /dev/random since posting, and I am not surprised that it blocks if its entropy store is empty.

Now, the next questions are why is it empty, and how can I change that?..
5  Linux Stuff / Kernel / Problem with /dev/random ? on: July 31, 2009, 02:59:33 PM
Hello all,

I had an issue, when setting a DNS server on my plug, with rndc-config that just hung up in the air doing nothing. It behaved as if blocked on an I/O.
So I had a shot at lsof...

xavier@majipoor:~$ rndc-confgen & lsof | grep rndc
[1] 1930
rndc-conf 1930 xavier  cwd       DIR  253,1     600 41339 /home/xavier
rndc-conf 1930 xavier  rtd       DIR  253,1    1312     1 /
rndc-conf 1930 xavier  txt       REG  253,1   13912 41845 /usr/sbin/rndc-confgen
rndc-conf 1930 xavier  mem       REG  253,1  121628  1140 /lib/ld-2.9.so
rndc-conf 1930 xavier  mem       REG  253,1 1251072 41787 /usr/lib/libdns.so.45.0.4
rndc-conf 1930 xavier  mem       REG  253,1  146496  1914 /usr/lib/libgssapi_krb5.so.2.2
rndc-conf 1930 xavier  mem       REG  253,1 1210776 17449 /lib/libcrypto.so.0.9.8
rndc-conf 1930 xavier  mem       REG  253,1  305628 41805 /usr/lib/libisc.so.45.0.3
rndc-conf 1930 xavier  mem       REG  253,1   13800  1224 /lib/libcap.so.2.11
rndc-conf 1930 xavier  mem       REG  253,1   75664  1431 /lib/libnsl-2.9.so
rndc-conf 1930 xavier  mem       REG  253,1  114725  1314 /lib/libpthread-2.9.so
rndc-conf 1930 xavier  mem       REG  253,1 1200748 19669 /usr/lib/libxml2.so.2.6.32
rndc-conf 1930 xavier  mem       REG  253,1 1201672  1322 /lib/libc-2.9.so
rndc-conf 1930 xavier  mem       REG  253,1   50816  1231 /lib/libgcc_s.so.1
rndc-conf 1930 xavier  mem       REG  253,1  498400  1864 /usr/lib/libkrb5.so.3.3
rndc-conf 1930 xavier  mem       REG  253,1  149116  1948 /usr/lib/libk5crypto.so.3.1
rndc-conf 1930 xavier  mem       REG  253,1    9648  1327 /lib/libcom_err.so.2.1
rndc-conf 1930 xavier  mem       REG  253,1   26360  1548 /usr/lib/libkrb5support.so.0.1
rndc-conf 1930 xavier  mem       REG  253,1    9744  1219 /lib/libdl-2.9.so
rndc-conf 1930 xavier  mem       REG  253,1    4948  1138 /lib/libkeyutils-1.2.so
rndc-conf 1930 xavier  mem       REG  253,1   71460  1311 /lib/libresolv-2.9.so
rndc-conf 1930 xavier  mem       REG  253,1   83612  1417 /lib/libz.so.1.2.3.3
rndc-conf 1930 xavier  mem       REG  253,1   13520  1220 /lib/libattr.so.1.1.0
rndc-conf 1930 xavier  mem       REG  253,1  673316  1335 /lib/libm-2.9.so
rndc-conf 1930 xavier    0u      CHR   4,64           498 /dev/ttyS0
rndc-conf 1930 xavier    1u      CHR   4,64           498 /dev/ttyS0
rndc-conf 1930 xavier    2u      CHR   4,64           498 /dev/ttyS0
rndc-conf 1930 xavier    3r      CHR    1,8           816 /dev/random

From what I could see, the obvious suspect was /dev/random, so I tried a simple cat /dev/random , which dave nothing. /dev/random does not output anything. I am not an expert of the /dev/random* devices but I can see that /dev/random DOES output random characters on my linux workstation. Moreover, asking rndc-confgen to use keyboard input to generate cryptographic keys made it work like a charm, what confirm what I thought.

The plug has been upgraded to kernel 2.6.30-rc6 / ubuntu 9.04 through the alpha 6 installer, and been kept up to date since using aptitude. I did not try using rndc before that so I cannot tell whether the stock kernel shows the same behaviour. I just upgraded to 2.6.30.3 (found on these fora) and the result is the same.

/dev/urandom seems to be working fine, curiously.

Any idea to fix/work around this, anyone?
6  Linux Stuff / General Linux questions / Re: [Cross-] compiling applications for SheevaPlug on: July 29, 2009, 01:27:42 AM
Maybe the temporary files which occur during a compilation could be putted on a RAM disk.

The easiest way to achieve that is to modify your makefiles to make use of the -pipe option for gcc. It makes tools of the build chain use unix pipes instead of temporary files to exchange data. However, this is only efficient is this case if your whole build chain (os + CLI + compiler + temporary data) fits into the physical memory. Otherwise it will translate into swap I/Os and every benefit you could hope for is lost.

So, basically, it is probably better to cross-compile if you intend to compile anything even remotely useful. I agree with Ergeist on that.
7  Hardware and U-Boot firmware / Hardware / Re: Loose mini-USB connector on: July 23, 2009, 01:04:10 PM
I also thought that the mini-USB connector was too loose at first. I also believed it was the fault of the casing that would prevent the plug to go deep enough, and tried another cable with a thinner plug. Eventually I found that there is absolutely NO problem with this connector.

In the end, it's just a metter of pushing hard enough, and everything clicks in place. Loudly and firmly. very loudly, and very firmly. Firmly enough for most people to be shy from pushing hard enough.
8  Linux Stuff / Kernel / Re: 2.6.30.1 new release on: July 23, 2009, 02:58:58 AM
And it's only now that I realize that the "IPV6: sheeva6" link means "from an IPv6 network" and not "with IPv6 support". No surprise there is no DNS resolution from the IPv4 InterWeb.

Ah well... It's not the first time and probably not the last time I make a fool of myself in public. Keeps one humble. *sigh*
9  Linux Stuff / Kernel / Re: 2.6.30.1 new release on: July 22, 2009, 01:24:16 PM
OK, I understand now. It's not a global DNS problem. It just happen that until this afternoon I always had tested with "sheeva6.with-linux.com", since I am interested in IPv6. "with-linux.com" is known and "sheeva" is properly resolved, but "sheeva6" does not exist.

A quick look at sheeva-2.6.30.1.config shows that the reachable kernel is compiled with IPv6 enabled as a module, so ultimately all is fine for me. This explains why the second link is dead. You might want to remove it altogether. Unles it is intended for a kernel image with IPv6 compiled in, instead of as a module?

As a matter of fact, it would probably be better compiled in, for me. Guess I'll have to go the cross-compiling way...
10  Linux Stuff / Kernel / Re: 2.6.30.1 new release on: July 22, 2009, 07:57:19 AM
It was really a DNS error (checked manually with "nslookup" and/or "host", at work and from home), and it has been so since at least yesterday, maybe monday (can't remember precisely when I started to look into upgrading my kernel for IPv6 support).

Checking right now, I discover that it is working again from my office.

Except that it is no use to me here :-) I will try again from home this evening. I suspect something's been temporarily amiss between French ISPs' DNS and yours. Thanks for checking on your side, anyway.
11  Linux Stuff / Kernel / Re: 2.6.30.1 new release on: July 22, 2009, 05:13:08 AM
Hello.

I would just like to report that the links at the beginning of this thread are dead (DNS error, no such thing as with-linux.com)...
Pages: [1]