Pine64 + USB drive

It looks like a crazy ball of string and rubber bands now. I added an external SSD in an enclosure powered by the compatible JMS578 chipset. But the board itself cannot supply enough power through USB to external drivers, so there’s also a powered USB hub (thus the whole thing needs two power supplies).

It works is the best I can say about it at this point.

Important edit: I discovered that the powered USB hub is not necessary (presumably because this is an SSD, not a spinning disk). That eliminates the power supply problem.

USB Per Port Power Switching

Increasing numbers of single board computers are powered by USB ports using a cable like this:

Wouldn’t it be cool if you could plug these into a USB hub and have the hub individually power up and down the computers? Like a cheap APC power management board.

It turns out you can — with difficulty. The USB standard defines Per-Port Power Switching (PPPS) but unfortunately almost no hub in existence actually supports it. To save a few cents on the BOM, the manufacturers generally leave out the extra power transistors needed to make it work. One guy has modified his USB hub to add the extra part and full marks to him but that’s a lot of effort.

There is one hub which actually supports this: The D-Link DUB-H7, but only the first version (the silver/grey case). In the second version (black case), D-Link too realized their “mistake” and saved on the extra bits.

Armed with this knowledge, I bought one of these from the US (shipping cost 3x the cost of the hub itself).

And it works! Well, for a while.

I used the C hub-ctrl program from this page, and the instructions from here.

# lsusb
...
Bus 003 Device 005: ID 2001:f103 D-Link Corp. DUB-H7 7-port USB 2.0 hub

Switch off port 7 (right-most port):

# ./hub-ctrl -b 3 -d 5 -P 4 -p 0

Switch on port 7:

# ./hub-ctrl -b 3 -d 5 -P 4 -p 1

The ports are not numbered in the same sequence as the ports on the hub itself. I found by experimentation that the ports correspond as follows. I don’t know if it’ll be the same on every model:

Port	hub-ctrl option
1 (left)	-P 5
2	-P 6
3	-P 1
4	-P 2
5	-P 7
6	-P 3
7 (right)	-P 4

The bigger problem is the hub is fairly unreliable. Switching ports on or off too frequently seems to result in the hub crashing, which appears to only be recoverable by powering the hub off for several seconds.

So I’m not quite there.

Making a serial cable for the ODROID XU

As I’ve said before, developer boards should come with all the bits, and a UART is essential for development on ARM.

I built my own using the jump leads from an unused CP2102, and this 1.8v FTDI serial to USB cable purchased previously.

The ODROID-XU board has a four pin Molex-type UART connector. The pin-out is: 1 = Power (do not connect), 2 = RX, 3 = TX, 4 = Ground. Pin 1 has the triangular notch on the outside of the connector. In the photo above, black is connected to pin 4 (ground), blue is connected to pin 3 (TX), and purple is connected to pin 2 (RX).

The FTDI cable has: Black = ground, Yellow = RX, Orange = TX.

Normally I would swap RX & TX in the cable, but that didn’t work here, so as you can see I’ve connected RX-RX, TX-TX straight through.

The photograph shows the connection before I wrapped the whole lot in many layers of black electrical tape.

Tip: Convert a Windows DVD ISO to a bootable USB key using guestfish

Situation: You have a Windows DVD (or ISO), but like any sane person in 2013 you don’t have a DVD drive on the computer. You want to convert the Windows DVD into a bootable USB key. There are many recipes for this online, but they all require another Windows machine and of course cannot be automated.

However with guestfish (and the always brilliant SYSLINUX doing most of the heavy lifting), this script will unpack the ISO and turn it into a bootable USB key.

Notes:

1. I am not going to support this script. You will need to read the script, look up the commands in the guestfish man page, and understand what it does. Any requests for help will be deleted unread.
2. You need to edit the USB key device before using the script.
3. You need libguestfs ≥ 1.21 with SYSLINUX support compiled in.

#!/bin/bash -

