[Ubld.it Staff]

I’ve updated the zip file for the pro and it indeed had a subdirectory called Linux, that .rules file needs to be in the udev.d dir not in a subdirectory. So I’ve fixed the zip file. That should fix your problem.

Sorry about that.

[Ubld.it Staff]

Sorry for the late response, somehow this post snuck past us. Yes you can use /dev/ttyACM0, however, the udev.d script does more than just symlink to /dev/TrueRNG it makes sure the term settings are in raw mode. I’ve tested the TrueRNG (and TrueRNGPRo) under 15.04 and it works just fine. The only reason I could see that you don’t have /dev/TrueRNG is the scripts were unzipped to a subfolder. There is appears to be a subfolder in the zip file with the udev script, I’ll look into updating the script so the subdirectory isn’t there but I suspect that is your issue.

[Ubld.it Staff]

Sorry about that, the mdev question was something relating to OS support for the TrueRNG, where as the ssh-keygen and gpg questions involve digging through source code that we didn’t write, so they take a lot longer, and furthermore it’s tricky if we notice something and tell you bad info based on some application we didn’t write so we will try our best.

— this is assuming a normal Linux install with the udev/mdev rules and rngd running to seed /dev/random —

First, digging through GnuPG’s site, I came across an old FAQ here searching for dev/random i see questions such as “Why does it sometimes take so long to create keys? and them referring that they need random bytes from /dev/random service.

This is a good indication that gpg is actually using /dev/random for key generation.

next digging through the source code, we find the configure script as options on specifying the entropy gatherer… you can choose linux or egd entropy gathering daemon, and there is a reference that NetBSD needs to use /dev/urandom. [doesn’t segment pseudo and real random in random/urandom like Linux does].

So the ultimate question here is how was your gpg built? Looking to analyze my own gpg that came with Ubnuntu, I ran “gpg –gen-key” through strace and I do indeed see some indication of this;

I see a write system call to the screen saying “We need to generate lots of random bytes” [which you should be used to if you generate keys a lot], then I see a open system call opening /dev/random, and a read statement reading bytes.

While not definitive, it looks a lot like gpg is actually opening /dev/random and using it for key generation in my copy.

Now moving along to ssh-keygen, I start out trying to do the same thing, I come across the man page for ssh-keygen and it states here ssh-keygen man page that at the bottom it says there is an environment variable called “SSH_USE_STRONG_RNG” and states that by default it uses /dev/urandom which is pseudorandom, but you can set the environment variable to tell it to use /dev/random.

So I go to test this theory in the same manor. run ssh-keygen -f /tmp/foo with strace and look for /dev/random being opened. I don’t see any reference to either, but it does reference the fact it is obtaining its entropy from openssl libraries. I tried to do the SSH_USE_STRONG_RNG environment variable under my own install of Ubuntu, but that statement isn’t in my man page for ssh-keygen. A quick google search says that a lot of people are on the edge about OpenSSL not using /dev/random for entropy and there are various patches to rectify the subject.

So to make a summary, gpg is probably using true random entropy, and ssh-keygen is not. But neither one of these statements is 100% because of source fragmentation and distro-specific patches.

I hope this helps.

[Ubld.it Staff]

So sorry for the late reply, didn’t see this message until now. The BOM for the WIOT is on github — located here https://github.com/ubldit/WIOT/blob/master/Hardware/WIOT_BOM_Ubld_Electronics.pdf

the Lion charger is mcp73811 from microchip as you can see on the bom.

[Ubld.it Staff]

I must have had some other code in there that got taken out in the final version, I had gone through a few iterations of trying to implement a working system before the final version. The vid/pid check at the top is negative, since on the remove event the vid/pid doesn’t exist. So we wouldn’t want to put the add action in that branch.

The simplest thing to do would be to add a check to the bottom making sure the vid/pid are correct before doing the add [otherwise the whole script needs reworking]

which would look something like
if [ “$ACTION” = “add” ] && [“$VID” = “4d8” ] && [ “$PID” = “f5fe” ]; then
instead of
if [ “$ACTION” = “add” ]; then

I would have to test this change before updating the script in the package, but there is room for improvement there.

[Ubld.it Staff]

Cool article! Appreciate the post!

[Ubld.it Staff]

Do you have the modem-manager package installed by chance? It has a tendency to mess with the serial port looking for modems. I believe we added a blacklist rule to the old udev rules but maybe it isn’t working any more with the updated os.

[Ubld.it Staff]

Thanks for the update, We’ll have to review how we want to handle this change, but for now I’ll link this post.

[Ubld.it Staff]

Good idea, I’ll add it to the FAQ page.

[Ubld.it Staff]

At this time TrueRNG by its self does not support any sort of cryptography. It simply provides a steady stream of true random numbers that can be used in cryptography. We have had reports of people using a TrueRNG to wipe out hard disks, and as for a product like VeraCrypt, it would be possible for something like that to use the TrueRNG to gather random data, as there is a Windows driver, but at this point that does not exist.

[Ubld.it Staff]

What I think is going on here is the tty mode, for Linux we’re using a udev.d script that changes the term to RAW mode (using the stty command, e.g. stty /dev/ttyACM0 raw).
Try to do these steps manually for now and see if you have the same issue.
“/bin/stty raw -echo -ixoff -F /dev/insertTTYdevicenamehere”
It looks like we should be able to automate this with devd (appears to be closest thing to udevd in FreeBSD).

[Ubld.it Staff]

Jorge,

Please contact us via e-mail with your order number so we can start a support request. We’ll get you fixed up quickly. E-mail: support@ubld.it

ubld.it

[Ubld.it Staff]

We haven’t tried openSUSE specifically, but we don’t have any reason to believe there would be any issues, most modular kernels have the USB CDC driver module, and the rng-tools package available.
As for quantity discounts, there are some on tindie right now, there aren’t any on amazon at the moment.

[Ubld.it Staff]

Hey there Justin, I had responded to your comment on the blog post here. But to recap — That error is just because the rngcapture program is a little crude. Just use the actual number of the comport numerically. So use “5″ not “com5″ … ie. “rngcapture 5 test.txt 9600″ once again, sorry for the confusion, I realize the ‘listing’ feature shows com5 but it only wants the number for an argument.

[Ubld.it Staff]

We’ve traced down the popup message, it appears to be Windows 8.1 only (as Win 7 seems fine), but anyway rngcapture has been updated and appears to not pop the message up any longer. Just note this is a console application, when you run it with no arguments (and the error message popped up) it was trying to find your ports for you. When supplying the ports the error message didn’t appear and it captured the stream fine.

The link on the TrueRNG downloads section has been updated to 1.1. Here a link as well.

[Author]

Posts