Tagged: mac osx cu serial_port dd
April 12, 2014 at 4:24 pm #624
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?April 14, 2014 at 11:50 pm #671
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.April 18, 2014 at 4:45 pm #684
Thanks! that is indeed much simpler and works great with loop scripting.April 28, 2014 at 1:32 am #717
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
picocom. (Picocom works even with arguments
--noinit --noreset.) When I try
ddon 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!April 28, 2014 at 12:12 pm #718
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 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
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.April 29, 2014 at 1:46 am #719
Thanks, that did the trick! I appreciate the quick response!
You must be logged in to reply to this topic.