guestfish <<'EOF'
trace on

add-ro en_microsoft_hyper-v_server_2012_x64_dvd_915600.iso

# NB: The next line MUST be changed to your USB drive.
# ANYTHING ON THIS DRIVE WILL BE OVERWRITTEN WITHOUT WARNING.
add /dev/sdX

run

# Inside the appliance, /dev/sda = DVD, /dev/sdb = USB.
# THESE ARE NOT RELATED TO HOST DISK NAMES.

echo "Partitioning the USB disk ..."
part-init /dev/sdb mbr
part-add /dev/sdb p 63 -1
part-set-mbr-id /dev/sdb 1 0xb
part-set-bootable /dev/sdb 1 true
mkfs vfat /dev/sdb1

echo "Copying the contents of the DVD to the USB key ..."
mkmountpoint /cd
mkmountpoint /usb
mount /dev/sda /cd
mount /dev/sdb1 /usb
# XXX We should add cp-r command XXX
debug sh "cp -rP /sysroot/cd/* /sysroot/usb"
#glob cp-a /cd/* /usb
umount /cd
umount /usb
rmmountpoint /cd
rmmountpoint /usb

echo "Making the USB key bootable using SYSLINUX ..."
syslinux /dev/sdb1
mount /dev/sdb1 /
upload /usr/share/syslinux/chain.c32 /chain.c32
write /syslinux.cfg "DEFAULT windows\n\nLABEL windows\nCOM32 chain.c32\nAPPEND fs ntldr=/bootmgr\n"
umount /dev/sdb1
upload /usr/share/syslinux/mbr.bin /dev/sdb

echo "Finished."

EOF

Real cheap Software Defined Radios?

It seems someone worked out that the Realtek RTL2832U found in various very cheap USB DVB-T decoders can be repurposed as a complete software-defined radio. The sidebar of this subreddit seems to be the best place to start.

Update: This is the Ezcap EZTV645 from Deal Extreme:

[175189.929963] usb 1-1.1: new high-speed USB device number 7 using ehci_hcd
[175190.028379] usb 1-1.1: New USB device found, idVendor=0bda, idProduct=2838
[175190.028385] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[175190.028389] usb 1-1.1: Product: RTL2838UHIDIR
[175190.028392] usb 1-1.1: Manufacturer: Realtek

Bus 001 Device 007: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T

guestfish — not just for disk images

You know you can run libguestfs / guestfish on anything, right? This question came up at one of the Summit parties, so maybe some people don’t know. But it works on USB keys, CDs, hard disks, partitions, and files (and more).

There is a practical benefit to using libguestfs on USB keys, because it adds a layer of isolation between the unknown contents of the USB key and your host kernel. Mounting random disks on your host kernel is deeply insecure.

In the example below, I’ve stuck in a random USB key (empty and safe as it happens, but how was I to know?) and I ran guestfish on the first partition directly:

$ guestfish -a /dev/sdb1

Welcome to guestfish, the libguestfs filesystem interactive shell for
editing virtual machine filesystems.

Type: 'help' for help on commands
      'man' to read the manual
      'quit' to quit the shell

><fs> run
 100% ⟦▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉⟧ 00:00
><fs> mount-options "" /dev/vda /
><fs> ll /
total 36
drwxr-xr-x  2 root root 32768 Jan  1  1970 .
drwxr-xr-x 24  500  500  4096 Jul  9 17:11 ..
><fs> df-h
Filesystem            Size  Used Avail Use% Mounted on
/dev/vda              3.7G   32K  3.7G   1% /sysroot

(I don’t need to be root, because I’ve added myself to the “disk” group, which means I can access any block device.)

