TrueRNG on Mac OSX 10.9

[Anonymous]

I got TrueRNG to run under OSX using old school cu:

sudo cu –nostop -l /dev/cu.usbmodem141 -s 230400 | dd conv=notrunc count=1m bs=64 of=random.bin

There is couple short comings with this approach
– after output stops you still need to manually terminate cu connection by sending ‘~’ and then ‘.’
– after getting one batch of results (dd count run) all the following calls wont produce any input. could it be because cu sets DTR to false at the end and doesn’t reset on subsequent calls?

that prevents me from writing script that will automatically collect say 1gb files and repeat the process 100s times to slowly fill up external drive with entropy (to be used by other apps)

Anybody found better solutions for Mac OSX?

[Ubld.it Staff]

Just doing
dd if=/dev/cu.usbmodem141 of=random.bin count=1m bs=64
appears to work just fine in mavericks, you don’t need to run it through cu to use the cu device as a interface to dd. And I tried it with multiple counts and block sizes, and let it run in a while loop for awhile and I didn’t have any issue.

[Anonymous]

Thanks! that is indeed much simpler and works great with loop scripting.

[philip]

Hello! I received a TrueRNG device last week, and it doesn’t behave like it should according to this thread. On Mavericks (10.9.2), the only way I can get output is by using minicom or picocom. (Picocom works even with arguments --noinit --noreset.) When I try cat or dd on the device, I never get any output.

Additionally, Picocom and Minicom both work correctly just once per insertion of TrueRNG into a USB port. So the first time I read from the device, I can read an unlimited stream of data, just as expected. The second time, I read some number of bytes (<1 MB), and the output stops forever. The third time and every subsequent time (if I close and reopen picocom), I get no output. When I unplug and replug the device, the whole thing repeats.

I posted about this problem on the Unix StackExchange, so please feel free to answer it there: http://unix.stackexchange.com/questions/126688/reading-from-serial-port-in-the-simplest-way

Thanks!

[Ubld.it Staff]

It’s possible that minicom/picocom are setting flow control characters on the tty. Since the TrueRNG’s output is random, it randomly will push out any byte which may be a control character if the tty is set for that sort of thing. Are you using /dev/tty.usbmodem[12345] or are you using /dev/cu.usbmodem12345 with dd/cat ? The difference I believe is cu. asserts DTR which is implemented on the TrueRNG as flow control (DTR on meaning you are ready for data).

Try doing a fresh plug/unplug (that will reset any flow control I hope), then without opening the port with any terminal program do cat /dev/cu.usbmodem[12345 whatever or tab completion] > testfile and see if it works.

Here’s some more info on the difference between tty.usbmodem and cu.usbmodem

https://stackoverflow.com/questions/8632586/macos-whats-the-difference-between-dev-tty-and-dev-cu

I’ve just always known cu.usbmodem to be the way to go as it’s not a real tty, and this is true for other usb-serial devices like FTDI chips in Arduino’s etc.

[philip]

Thanks, that did the trick! I appreciate the quick response!

[Author]

Posts