Focusrite Scarlett 6i6 and Pulseaudio

Oh, pulseaudio, how do I love thee...

The Focusrite Scarlett 6i6 is a 2 Mic, 2 Line, 2 Digital input, 4 Line, 2 Digital output audio interface and is presented to the Linux machine as a 12 output, 6 input USB2.0 class compliant soundcard. Strange, but that's what it is. Now, pulseaudio, not very smart in the first place, gets confused and only ever wants to use this card as a "multichannel" output, with outputs 1/2 deprived of bass, and output 6 (typically mapped to the s/pdif output) being a subwoofer. Not useful when listening over headphones.

After looking through the non-existing pulseaudio-documentation regarding udev, and searching on the web, I've came up with a workaround. This is at least useful to use the card as a normal stereo output.

To get output on the 2nd headphone output, use alsamixer to map Master 2L and Master 2R source to PCM1 and PCM2. The same applies to the S/PDIF output (Master 3L/R).

Bug filed.

➜  ~  cat /usr/share/pulseaudio/alsa-mixer/profile-sets/focusrite-scarlett-6i6.conf 
; Based on native-instruments-traktor-audio10.conf

;
; Focusrite Scarlett 6i6 has 6 physical inputs/outputs
; Inputs
;  2x  Microphone/Line on front
;  2x  Line on back
;  2x  S/PDIF coaxial on back
; Outputs
;  2x  Headphone (Out1/2, Out 3/4) on front
;  2x  Line on back (Out 1..4)
;  2x  S/PDIF coaxial on back
;
; It's presented as a 6 input, 12 output interface to the PC, so
; we have to create some mappings. Actual routing is configurable
; in ALSA mixer. I prefer a 1:1 mapping to physical outputs.
;

[General]
auto-profiles = no

[Mapping analog-out]
description = Analog Outputs
device-strings = hw:%f
channel-map = left,right,aux0,aux1,aux2,aux3,aux4,aux5,aux6,aux7,aux8,aux9

[Mapping analog-in]
description = Analog Inputs
device-strings = hw:%f
channel-map = left,right,aux0,aux1,aux2,aux3
direction = input


[Profile output:analog-out+input:analog-in]
description = Analog Duplex
output-mappings = analog-out
input-mappings = analog-in
priority = 100
skip-probe = yes

➜  ~  cat /etc/udev/rules.d/99-pulseaudio-local.rules 

SUBSYSTEM!="sound", GOTO="pulseaudio_local_end"

ACTION!="change", GOTO="pulseaudio_local_end"

KERNEL!="card*", GOTO="pulseaudio_local_end"

SUBSYSTEMS=="usb", GOTO="pulseaudio_local_check_usb"

LABEL="pulseaudio_local_check_usb"

##

# The Focusrite Scarlett 6i6 only runs as 12 playback and 6 capture channels!

# (mappable using the internal mixer)

# Bus 002 Device 004: ID 1235:8012 Focusrite-Novation Scarlett 6i6

##

ATTRS{idVendor}=="1235", ATTRS{idProduct}=="8012", ENV{PULSE_PROFILE_SET}="focusrite-scarlett-6i6.conf"

LABEL="pulseaudio_local_end"

Behringer "X-Air" XR18 Teardown

Here's a teardown of a Behringer XR18 (sometimes spelled X18R) Compact Digital Mixer. There's a full album with all pictures I took.

To open the device, you have to remove the rubber bumpers on the sides (which can be replaced with rack-ears). Two of the tiny screws on each side don't have to be removed, this lets the bottom shell of the case keep more mechanical strength. Then two halves slide open, an L-shaped top-plus-front-side part, and the rest enclosing sides, bottom and back side.

From Behringer XR18 Teardown

In the inside, you can find the power supply, a digital board (+ analog outputs) and a stack of three boards mainly responsible for the analog mic/line inputs. The topmost board (which I didn't remove because it's attached to the case by all the XLR connectors) mainly has connectors and the headphone amp. The middle board carries circuitry for the actual mic preamp. The bottom board has a few opamps and the ADCs for the analog inputs.

From Behringer XR18 Teardown

Power Supply

Generally the manufacturing is pretty nice and everything looks produced to tight tolerances. I could see no gaps, nothing loose. The only downside I see is the powersupply and the mains connector: The supply gets very hot during normal operation (and no devices running on phantom power were connected during the few hours it was in operation before opening the case). The mains connector is isolated with an additional layer of sticky tape, and fastened with hot glue. This looks rather sloppy.

From Behringer XR18 Teardown

Interestingly Behringer (the Music Group) designed their own supply!

From Behringer XR18 Teardown

Digital/DSP (+analog output) PCB

People are generally annoyed by the lack of support for WPA/WPA2 with the builtin WiFi access point. It's essentially a Microchip MRF24WG0MB Module

From Behringer XR18 Teardown

The USB audio interface seems to be powered by a XMOS 16L7C10 1000 MIPS, 128 kB SRAM, 32-bit multicore microcontroller and its associated Microchip USB3340 Enhanced Single Supply Hi-Speed USB ULPI Transceiver.

From Behringer XR18 Teardown