Above, I ran guestfish on the USB key’s first partition (/dev/sdb1, so that inside libguestfs the partition appears as a whole device (/dev/vda). Equally I could have run guestfish on the whole USB key (/dev/sdb), in which case libguestfs would see and be able to manipulate the partition table too.

Yubikey arrived

It arrived this morning, about 20 hours after I placed the order. I haven’t had a chance to do anything other than plugging it in yet.

usb 1-1.1: new low speed USB device using ehci_hcd and address 5
usb 1-1.1: New USB device found, idVendor=1050, idProduct=0010
usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1.1: Product: Yubico Yubikey II
usb 1-1.1: Manufacturer: Yubico
input: Yubico Yubico Yubikey II as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0/input/input9
generic-usb 0003:1050:0010.0001: input,hidraw0: USB HID v1.11 Keyboard [Yubico Yubico Yubikey II] on usb-0000:00:1a.0-1.1/input0

lsusb output:

Bus 001 Device 005: ID 1050:0010 Yubico.com Yubikey

Pressing the one button on the yubikey sends a string of random letters (as if typed on the keyboard or another USB input device). The string is different each time.

That’s all for now folks!

USB Hardware Random Number Generator

This is a USB Entropy Key, cost £42 inc VAT and delivery from a company up in Lancashire.

usb 2-1: new full speed USB device using uhci_hcd and address 2
usb 2-1: New USB device found, idVendor=20df, idProduct=0001
usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 2-1: Product: Entropy Key
usb 2-1: Manufacturer: Simtec Electronics
usb 2-1: SerialNumber: M/xxx

I can report that it works fine in Fedora 13 with the open source daemon provided. The entropy can be collected in a file, passed to egd, but by default it is added to the kernel entropy pool for use by /dev/random and things like ASLR.

I love how overengineered (yet cheap) this thing is. From the documentation:

“The Entropy Key uses P-N semiconductor junctions reverse biased with a high enough voltage to bring them near to, but not beyond, breakdown in order to generate noise. In other words, it has a pair of devices that are wired up in such a way that as a high potential is applied across them, where electrons do not normally flow in this direction and would be blocked, the high voltage compresses the semiconduction gap sufficiently that the occasional stray electron will quantum tunnel through the P-N junction. (This is sometimes referred to as avalanche noise.) When this happens is unpredictable, and the occurrence of these events is what the Entropy Key measures.

These noise generators are then coupled to a 72MHz ARM Cortex-M3 CPU on the device. This processor samples the generators at a high frequency, forming a stream of random bytes. These streams of bytes are then analyzed using Ueli Maurer’s universal test for random bit generators whereby the amount of entropy in the streams is estimated rather conservatively. The streams are also exclusive-ORed together and that stream’s entropy is estimated in the same manner. If the raw streams appear to have severely reduced entropy then it indicates a fault in that generator, if the third stream has low entropy then it indicates that the generators have correlated and are not independently gathering entropy. Any of those three states are considered a failure mode and will result in the eKey locking itself out of the host, returning only an error code instead of generating entropy packets.

The two raw streams are then processed further in a de-biasing process invented by John von Neumann. Their entropy is estimated after the de-biasing process has been performed. Again, if the estimated entropy in the streams is seen to vary too wildly at this stage, the Entropy Key will lock itself out. The processed streams are then mixed into a pool made with a secure hashing function. Once at least 50% more (estimated) entropy has been mixed into the pool than it could possibly hold it is finalised and another pool initialised. Once enough pools have been processed to fill 20000 bits, the totality is subjected to the tests stipulated in FIPS 140-2. These tests produce a PASS/FAIL indicator for the block. On its own, this is not useful, since a perfectly random block could quite plausibly fail the tests. The Entropy Key therefore keeps running statistics on the FIPS 140-2 tests and will lock itself out if the ratio of failed blocks to passed blocks rises above a conservative estimate of the statistical likelihood of failure.

Once the block has been analysed, regardless of its PASS/FAIL indication, it is chopped up into 32 byte packets and these are handed off to the protocol handler in the device. Through this process therefore, each 256 bit block of data handed to the host was formed from somewhere in the region of between 3000 and 5000 bits read from the generators.”