The actual user-facing functionality obviously is orchestrated by a Freescale MCIMX253DJM4A i.MX25 400 MHz, single core, ARM 926EJ-S, the network is connected with a standard Microchip LAN8720A Small Footprint RMII 10/100 Ethernet Transceiver.

From Behringer XR18 Teardown

From Behringer XR18 Teardown

The eight XLR analog outputs are fed by a CS4385 Cirrus Logic octal 24 bit DAC, the CS4272 Cirrus Logic 24 bit stereo audio codec feeds the headphone output and digitizes the line input (ch 17/18). [it's the only ADC/DAC left after accounting for the 8 analog outputs and 16 analog inputs and corresponding octal converters].

From Behringer XR18 Teardown

Routing of signals probably is taken care of by the logic inside this Xilinx XC6SLX4 (Spartan 6) FPGA. It's the smallest of the Spartan 6 family -- and while it has 216 kBit of blockram and 8 "DSP Slices" which feature multipliers, adders and accumulators, I doubt that it does any computational work. Maybe it scales the output level or so, though...

From Behringer XR18 Teardown

There's a truckload of New Japan Radio Corporation NJM4580 Dual Opamps used inside the XR18, and
a bunch of them seem to take care of driving the differential XLR analog outputs.

From Behringer XR18 Teardown

Mic/Line ADC

The most interesting chip on the ADC board (bottom-most in the three-board stack) is the Cirrus Logic CS5368 octal 24bit ADC. There are two of them, for 16 inputs in total. There are also a bunch of NJM4580 (1+1/2 for each channel), likely for a final level adjust and to drive the differential inputs of the ADCs.

From Behringer XR18 Teardown

Mic Preamp

The board with the mic preamps is rather interesting. The layout seems to be a conventional frontend using discrete transistors as first stage amplification and a NJM4580 as a differential amplifier. There are two Coolaudio V411 analog switches per channel to adjust the gain, and quite a few shift registers to provide the control inputs to the analog switches.

From Behringer XR18 Teardown

From Behringer XR18 Teardown

From Behringer XR18 Teardown

From Behringer XR18 Teardown

Connector PCB

The connector PCB is very uninteresting. One very thoughtful detail, though, is that they drilled holes beneath the XLR/TRS combo jacks. If you ever had to desolder one of those because the TIP of a TRS connector broke off you appreciate this. I did not remove this board, because it's held in place by dozens of screws on the XLR jacks.

From Behringer XR18 Teardown

A OPAMP labeled JRC8074A seems to be the headphone amplifier.

From Behringer XR18 Teardown

Logarithmic Sine Sweep for Impulse Reponse Measurements (in Python/Numpy)

There's quite a lot of software available to do impulse response measurements, e.g. for doing measurements on loudspeakers or electronic audio equipment. Some also use it to sample the impulse responses of rooms and halls to get realistic reverb.

To learn about the technique (on which one can find quite a few publications using google) I'm going to implement the analyses in python/numpy.

The first building block is a small script to generate such a sweep and which I've published, as usual, on github: https://github.com/vogelchr/sweep_analysis

Below you can find a spectrogram made using the magnificent baudline.

From Chris’ Miscellanea

Full Disk Encryption with Cyanogenmod CM12.1 on a Samsung Galaxy S4 Mini

Update August 9th: Just skip to the last line of this post where we realize that we could have spared us all of the hassles and resize2fs from within the running android system ☺.

If you try to enable full disk encryption on Cyanogenmod CM12.1 using the normal settings menu (Security -> Encrypt Phone) it doesn't work, the phone will just soft-reboot and nothing will have happened.

If you "logcat" the debugging log of your phone (using adb logcat) within the huge amount of data, some hint about what might have gone wrong can be found:

➜  ~  grep Cryptfs logcat_encryption.txt 
I/Cryptfs (  199): Check if PFE is activated on Boot
E/Cryptfs (  199): Bad magic for real block device /dev/block/platform/msm_sdcc.1/by-name/userdata
E/Cryptfs (  199): Error getting crypt footer and key
E/Cryptfs (  199): Bad magic for real block device /dev/block/platform/msm_sdcc.1/by-name/userdata
E/Cryptfs (  199): Orig filesystem overlaps crypto footer region.  Cannot encrypt in place.
E/Cryptfs (  199): Bad magic for real block device /dev/block/platform/msm_sdcc.1/by-name/userdata
E/Cryptfs (  199): Orig filesystem overlaps crypto footer region.  Cannot encrypt in place.

On android, the footer that tells the operating system that an partition is encrypted resides on the end of the filesystem and it needs a little space between the logical end of the filesystem in a partition, and the physical end of the partition to be squeezed in when converting a phone from unencrypted to encrypted.

http://forum.xda-developers.com/nexus-4/help/looking-encryption-footer-t2676700

Running the recovery system (boot while keeping Volume-Up and Home pressed), we can have a look at the partition sizes and filesystem details. We learn that on my S4 mini, the userdata partition (mmcblk0p24) has a size of 5685231 1k blocks, and the /data filesystem claims a size of 1421307 4k blocks.

$ adb shell
~ # cat /proc/partitions
major minor  #blocks  name
(...)
 179       24    5685231 mmcblk0p24
~ # tune2fs -l /dev/block/mmcblk0p24 
(...)
Block count:              1421307
(...)
Block size:               4096

As 5685231-1421307*4 = 3, that's only 3 meager 1k blocks at the end of the filesystem, whereas the encryption footer needs a space of at least 16k, the allmighty internet tells me. So, let's build a filesystem that leaves 128kByte of free space on the end as I don't know if Android 5 has enlarged the footer from what the websites I had found claims, or if there's some alignment requirement for it. So I'll be generous. (5685231-128)/4=1421275.75 so I'll create a ext4 filesystem occupying 1421275 4k blocks:

~ # mke2fs -b4096 -T ext4 /dev/block/platform/msm_sdcc.1/by-name/userdata 142127

(note: I made a mistake, ch0pped off the 5!)
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
35600 inodes, 142127 blocks
7106 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=146800640
5 block groups
32768 blocks per group, 32768 fragments per group
7120 inodes per group
Superblock backups stored on blocks: 
32768, 98304

Writing inode tables: done                            
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 33 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

Do I really have to mention at this point that this will erase all your files? Alternatively one could try "resizefs" to resize the filesystem, but that program isn't included in my recovery. Anyhow, it seems to be prudent to try encryption on an otherwise virgin install, as one risks data loss anyhow when performing the encryption process and there are reports of phones not booting up correctly after encyption had been enabled.

Then reboot the phone, do a half-hearted initial setup of the device, configure a simple PIN for testing, and encrypt your phone. (I also enabled debugging so that I can run logcat again to catch errors).

$ grep Cryptfs logcat_encryption_newfs.txt
(...)
I/Cryptfs (  196): Check if PFE is activated on Boot
E/Cryptfs (  196): Bad magic for real block device /dev/block/platform/msm_sdcc.1/by-name/userdata
E/Cryptfs (  196): Error getting crypt footer and key
E/Cryptfs (  196): not running with encryption, aborting
E/Cryptfs (  196): Bad magic for real block device /dev/block/platform/msm_sdcc.1/by-name/userdata
D/Cryptfs (  196): Just asked init to shut down class main
D/Cryptfs (  196): unmounting /mnt/shell/emulated succeeded
D/Cryptfs (  196): unmounting /data succeeded
I/Cryptfs (  196): keymaster version is 2
I/Cryptfs (  196): Using scrypt for cryptfs KDF
D/Cryptfs (  196): Just triggered post_fs_data
D/Cryptfs (  196): post_fs_data done
D/Cryptfs (  196): Just triggered restart_min_framework
I/Cryptfs (  196): Using scrypt for cryptfs KDF
I/Cryptfs (  196): Enabling support for allow_discards in dmcrypt.
I/Cryptfs (  196): load_crypto_mapping_table: target_type = crypt
I/Cryptfs (  196): load_crypto_mapping_table: real_blk_name = /dev/block/platform/msm_sdcc.1/by-name/userdata, extra_params = 1 allow_discards
I/Cryptfs (  196): Encrypting ext4 filesystem in place...
I/Cryptfs (  196): Encrypting group 0
I/Cryptfs (  196): Encrypting from sector 0
I/Cryptfs (  196): Encrypting group 1
I/Cryptfs (  196): Encrypted to sector 1356288
I/Cryptfs (  196): Encrypting from sector 16777216
I/Cryptfs (  196): Encrypted to sector 16867328
I/Cryptfs (  196): Encrypting from sector 16874496
I/Cryptfs (  196): Encrypted to sector 17014784

The phone will now reboot and ask for the PIN you entered. Unfortunately this takes *ages*! But if everything is fine, you can now setup your phone to your heart's content and set up a real password to have a securely encrypted phone. We'll have to see how stable this encrypted phone will be in daily use.

From Chris’ Miscellanea

Update: I made a mistake and chopped off the "5" at the end, so my filesystem only occupies 1/10 of the available space and has a completely unusable size of 500 MB :-(. So, to not have to start all over again, I'll try to resize the file system in place.

Login to your android device, and check the filesystem size. Indeed /data is completely ridiculous at 500MB.

➜  e2fs  adb shell

shell@serranoltexx:/ $ su

root@serranoltexx:/ # df

Filesystem               Size     Used     Free   Blksize

(...)

/data                  553.0M   490.2M    62.8M   4096

Check the sizes of the underlaying block device, and the dmcrypt mapper:

root@serranoltexx:/ # cat /proc/partitions

major minor  #blocks  name

(...)

 179       24    5685231 mmcblk0p24

(...)

 254        0    5685215 dm-0

Indeed, the crypted partition is exactly 16kB smaller (the crypt footer) than the raw block device. So we can hopefully let resize2fs autodiscover the target size. Unfortunately, we cannot access the block device hosting /data, and we can't umount /data because the android framework is still running. So we use the same method as the volume daemon to shutdown most of android. (your device will not no longer react to user input on the buttons or touch secreen):

root@serranoltexx:/ # setprop vold.decrypt trigger_shutdown_framework

root@serranoltexx:/ # umount /data

root@serranoltexx:/ # e2fsck -f /dev/block/dm-0       

e2fsck 1.42.9 (28-Dec-2013)

Pass 1: Checking inodes, blocks, and sizes

(...)

(fix problems as they appear here)

root@serranoltexx:/ # resize2fs /dev/block/dm-0

resize2fs 1.42.9 (28-Dec-2013)

Resizing the filesystem on /dev/block/dm-0 to 1421303 (4k) blocks.

The filesystem on /dev/block/dm-0 is now 1421303 blocks long.

I rebooted the phone the hard way via sync; echo b >/proc/sysrq-trigger.

Now /data is at the expected size of 5.5 GB.

➜  ~  adb shell df
Filesystem               Size     Used     Free   Blksize
(...)
/data                    5.4G   734.3M     4.7G   4096

Of course, now that we have found out how to resize an ext4 filesystem in place from within android, we realize that we could have made it that way from the beginning 😉. Without data loss. Just run the last 4 commands but using the physical emmc device and append the right number of blocks we need to resize2fs while the device is still unencrypted...

e2fsck /dev/block/mmcblk0p24

resize2fs /dev/block/mmcblk0p24 14221303

That should do the trick. Reboot and run the normal encryption process.

Public Service Announcement: Putty

A recent upgrade of sshd apparently broke my saved putty connections, which have a deprecated key-exchange protocol on the top of the "Algorithm selection policy."

It manifests itself as a long pause, showing a black putty terminal window, followed by the message: PuTTY Fatal Error: Server unexpectedly closed network connection.

The putty event window will show it being stuck in the "Doing Diffie-Hellman group exchange" phase.

From Chris’ Miscellanea

If you run your sshd in debug mode, you'll see that sshd isn't happy with the selection of the key exchange protocol.

➜  ~  sudo /usr/sbin/sshd -p 2222 -d
debug1: sshd version OpenSSH_6.9, OpenSSL 1.0.2c 12 Jun 2015

(...)

debug1: kex: server->client aes256-ctr hmac-sha2-256 none [preauth]

debug1: expecting SSH2_MSG_KEX_DH_GEX_REQUEST [preauth]

Hm, kex protocol error: type 30 seq 1 [preauth]

Connection closed by 10.120.102.56 [preauth]

(...)

From Chris’ Miscellanea

It seems that OpenSSH recently had removed an ancient method of key exchange, as is to be read on this thread on the misc@OpenBSD mailing list.

If you open putty 's session configuration and move the "Diffie-Hellmann group exchange" right to the bottom of the "Algorithm selection policy" (Configuration / Connection / SSH / Kex), everything works again.

From Chris’ Miscellanea

SDM220 Power Meter, MODBUS, Python, RS485

The Eastron SDM220 is a very inexpensive one-phase power/energy meter, which can be readout via RS485. I got myself one to play with, and there are a few observations I wanted to write down.

From Chris’ Miscellanea

From Chris’ Miscellanea

From Chris’ Miscellanea

It's actually a pretty nifty meter, measuring power and energy in both directions, voltage and line frequency. Furthermore it outputs power-factor (cosϕ) and reactive or apparent power (which is basically the same thing, just represented differently).

One thing that cost me some time to resolve, especially as I used a selfmade RS485 adapter in the first place about the correctnes of which I was unsure are: The RS485 terminals are wired incorrectly, B and A are swapped, this has been verified with an industrial/commercial interface. Connectors 7, 8 and 9 are GND, A and B. In that order. If the link is idle, B will be positive with respect to A.

There's an existing modbus library for Python (pymodbus) which works perfect, so far. The serial modbus link is instantiated like this (if the modbus runs with parity = None).

    cl = pymodbus.client.sync.ModbusSerialClient('rtu',
        port='/dev/ttyUSB1', baudrate=9600,
        parity='N',stopbits=2,
        timeout=0.125)

The values stored in the device are actually IEEE754 floating point values, which can be converted to python floats very conveniently, they are fetched as two consecutive 16bit register, concatenated to a 32bit field, and then reinterpreted as the 32bit float:

    resp = client.read_input_registers(basereg,2, unit=1)

    return struct.unpack('>f',struct.pack('>HH',*resp.registers))

The documentation for the SDM220 is actually quite comprehensive, but it took me quite a while until I really figured out what they meant... So here are the register numbers I sucessfully used to get date off the device:

        # Symbol    Reg#  Format
        ( 'V',      0x00, '%6.2f' ), # Voltage [V]
        ( 'Curr',   0x06, '%6.2f' ), # Current [A]
        ( 'P[act]', 0x0c, '%6.0f' ), # Active Power ("Wirkleistung") [W]
        ( 'P[app]', 0x12, '%6.0f' ), # Apparent Power ("Scheinl.") [W]
        ( 'P[rea]', 0x18, '%6.0f' ), # Reactive Power ("Blindl.") [W]
        ( 'PF',     0x1e, '%6.3f' ), # Power Factor   [1]
        ( 'Phi',    0x24, '%6.1f' ), # cos(Phi)?      [1]
        ( 'Freq',   0x46, '%6.2f' )  # Line Frequency [Hz]

esp8266 firmware upgrade, odd baudrate in bootloader?

So, I also got one of those ESP8266 wifi/serial modules, which are pretty neat. Unfortunately mine seemed to come with an ancient firmware on it, and pretty unconveniently those didn't want to be re-flashed with newer software.

From Chris’ Miscellanea

The bootloader seems to initialize the modules' serial port to the pretty insane value of 76923 bps, so that in "programming" mode, the stupid windows-utility (or, for that matter, any program expecting standard-baudrates) will fail to communicate with the module.

From Chris’ Miscellanea

If you have a suitable serial cable (a FTDIchip FT2232 is what I used), you can calculate "custom dividers" for most uncommon baudrates, and use those instead of 38,4kBps (the "magic" baudrate indicating that the custom one should be used).

Base-frequency for the ft2232 is 60 Mhz, so we'll use a custom divisor of 780 (60Mhz/76923).

$ setserial /dev/ttyUSB0 spd_cust divisor 780     
$ cu -l ttyUSB0 -s 38400
Connected.

 ets Jan  8 2013,rst cause:1, boot mode:(7,7)

waiting for host

 ets Jan  8 2013,rst cause:1, boot mode:(7,7)

waiting for host

 ets Jan  8 2013,rst cause:1, boot mode:(3,7)

load 0x40100000, len 24444, room 16 
tail 12
chksum 0xe0
ho 0 tail 12 room 4
load 0x3ffe8000, len 3168, room 12 
tail 4
chksum 0x93
load 0x3ffe8c60, len 4956, room 4 
tail 8
chksum 0xbd
csum 0xbd

Interestingly, that seems to be only the bootloader of the module, after this, the device switches to the more common 115200kbps and responds to AT-commands, given that GPIO15=GND, GPIO2=Vcc, GPIO0=Vcc and CH_PD=Vcc. (pullups to Vcc via ~5kΩ resistor)

So, to get the windows-only updater to run successfully, we...

• connect GPIOs and CH_PD as listed above (AT-Mode)
• power up module
• module will start bootloader with 77kbps, then change into AT-command mode, at 115200 bps
• connect GPIO0 to GND (firmware download mode)
• pulse CH_PD to LOW to restart module
• firmware will restart, but bootloader does NOT go back to 77kbps
• run firmware-upgrade in windows

From Chris’ Miscellanea

Now I'm upgraded to version 170901 (whatever that means).

AT+GMR
00170901

Building pyqwt 5.2.0 by manually installing the pyqtconfig.py module.

For playing with GNU radio I had to install quite a lot of dependencies to get all the modules to build, unfortunately there's currently a build issue with PyQwt, which are the Python bindings for Qwt, the Qt Widgets for Technical Applications.

Installation of PyQwt-5.2.0 fails with an error message of...

Requires at least PyQt-4.2 and its development tools.
==> ERROR: A failure occurred in build().
    Aborting...

...and this is because of the configuration script of PyQwt that tries to import PyQT's pqtconfig.py, that no longer is installed by PyQt 4.11.1!

There are a few bugreports to be found on the web, e.g.

• https://github.com/Homebrew/homebrew/issues/21984
• http://sourceforge.net/p/pyqwt/bugs/12/

To fix this, get yourself the pyqt-x11 source, then run the configure script as appropriate for your particular Linux installation...

[optiplex …/chris/AUR/python2-pyqt4/src/Py2Qt-x11-gpl-4.11.1]
$ python2 configure.py -v /usr/share/sip --qsci-api -q /usr/bin/qmake-qt4 Determining the layout of your Qt installation...
This is the GPL version of PyQt 4.11.1 (licensed under the GNU General Public
License) for Python 2.7.8 on linux2.
Type '2' to view the GPL v2 license.
Type '3' to view the GPL v3 license.
Type 'yes' to accept the terms of the license.
Type 'no' to decline the terms of the license.
Do you accept the terms of the license? yes
Found the license file pyqt-gpl.sip.
Checking to see if the QtGui module should be built...
Checking to see if the QtHelp module should be built...
Checking to see if the QtMultimedia module should be built...
Checking to see if the QtNetwork module should be built...

(...)

Creating pyrcc4 Makefile...
Creating Qt Designer plugin Makefile...
Creating pyqtconfig.py...

At this point, the proper pyqtconfig.py script has been created, install to the python site-package directory.

[optiplex …/chris/AUR/python2-pyqt4/src/Py2Qt-x11-gpl-4.11.1]
$ sudo install -m644 pyqtconfig.py /usr/lib/python2.7/site-packages/PyQt4/pyqtconfig.py 

Now, the pyqwt bindings can be built, e.g. by using ArchLinux's makepkg utility, using the AUR package.

[optiplex /home/chris/AUR/pyqwt]
$ makepkg
==> Making package: pyqwt 5.2.0-10 (Tue Aug 26 21:37:07 CEST 2014)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...

(...)

==> Starting build()...
patching file qt4lib/PyQt4/Qwt5/qplt.py
patching file configure/configure.py
patching file configure/configure.py
Command line options:
{'debug': False,
 'disable_numarray': False,

(...)

cp -f ../../qt4lib/PyQt4/uic/widget-plugins/qwt.py /home/chris/AUR/pyqwt/pkg/pyqwt/usr/lib/python2.7/site-packages/PyQt4/uic/widget-plugins/qwt.py
make[1]: Leaving directory '/home/chris/AUR/pyqwt/src/PyQwt-5.2.0/configure/qwt5qt4'
==> Tidying install...
  -> Purging unwanted files...
  -> Removing libtool files...
  -> Removing static library files...
  -> Compressing man and info pages...
  -> Stripping unneeded symbols from binaries and libraries...
==> Creating package "pyqwt"...
  -> Generating .PKGINFO file...
  -> Generating .MTREE file...
  -> Compressing package...
==> Leaving fakeroot environment.
==> Finished making: pyqwt 5.2.0-10 (Tue Aug 26 21:40:25 CEST 2014)

Controlling USB device access on Linux (e.g. BADusb defense)

So, there was a lot of fuzz about a recent talk by Karsten Nohl et al. at BlackHat about the the unsecurity of current USB implementations (on the computer side) which happily load drivers for all kinds of devices as soon as a (potentially malicious) USB stick is connected.

I completely agree that, as shipped, most computer systems will be susceptible to this attack, and assume that all of their attacks will work as advertised. What I don't agree with at all is their conclusion, which boils down that no effective defenses exist.

While I haven't made my homework to develop a defense, I want to at least show the mechanism in current Linux kernels to limit binding of potentially dangerous drivers to specific devices, so that e.g. a inserted USB-stick would only be mounted as a block device, and its malicious keyboard interface be ignored.

Binding of Drivers

A linux-module can claim ownership of certain usb vendor/device ids or device classes. Those are visible when looking at the modinfo of a kernel module, to facilitate autoloading of modules, but are also registered in internal kernel structures, so that drivers compiled in statically directly can be mated with the proper devices:

$ modinfo snd-usb-audio
filename:       /lib/modules/3.15.8-1-ARCH/kernel/sound/usb/snd-usb-audio.ko.gz
license:        GPL
description:    USB Audio
author:         Takashi Iwai
alias:          usb:v*p*d*dc*dsc*dp*ic01isc01ip*in*
alias:          usb:v0D8Cp0103d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v*p*d*dc*dsc*dp*ic01isc03ip*in*
alias:          usb:v200Cp100Bd*dc*dsc*dp*ic*isc*ip*in*
(...)

This information currently comes from the MODULE_DEVICE_TABLE of sound/usb/card.c, stored in an array called usb_audio_ids. The bold one is the "default class", the others all are included in the "quirks table", which includes all exceptions from the default class.

static struct usb_device_id usb_audio_ids [] = {
#include "quirks-table.h"
     { .match_flags = (USB_DEVICE_ID_MATCH_INT_CLASS | USB_DEVICE_ID_MATCH_INT_SUBCLASS),
       .bInterfaceClass = USB_CLASS_AUDIO,
       .bInterfaceSubClass = USB_SUBCLASS_AUDIOCONTROL },
     { }                                         /* Terminating entry */
 };
MODULE_DEVICE_TABLE(usb, usb_audio_ids);

On connection of a USB device, the kernel will look through all its currently registered modules that claim to support USB devices (by registering those tables with the kernel) and bind devices to drivers (and if it doesn't succeed, it will call udev/hotplug to load a module that does). 

The Vulnerability

So, if you connect a particular USB headset, the electronics of which I have laying around... you get a new sound device in ALSA...

[root@optiplex devices]# aplay -l

**** List of PLAYBACK Hardware Devices ****
(...)
card 1: Headset [Logitech USB Headset], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

But also a new keyboard! (the mute/volume buttons on the headset, but those could be arbitrary buttons entering text, too).

[root@optiplex devices]# xinput
⎡ Virtual core pointer                     id=2 [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer               id=4 [slave  pointer  (2)]
⎜   ↳ Logitech USB-PS/2 Optical Mouse         id=8 [slave  pointer  (2)]
⎣ Virtual core keyboard                   id=3 [master keyboard (2)]
    ↳ Virtual core XTEST keyboard             id=5 [slave  keyboard (3)]
    ↳ Power Button                             id=6 [slave  keyboard (3)]
    ↳ Power Button                             id=7 [slave  keyboard (3)]
    ↳ Das Keyboard                             id=9 [slave  keyboard (3)]
    ↳ Logitech Logitech USB Headset           id=10 [slave  keyboard (3)]

If you look in the sysfs filesystem, you can see, that the USB headset (usb device 5-1) has 4 distinct functions (.0 -- .3) on configuration :1.

[root@optiplex /sys/bus/usb/devices/5-1]# ls
5-1:1.0     bcdDevice    maxchild
5-1:1.1     bmAttributes   port
5-1:1.2     busnum    power
5-1:1.3     configuration  product
authorized     descriptors    quirks
avoid_reset_quirk    dev    removable
bConfigurationValue  devnum    remove
bDeviceClass     devpath    speed
bDeviceProtocol      driver    subsystem
bDeviceSubClass      ep_00    uevent
bMaxPacketSize0      idProduct    urbnum
bMaxPower     idVendor    version
bNumConfigurations   ltm_capable
bNumInterfaces     manufacturer

And those are described by the (very lengthy) lsusb -v output, which I'll not reproduce completely here, just try it for yourself on any USB device.

Bus 005 Device 006: ID 046d:0a0b Logitech, Inc. ClearChat Pro USB

Device Descriptor:

 (...)

  bNumConfigurations      1

  Configuration Descriptor: (configuration #1 starts here)

    bLength                 9

(...)

    Interface Descriptor: (interface 1:0)

(...)

       bDescriptorType         4

       bInterfaceNumber        0

(...)

    bInterfaceClass         1 Audio

      bInterfaceSubClass      1 Control Device

(...)

      AudioControl Interface Descriptor: (detailed info about audio capabilities)

        bLength                10

(...)

    Interface Descriptor: (interface 1:3)

      bInterfaceNumber        3

(...)

      bInterfaceClass         3 Human Interface Device

      bInterfaceSubClass      0 No Subclass

      bInterfaceProtocol      0 None

      iInterface              0 

So, here you have it, one device that (legitimately) is both a soundcard and a keyboard/mouse (e.g. an human interface device). Given enough motiuvation, code could be written for the controller inside the soundcard that enters arbitary text to my computer. And that's basically the vulnerability presented in the Black Hat Presentation by Nohl et al.

Defense

But, you can easily turn off this automatic binding, at least on Linux, with one single command:

[root@optiplex ~]# echo 0 >/sys/bus/usb/drivers_autoprobe 

Now, whenever you connect a USB device to your computer, it will not automatically connect the usb-soundcard to the ALSA subsystem and the volume buttons to the hidraw/keyboard driver. If I now connect the aforementioned soundcard, I'll not get a new keyboard in xinput, nor a soundcard in ALSA (and also not a network- or block-device for a network card or USB disk).

The only thing I'll get in my dmesg is the message, that an USB device has been connected:

[13399.092113] usb 5-1: USB disconnect, device number 6
[13405.245389] usb 5-1: new full-speed USB device number 7 using uhci_hcd

And to manually bind this device, you first have to choose the appropriate USB configuration...

# echo 1 >/sys/bus/usb/devices/5-1/bConfigurationValue 

...and tell the usb audio driver to bind to that device.

# echo 5-1:1.0 >/sys/bus/usb/drivers/snd-usb-audio/bind

Now you have the USB audio interface, but not the keyboard, yet... If you wanted, you'd just bind usb-hid to interface 3.

# echo 5-1:1.3 >/sys/bus/usb/drivers/usbhid/bind 

To verify that your keyboard presses aren't registed from the connected device before, and are registered after binding, you can run "xev" and press the volume buttons (note: those, in principle, could enter arbitrary text to your computer, depending on the programming of the controller in the device).

KeyRelease event, serial 38, synthetic NO, window 0x3800001,
    root 0x1dc, subw 0x3800002, time 13880057, (41,58), root:(2384,618),
    state 0x10, keycode 123 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

The most often quoted use-case if obviously connection of a usb-storage device, e.g. an external harddrive or flash-stick.

[14567.888596] usb 6-1: new high-speed USB device number 4 using ehci-pci

# echo 1 >/sys/bus/usb/devices/6-1/bConfigurationValue
# echo 6-1:1.0 >/sys/bus/usb/drivers/usb-storage/bind

[14667.692717] usb-storage 6-1:1.0: USB Mass Storage device detected
[14667.692936] scsi7 : usb-storage 6-1:1.0
[14668.696482] scsi 7:0:0:0: Direct-Access     TOSHIBA  MK4309MAT        G5.0 PQ: 0 ANSI: 0 CCS
[14668.698461] sd 7:0:0:0: [sdd] 8452080 512-byte logical blocks: (4.32 GB/4.02 GiB)

(yes, it's a very, very crappy and old USB harddisk)

Proper user-interface, current lack thereof.

To convert all this sysfs poking into a proper user-friendly software, one will have to...

• On computer startup, disable  autoprobe (probably there's a kernel command line for that).
• Statically configure the minimal interfaces used (e.g. the main usb keyboard, trackpad/mouse, ...).
• During normal operation, watch hotplug-events or poll the sysfs filesystem for newly inserted usb devices.
• Verify presented configurations of USB devices and their interfaces with a policy (e.g. enable only usb-storage devices, e.g. "thumbdrivers"
• Ask the user, if he's happy with this device.
• On successful verification, only bind the single necessary driver (e.g. usb-storage) to the proper interface of the device.

Of course, for certain devices more sophisticated verification schemes could be envisioned, checking certificates, downloading firmware for verification (which, again, might be forged, ...).

The "Authorized" Mechanism

There's a second mechanism to disable/enable communication with USB device using the "authorized" property of USB controllers. It's described in the kernel documentation.

Windows...

There seems to be a group policy for that... Local Computer Policy, Computer Configuration,Administrative Templates, System, Device Installation, and Device Installation Restrictions

Stairville DJ-X 16, voided my warranty

The DJ-X 16 is a very basic DMX controller, which I used to test out DMX controlled (d'uh...) LED lights. I cannot recommend it, it lacks a lot of features, and the buttons/faders have a very flimsy feeling. Nevertheless: Because I was pondering if it was worthwhile to modify its firmware, I decided to void the warranty (yeah!) and here are few pictures documenting the insides of this device.

What I found pretty interesting is the fact that, even though I bought it new only a few months ago, and it's still being manufactured exactly like that, it uses pretty antique components, and is an all-through-hole PCB, not a single SMD to be found.

The main controller is a Atmel AT89C55WD, a 8051 compatible 8-bit microcontroller. It's meagre 256 bytes of internal RAM is extended by 8k of High-Speed (120ns...) SRAM. A 29EE010 EEPROM takes care of the 8051's lack of long-term memory. Everything else is 80s-style design, with a lot of 47hc's.

There's a second, smaller, PCB which is home of the SN57176 RS485 driver/receiver, an optocoupler (MIDI out/through), connectors and a 7805 voltage regulator. The flat-ribbon cable connecting this connection-PCB to the main board is nicely labeled on the silkscreen, very convenient.

K1    1   2  COM
K2    3   4  Audio2
K3    5   6  Audio1
k5    7   8  MIDI in
+5V   9  10  +5V
NC    11 12  MIDI through
GND   13 14  GND
+5V   15 16  +5V
NC    17 18  DMX out
+12V  19 20  +12V

From Chris’ Miscellanea

From Chris’ Miscellanea

From Chris’ Miscellanea

Playing with a AM2302 Temperature/Humidity Sensor & LUFA

I played around with a Adsong AM2302 Temperature/Humidity sensor today which has a pretty neat serial interface.

From Chris’ Miscellanea

I wrote some code to read in the data using the input-capture mode of the Timer/Counter1 in a AVR ATmega32u4 (way overpowered, but it's handy on a Olimexino 32U4 board) to learn about using the LUFA USB library a little, maybe someone can put it to actual use?

$ cu -l ttyACM0
Connected.
Triggering conversion.
AS2302 raw bytes: recv cnt=0 01 76 00 fa 71
status: 0, temp=250 (*0.1 dC), rh=374 (*0.1%)

Get /dev/spidev on an Raspberrypi running under Archlinux ARM working again.

Currently, when running a raspberry-pi with the latest kernel available for Archlinux, access to the SPI bus via /dev/spidev no longer works. Bugs have been filed, but apparently the late-binding logic available via spi_register_board_info just seems to be broken right now.

I've written a small kernel module that doesn't fix the initial bug, but just does the binding of spidev to the first two chipselects of the first spi master. It's available on github.


$ ls -la /dev/spidev*
zsh: no matches found: /dev/spidev*

$ sudo insmod rpi_add_spidev_module/rpi_add_spidev_module.ko 

$ dmesg

(...)
[  245.299487] spi_master spi0: ...is the master for device #0.
[  245.299709] spi spi0.0: ...is the device #0.
[  245.299734] spi_master spi0: ...is the master for device #1.
[  245.304763] spi spi0.1: ...is the device #1.

$ ls -la /dev/spidev0.*

crw------- 1 root root 153, 0 Mar  6 16:47 /dev/spidev0.0

crw------- 1 root root 153, 1 Mar  6 16:47 /dev/spidev0.1

# cd /sys/bus/spi/drivers/spidev
# ls -l
total 0
--w------- 1 root root 4096 Jan  1 00:03 bind
lrwxrwxrwx 1 root root    0 Jan  1 00:02 module -> ../../../../module/spidev
lrwxrwxrwx 1 root root    0 Jan  1 00:03 spi0.0 -> ../../../../devices/platform/bcm2708_spi.0/spi_master/spi0/spi0.0
lrwxrwxrwx 1 root root    0 Jan  1 00:02 spi0.1 -> ../../../../devices/platform/bcm2708_spi.0/spi_master/spi0/spi0.1
--w------- 1 root root 4096 Jan  1 00:00 uevent
--w------- 1 root root 4096 Jan  1 00:02 unbind

Using software to talk to a proprietary SPI gyro/accelerometer module works again.

$ sudo ./rpi_gyro /dev/null  

Opened gpio25 direction as fd 5.

Opened gpio25 value as fd 6.

Opened /dev/spidev0.0 as fd 7 (0x03, 8, 0).

Opened /dev/spidev0.1 as fd 8 (0x03, 8, 0).

lsm330dlc_dump_regs: dumping accelerometer registers.

$00: $00 $00 $00 $00   $00 $00 $00 $ff

$08: $00 $00 $00 $00   $00 $00 $00 $33

$10: $86 $16 $a6 $26   $48 $25 $21 $1e

$18: $1b $a3 $50 $65   $c0 $00 $50 $00

$20: $27 $00 $00 $80   $40 $00 $00 $ff

$28: $00 $2d $c0 $01   $40 $27 $80 $9e

$30: $00 $00 $00 $00   $00 $00 $00 $00

$38: $00 $00 $00 $00   $00 $00 $00 $00

lsm330dlc_dump_regs: dumping gyro registers.

$00: $d3 $66 $a8 $cc   $4d $d0 $11 $f1

$08: $20 $06 $ff $18   $02 $83 $00 $d3

$10: $90 $2b $19 $44   $0c $e0 $61 $60

(...)

Riso Kagaku Corp Webmail Notifier Redux: Kernel Module Cleanup

Trying to clean up this code, so that it's usable without too much friction...

I put up my slightly modified version of the usbled.c kernel module on github. It includes support for one of the cheapest incarnation of USB-led devices, the Riso Kagaku Corp. Webmail Notifier. It can now be built out-of-tree easily (trying to forward to the kernel guys to merge it eventually) and includes udev rules and a script to automate the re-binding of device from usbhid to the usbled driver).

Earlier posts:

• Webmail Notifier - Linux Hidraw
• Webmail Notifer, Linux Kernel Module

Github: Extending Linux' usbled.c to support the "Webmail Notifier" by Riso Kagaku Corp.

Movie hosted by instagram: