Still Here…

Posted May 26, 2014 by Tyson Key
Categories: Uncategorized

Tags: , , ,

Sorry for not updating this blog more often than I intended to, lately…

Not a great deal to report on, from a personal perspective, since I’ve mostly being trying to focus on getting through this stage of my course, and am waiting for exam results, so that I can hopefully progress onto my final year. 

Since the last time that I posted about them, my Wireshark dissectors (especially the USB CCID, and NXP PN532 ones) have seen some significant updates, thanks to the much-appreciated assistance of Michal Labedzki, and other members of the upstream Wireshark community.

This means that most of the CCID-specific USB descriptors are now dissected, and the PN532 dissector now not only supports the entire command set, but also supports the custom Host Communication Interface wrapper protocol, used by certain devices.

As a side project, I decided to start a new, L4Ka::Pistachio-based OS project, earlier this month, by branching the official GitHub repository, which as of yet still doesn’t have a name.

This one won’t initially be as ambitious as my prior, failed attempts; and I’ve already made some progress on implementing a C library, using code from the existing “libio“, various versions of BSD, and Solaris; and a shell using the existing driver for serial port, and keyboard. 

The keyboard driver is still pretty buggy (shift key support doesn’t work, for some reason); however, the serial driver works fine in QEMU, and even seems to cope with Unicode characters (the example text is a song title from a Korean band (DOZ), for the curious), without problems, provided a suitable font is available:


I also started trying to implement support for ATA-based hard disk access (using a public-domain driver), and the FAT series of file systems (using Chan’s driver), but this doesn’t quite work properly, yet. 

Also, my C library implementation still has a fairly large numbers of flaws, and missing features (no file support, or streams support are probably the most glaring omissions, right now), so it’s difficult to port things to it.

Anyway, I hope that provides some explanation for my absence for so long.

Configuring a Generic Wireless LAN Bridge

Posted August 18, 2013 by Tyson Key
Categories: Everything

Tags: , , , , , , ,

Some time ago, I purchased a generic 802.11n Wireless LAN repeater, after having issues with receiving a reliable wireless connection to my ADSL residential gateway/router due to interference from neighbouring networks, and the signal propagating poorly throughout the back of the house.

I ended up buying it as a “cheap workaround”, after getting frustrated with being unable to maintain a reliable connection on my laptop, or various phones – despite trying things like switching to less congested channels (usually 9, or 13), increasing transmission power rates (at the expense of battery life); and decreasing maximum bitrates to ridiculously-levels.

Technically, the bridge is a small, embedded Linux-based device with a RealTek RTL8186 MIPS-derived system-on-chip, supporting Ethernet, and 802.11; PCI, and even PCM audio. (Which seems like overkill – but I suppose that it’s probably cheaper to design, and distribute a universal, multipurpose chipset, than it would be to produce cut-down variants).

Common complaints that buyers on Amazon had were that the firmware was buggy, the device was unreliable, and that the device’s Web-based configuration tool supposedly became inaccessible, post-configuration.

However, I found that if I ignored the supplied instructions, and attempted to configure the device by using a direct connection to my PC using Ethernet, I was able to configure it in a reliable manner that allowed for continued access to its administration server, as well as roaming throughout the house using the same SSID

Please note that the values in the screenshots are specific to my home network, and are not factory defaults.

Unfortunately, since I have discarded the packaging, I can’t provide photos of its contents – although I’m sure that they consisted of at least:

  • The device itself
  • An instruction leaflet
  • A short Ethernet cable
  • A detachable 3-pin UK mains plug

To begin with, I unpacked the product; plugged into a power outlet, and connected the Ethernet cable to my laptop.

Next, I temporarily disabled the use of my laptop’s wireless LAN chipset, using the hardware kill-switch, to ensure that requests for multiple IPv4 addresses via two hardware interfaces won’t be made.

The bridge ships configured with a DHCP server enabled by default, issuing IPv4 addresses within the 192.168.10.x range, and reserving for itself – but we’ll change this, later.

First, navigate to the default configuration URL (, using your preferred browser:

Next, select the “Wireless” option from the “Professional Setup” category:

Here, set the following options:

  • “Mode”: “Repeater”
  • “Network Type”: “Infrastructure”
  • “SSID of Connect to” (sic): Enter the SSID of your primary access point
  • Check the “Enable Universal Repeater Mode (Acting as AP and client simultaneouly” (sic) checkbox
  • “SSID of Extended Interface”: Enter the SSID of your primary access point again

If you have configured your primary access point to enable operation in 802.11n mode, then select either “2.4GHz (N)”, “2.4GHz (G + N)”, or “2.4GHz (B+G+N)” from the “Band” menu. Otherwise, “2.4GHz (B+G)” should deliver satisfactory performance for most WAN-based activities.

In order for seamless handover between access points using the same SSID to work well, it is then necessary to set the default 802.11 channel of your primary access point to 11. (This seems to be a hard-coded, preset value).

It may also be necessary to configure WEP, or WPA keys for your primary access point on the “Security” page; and I also recommend changing the configuration tool’s access credentials to something more secure than their default values.

After configuring these settings, the bridge will reboot automatically…

Once the bridge has rebooted, return to the “LAN Interface” page:

On this page, set the “DHCP” setting to “Client”, and apply changes. At this point, because the bridge will attempt to obtain its configuration IPv4 address from your primary access point/gateway’s DHCP server, it’d be a good idea to disconnect the Ethernet cable, and re-enable the PC’s wireless LAN interface.

Hopefully, at this point, a successful WLAN connection will have been made.

However, in order to maintain future access to the bridge’s configuration server, it is necessary to assign a static IPv4 address to its MAC address (printed on a sticker on the case – but it’ll probably also appear in system/DHCP server logs) using the configuration tool of your primary access point.

After configuring this, power-cycle the bridge, and attempt to access its configuration page via the newly-set IPv4 address. If successful, you should be presented with an authentication dialogue, and be able to see the configuration tool’s status page, as at the beginning.

Hopefully, this will be of assistance to other owners of these devices, or folks contemplating purchasing one.

WAP @ Home

Posted May 26, 2013 by Tyson Key
Categories: Everything

Tags: , , , , , , ,

Last night, I decided to install Kannel (an Open Source Wireless Application Protocol gateway), for a challenge.

It seems that installation itself was easy (just a case of downloading a snapshot archive, unpacking it, installing the libxml2-dev package from the Ubuntu repositories, and then running ./configure && make && make install to install it.

However, actually configuring it to run successfully was harder, since the “bearerbox“, and “wapbox” utilities will just unceremoniously quit with a “panic” notice, if they can’t either find their configuration file, or if it isn’t structured in a suitable manner.

I ended up copying the example configuration file from ~/kannel-snapshot/doc/examples/kannel.conf to /etc/kannel/kannel.conf, and modifying it to look like:

group = core
admin-port = 13000
admin-password = bar
wapbox-port = 13002
wdp-interface-name = *
group = wapbox
group = smsbox
bearerbox-host = localhost
sendsms-port = 13013
group = sendsms-user
username = tester
password = foobar
# this sender is for Kannel relay testing (http_smsc)
group = sendsms-user
username = kannel
password = rL4y
user-deny-ip = "*.*.*.*"
user-allow-ip = ""
# there should be default always
group = sms-service
keyword = default
text = "No service specified"

view raw


hosted with ❤ by GitHub

I also had to configure my residential gateway/router to use my laptop’s IPv4 address as a DMZ host. (Although I originally intended to just allow inbound traffic on UDP ports 9200, and 9201, for testing purposes).

After doing so, the core BearerBox utility can be invoked with bearerbox /etc/kannel/kannel.conf.

WAPBox is supposed to start automatically – however, it didn’t in my case, so I had to manually invoke
wapbox /etc/kannel/kannel.conf, in order to prevent this error:

2013-05-26 12:42:41 [16085] [1] DEBUG: Thread 1 (gwlib/fdset.c:poller) maps to pid 16085.
2013-05-26 12:42:54 [16085] [6] DEBUG: datagram received
2013-05-26 12:42:54 [16085] [8] DEBUG: Did not find previous routing info for WDP, generating new
2013-05-26 12:42:54 [16085] [8] WARNING: Cannot route message, discard it

view raw


hosted with ❤ by GitHub

To test to see if I could connect to the newly-installed gateway, I decided to play with the “Network Settings” view of the BlackBerry OS version of the Shazam application, since it allows for overriding of the default GPRS/WAP settings.

I ended up using the following settings (which will probably be useless for other readers, but otherwise provide a template):

Username: payandgo
Password: password
WAP Gateway IP:
WAP Port: 9201

(*) These are network WAP Settings

[Y] Enable Overrides

After selecting “Test Settings”, and waiting a while, I eventually received a packet from O2’s GPRS gateway on behalf of my handset:

No. Time Source Destination Protocol Length
396 90.647910000 WTP+WSP 208 WSP Connect (0x01)
Frame 396: 208 bytes on wire (1664 bits), 208 bytes captured (1664 bits) on interface 0
Interface id: 0
Encapsulation type: Linux cooked-mode capture (25)
Arrival Time: May 26, 2013 12:42:54.674299000 BST
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1369568574.674299000 seconds
[Time delta from previous captured frame: 0.371763000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 90.647910000 seconds]
Frame Number: 396
Frame Length: 208 bytes (1664 bits)
Capture Length: 208 bytes (1664 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: sll:ip:udp:wtp:wsp]
Linux cooked capture
Packet type: Unicast to us (0)
Link-layer address type: 1
Link-layer address length: 6
Source: c4:3d:c7:bf:6f:8e (c4:3d:c7:bf:6f:8e)
Protocol: IP (0x0800)
Internet Protocol Version 4, Src: (, Dst: (
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
0000 00.. = Differentiated Services Codepoint: Default (0x00)
…. ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
Total Length: 192
Identification: 0x78fb (30971)
Flags: 0x00
0… …. = Reserved bit: Not set
.0.. …. = Don't fragment: Not set
..0. …. = More fragments: Not set
Fragment offset: 0
Time to live: 101
Protocol: UDP (17)
Header checksum: 0xea17 [correct]
[Good: True]
[Bad: False]
Source: (
Destination: (
User Datagram Protocol, Src Port: 26131 (26131), Dst Port: 9201 (9201)
Source port: 26131 (26131)
Destination port: 9201 (9201)
Length: 172
Checksum: 0xd37c [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Wireless Transaction Protocol, PDU: Invoke (1), Transaction Class: Reliable Invoke with Reliable Result (2)
0… …. = Continue Flag: No TPI
.000 1… = PDU Type: Invoke (0x01)
…. .01. = Trailer Flags: Last packet of message (0x01)
…. …0 = Re-transmission Indicator: First transmission
0… …. …. …. = TID Response: Original
.001 0010 1001 0101 = Transaction ID: 0x1295
00.. …. = Version: Current (0x00)
..1. …. = TIDNew: TID is new
…0 …. = U/P flag: User Acknowledgement optional
…. 00.. = Reserved: 0x00
…. ..10 = Transaction Class: Reliable Invoke with Reliable Result (0x02)
Wireless Session Protocol, Method: Connect (0x01), Version: 1.0
PDU Type: Connect (0x01)
0001 …. = Version (Major): 1
…. 0000 = Version (Minor): 0
Capabilities Length: 19
Headers Length: 136
Client SDU Size: 350000
Protocol Options: (confirmed push facility) (session resume facility)
1… …. = Confirmed Push facility: True
.0.. …. = Push facility: False
..1. …. = Session Resume facility: True
…0 …. = Acknowledgement headers: False
…. 0… = Large data transfer: False
Method MOR: 4
Push MOR: 1
Server SDU Size: 350000
User-Agent: BlackBerry8520/ (ShazamId_SmartWorld_Iota__2.8.2/BBAWFREE) CLDC-1.1 MIDP-2.1
Content-Language: Uighur (ug)
Cache-Control: no-transform
X-Rim-Transcode-Content: none
Connection: close
0000 00 00 00 01 00 06 c4 3d c7 bf 6f 8e 00 00 08 00 …….=..o…..
0010 45 00 00 c0 78 fb 00 00 65 11 ea 17 52 84 dd e9 E…x…e…R…
0020 c0 a8 01 04 66 13 23 f1 00 ac d3 7c 0a 12 95 22 ….f.#….|…"
0030 01 10 13 81 08 04 80 95 ae 30 02 82 a0 02 83 04 ………0……
0040 02 84 01 04 81 95 ae 30 a9 42 6c 61 63 6b 42 65 …….0.BlackBe
0050 72 72 79 38 35 32 30 2f 35 2e 30 2e 30 2e 36 38 rry8520/
0060 31 38 35 32 30 2f 35 2e 30 2e 30 2e 36 38 31 20 18520/
0070 28 53 68 61 7a 61 6d 49 64 5f 53 6d 61 72 74 57 (ShazamId_SmartW
0080 6f 72 6c 64 5f 49 6f 74 61 5f 5f 32 2e 38 2e 32 orld_Iota__2.8.2
0090 2f 42 42 41 57 46 52 45 45 29 20 43 4c 44 43 2d /BBAWFREE) CLDC-
00a0 31 2e 31 20 4d 49 44 50 2d 32 2e 31 00 8c ff 88 1.1 MIDP-2.1….
00b0 88 58 2d 52 69 6d 2d 54 72 61 6e 73 63 6f 64 65 .X-Rim-Transcode
00c0 2d 43 6f 6e 74 65 6e 74 00 6e 6f 6e 65 00 89 80 -Content.none…

view raw


hosted with ❤ by GitHub

Unfortunately, it seems that connections are not always successful – presumably due to either WAPBox/BearerBox configuration issues, or problems with connectivity between the GPRS gateway, my handset, and my network.

(I suspect that O2 occasionally block third-party gateway connectivity, or that the BlackBerry OS WAP stack copes badly with multiple failed connection attempts).

Connectivity problems aside, this might be a useful way of debugging/testing applications using cellular data networking on handsets without a Wi-Fi radio.

Repackaged CryptoRF/LibNFC Example Code

Posted March 30, 2013 by Tyson Key
Categories: Everything

Tags: , , , , , , , ,

Earlier, I tried to build the “NFC-CryptoRF” example code from the LibNFC Wiki, without success against LibNFC 1.7.0-rc4-9-g3584338, under Ubuntu 12.10.

Unsurprisingly, thanks to the LibNFC developers constantly changing their public APIs (for good reasons, I’m sure), said example code has succumbed to bit-rot, and only builds against obsolete versions of LibNFC.

Therefore, it seems that the only immediately obvious way for this code to be useful is to either downgrade the installed library version, or attempt to fix the hacky code to compensate for changes.

Luckily, after temporarily uninstalling my trunk version; downloading, and installing a LibNFC 1.3.4 source archive, applying the patch from a member of the LibNFC Forums to the example code, and attempting to rebuild everything, it seems that the example code works as it should.

After reinstating my modern LibNFC version; configuring 1.3.4’s build process to install to a temporary directory, copying the resulting ancient shared object file to “” in the example code directory, and creating a wrapper shell (“crf134“) script based upon the arguments passing technique mentioned here, it seems that I can now enjoy being able to use this tool, alongside more modern, “global” versions of LibNFC…

Anyway, to save others the hassle, I’ve uploaded the resulting product to Google Code.

As proof of peaceful co-existence with a more modern version of LibNFC:

tyson@tyson-HP-Compaq-2510p-Notebook-PC:~/CM$ ./crf134 0 0 0 0
CryptoRF example – (c) Radboud University Nijmegen
Connected to NFC device: ACS ACR122U 00 00 / ACR122U103 – PN532 v1.6 (0x07)
The following (NFC) ISO14443-B tag was found:
ATQB: 50 ff ff ff ff ff ff ff 33 00 10 51
ID: 01 3d 84 04
CID: 00
PARAMS: 08 00 04 d4
Changing active userzone
R: 11 00
T: 11 00 00
Reading first Ci(0) from the system zone (offset = 0x50)
R: 16 00 50 07
T: 16 00 88 ff ff ff ff ff ff ff 00
* Computing authentication values with card secret
Authenticate using Gc, Ci and random Q
R: 18 00 c9 73 ee ed 1d 5e cc e0 bd d9 9e 4e f3 91 a9 09
T: 18 41 a9
Reading new Ci value from the system zone (tag-answer)
R: 16 00 50 07
T: 16 00 00 ff ff ff ff ff ff ff 00
ERROR: Authentication failed
tyson@tyson-HP-Compaq-2510p-Notebook-PC:~/CM$ nfc-list
nfc-list uses libnfc libnfc-1.7.0-rc4-9-g3584338
NFC device: ACS ACR122U 00 00 / ACR122U103 opened

view raw


hosted with ❤ by GitHub

Finally, in order to satisfy the terms of the (L)GPL, I have also included the original, uncompressed LibNFC 1.3.4 archive, the patched example source code, a copy of the patch, and the unpacked LibNFC directory containing both source, and 32-bit Linux binaries.

Finally, CryptoRF

Posted March 29, 2013 by Tyson Key
Categories: Everything

Tags: , , , , , , , ,

Yesterday, I finally received a package from Atmel USA containing some sample ISO/IEC14443 Type-B CryptoRF tags, after numerous failed attempts at requesting some via their sample request form.

I ordered 1 sample of the 8KB AT88SC0808CRF-MX1 variant, and 2 samples of the 4KB AT88RF04C-MX1G variant.

The 4KB tags seem to be unusually packaged, and I don’t know if it’d be safe to carefully attempt to cut the strip in half using scissors, in order to make it easier to work with each:

I was probably expecting to receive paper-mounted tags, similar to my FeliCa Lite, and MiFare UltraLight ones – but the product seems to work as advertised.

Curiously, I was able to trigger an unusual hardware glitch in the PN532 chipset, if I carefully placed the strip of 4KB tags in the reader’s field in a specific way, which manifested in the following output from nfc-list -v:

1 ISO14443B passive target(s) found:
ISO/IEC 14443-4B (106 kbps) target:
PUPI: 50 ff ff ff
Application Data: ff ff ff ff
Protocol Info: 22 00 10
* Bit Rate Capability:
* PICC to PCD, 1etu=32/fc, bitrate 424 kbits/s supported
* PCD to PICC, 1etu=32/fc, bitrate 424 kbits/s supported
* Maximum frame sizes: 16 bytes
* Frame Waiting Time: 0.6041 ms

view raw


hosted with ❤ by GitHub

I’ve also uploaded a USB trace file demonstrating this phenomenon, here.

It seems that I’m supposed to see this, instead:

1 ISO14443B passive target(s) found:
ISO/IEC 14443-4B (106 kbps) target:
PUPI: ff ff ff ff
Application Data: ff ff ff 22
Protocol Info: 00 10 51
* Bit Rate Capability:
* PICC supports only 106 kbits/s in both directions
* Maximum frame sizes: 24 bytes
* Frame Waiting Time: 9.666 ms
* Frame options supported: NAD

view raw


hosted with ❤ by GitHub

Unsurprisingly, I can’t seem to be able to reliably read either of these two, without even more careful positioning – which suggests anti-collision problems (probably since both have the same unique ID, as supplied)…

The 8KB version, and its accompanying protective packaging looks like:

(Hand not included!)

…and nfc-list -v says:

1 ISO14443B passive target(s) found:
ISO/IEC 14443-4B (106 kbps) target:
PUPI: ff ff ff ff
Application Data: ff ff ff 33
Protocol Info: 00 10 51
* Bit Rate Capability:
* PICC supports only 106 kbits/s in both directions
* Maximum frame sizes: 24 bytes
* Frame Waiting Time: 9.666 ms
* Frame options supported: NAD

view raw


hosted with ❤ by GitHub

When I get time, I intend to study the datasheet, and probably play with building TAMA shell scripts, with a view to trying to write another command set dissector.

That said, I have, however tried to compile the sample code on the LibNFC wiki, without success.

Maybe someone else has succeeded in building it against the latest revisions of LibNFC?

Minor Wireshark NFC/RFID Dissector Updates

Posted March 6, 2013 by Tyson Key
Categories: Everything

Tags: , , , , , ,

Recently, I updated my FeliCa, and NXP PN532 Wireshark dissectors to support the following functionality:

PN532 dissector:

  • Support for dissection of MiFare command payloads in PN532 InDataExchange packets (bug #8291)
    • This means that command packets (but not responses) from tools such as MFOC, and the tools from LibNFC for accessing MiFare Classic, and MiFare UltraLight tokens are dissected.
  • Support for dissection of FeliCa payloads in PN532 InCommunicateThru packets (bug #8246)
    • This means that dissection of packets from almost all of an “NFC Tag Type 3” (barring NDEF payload data) tag reading session should be dissected, using the FeliCa “flavour” of notation.

FeliCa dissector:

  • Support for the FeliCa Plug system code (bug #7767)
    • This theoretically means that Sony’s new FeliCa Plug should be identified in “Polling Response” packets.
  • Update to identify commands from the full FeliCa Standard profile (bug #8243)
    • This theoretically means that commands related to enciphered reading/writing, authentication, searching for system/service codes, and requesting system information from the latest FeliCa Standard tokens should be at least identified.

I have also been trying to update Google’s dissectors to work with the latest SVN revisions of Wireshark, with mixed success. However, it seems that project has temporarily stalled – save for some brief exchanges on its mailing list, that didn’t really go anywhere.

Anyway, I remain willing to assist with that effort; and in the interim, I hope that this new functionality is useful.

Notes on installing the MDaemon BlackBerry Enterprise Server component under Windows 7

Posted January 15, 2013 by Tyson Key
Categories: Everything

Tags: , , , ,

Recently, I decided to try and install a demo version of Alt-N’s MDaemon Messaging Server for Windows, out of curiosity.

It seems that the main server component installation completes successfully – although I didn’t try to use any of the newly-installed components, immediately.

Unfortunately, installation of the optional BlackBerry Enterprise Server component fails with:

According to a page on the FalconView Wiki; and an MS KnowledgeBase article, this error relates to a permissions issue on a non-existent directory (C:\Documents and Settings\NetworkService\Application Data\Microsoft\Protect).

Under Windows 7, the equivalent directory is supposed to exist at C:\Windows\ServiceProfiles\NetworkService\AppData\
– but I had to manually create it, after gaining permission to access C:\Windows\ServiceProfiles\NetworkService\.

It seems that a similar error that occurred whilst trying to install a slightly older version of MS SQL Server under Windows XP, has also been reported.

I also ended up uninstalling some existing MS SQL Server 2008 components that were supplied as with other software.

Afterwards, I re-launched the installation process, and got a little further – only to encounter another error:

It appears that rebooting Windows is the favoured workaround for this issue (that apparently relates to a (Microsoft.SqlServer.Setup.Chainer.Workflow.
) being triggered)  – which worked for me, in this scenario, and meant that I was able to successfully use the product.

Unsurprisingly, the official product support KnowledgeBase has limited information regarding installation failures.

That said, others have reported seeing a related error under Windows XP – despite using an Administrator account; and it appears that the problem also occurred with earlier releases of MS SQL Server.

Anyway, I hope that this belated, short post is vaguely useful.

Workaround for VMAlloc errors from Linux-ZFS under Ubuntu 11.10

Posted October 13, 2012 by Tyson Key
Categories: Everything

Tags: , , , , , , , ,

Earlier on, today, I decided to stress-test the “ZFS on Linux” project’s drivers under my Ubuntu VirtualBox VM, by creating a new ZPool spanning two virtual SATA hard disks, and trying to extract a Wireshark SVN source archive within it.

However, after my initial attempt at extracting the archive seemingly stalled, and discovering that the kernel logs were full of “vmap allocation for size 4198400 failed: use vmalloc=<size> to increase size” errors, I ended up reading a page on the MythTV Wiki detailing a similar problem.

Unfortunately, the suggestions provided there weren’t entirely up-to-date with the configuration of GRUB in that version of Ubuntu – although they provided some useful recommendations for identifying a remedy for this issue.

Finally, after searching for “3.0.0-14-generic” within “/boot/grub/grub.cfg”, appending “vmalloc=400M” to the line beginning with “linux /boot/vmlinuz-3.0.0-14-generic“, and rebooting the VM, I was able to successfully unpack the archive, and build the software itself.

Obviously, this is just a temporary method that will probably get broken when upgrading the GRUB, or Linux kernel versions – but I thought that I’d quickly share this workaround, for future reference.

A renovated PureDarwin XMas disk image

Posted August 27, 2012 by Tyson Key
Categories: Everything

Tags: , , , , , , , ,

Recently, I spent a few hours on modifying the “PureDarwin XMas” disk image, in the hope of trying to boot it under VirtualBox, and QEMU, with mixed success.

The modifications themselves entailed the following steps…

  • Using an installation of Mac OS X 10.6 under VirtualBox to mount said disk image
  • Extracting its primary partition from the rather Byzantine partitioning scheme in use using Disk Utility’s new disk image creation feature
  • Re-partitioning the original image to use a standard x86 MBR partitioning scheme, and creating a single partition
  • Mounting the newly created partition image using Disk Copy, again
  • Copying the raw sector contents of the mounted partition image to the newly created MBR partition, using “DD”
  • Installing the Chameleon v2.0-RC4 r684 bootloader

Under some versions of QEMU, it seems to be possible to boot it as far as a working shell, where the startx command can be issued, in order to launch a customised version of WindowMaker:
 However, under VirtualBox on my AMD Phenom II-based HP G62 laptop, booting fails at:

If I attach the modified image to a Ubuntu virtual machine, copy its raw sectors to an SD card, and reboot my laptop with it inserted into a USB card reader, I can also attempt to boot it, and launch WindowMaker with some success:

Unfortunately, the ancient version of XFree86 supplied in the image doesn’t support the AMD graphics chipset in this G62-series model – so graphical corruption, similar to that seen when trying to boot certain old Linux distributions on incompatible hardware can be witnessed.

There is also an unresolved glitch where the image fails to reboot, under certain circumstances, seemingly due to some issues involving file system drivers, and replaying the volume journal during mounting. This problem may also be encountered when trying to boot it from a locked SD card, for the first time.

Anyway, for others wishing to try it, I’ve uploaded a copy of the modified disk image to Google Code.

Let’s Try RTL-SDR! – Part 1

Posted July 26, 2012 by Tyson Key
Categories: Everything

Tags: , , , , , , , , , ,

Recently, I received a device that was originally marketed as a USB DAB/DVB/FM receiver, containing a chipset compatible with the utilities from the RTL-SDR project.

It cost £17.50 (roughly €22.42/2159円/US$27.45, according to WolframAlpha) including free shipping from the US.

What’s in the kit?

The receiver that I ordered was supplied with only a remote control, and a stubby antenna with a magnetic base. No CD-ROMs, or user manuals were included.

About the hardware

The eBay listing page claims that it contains an Elonics E4000 tuner IC, and a RealTek RTL2832U DVB-T demodulator IC.

lsusb -v Reports:

Bus 001 Device 002: ID 0bda:2838 Realtek Semiconductor Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0bda Realtek Semiconductor Corp.
idProduct 0x2838
bcdDevice 1.00
iManufacturer 1 Realtek
iProduct 2 RTL2838UHIDIR
iSerial 3 00000088
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 34
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 4 USB2.0-Bulk&Iso
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 5 Bulk-In, Interface
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 5 Bulk-In, Interface
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 2
Device Status: 0x0000
(Bus Powered)

view raw


hosted with ❤ by GitHub

Installing RTL-SDR, and associated utilities

Download and run the build-gnuradio script, as recommended by Andrew Back:

tysonkey@ubuntu:~/SoftRadio$ wget
–2012-07-19 12:35:19–
Connecting to||:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 29181 (28K) [text/plain]
Saving to: `build-gnuradio'
100%[======================================================================================================================================================>] 29,181 80.8K/s in 0.4s
2012-07-19 12:35:21 (80.8 KB/s) – `build-gnuradio' saved [29181/29181]
tysonkey@ubuntu:~/SoftRadio$ chmod +x build-gnuradio
tysonkey@ubuntu:~/SoftRadio$ ./build-gnuradio
This script will install Gnu Radio from current GIT sources
You will require Internet access from the computer on which this
script runs. You will also require SUDO access. You will require
approximately 500MB of free disk space to perform the build.
This script will, as a side-effect, remove any existing Gnu Radio
installation that was installed from your Linux distribution packages.
It must do this to prevent problems due to interference between
a linux-distribution-installed Gnu Radio/UHD and one installed from GIT source.
The whole process may take up to two hours to complete, depending on the
capabilities of your system.
NOTE: if you run into problems while running this script, you can re-run it with
the –verbose option to produce lots of diagnostic output to help debug problems.
This script has been written to anticipate some of the more common problems one might
encounter building ANY large, complex software package. But it is not pefect, and
there are certainly some situations it could encounter that it cannot deal with
gracefully. Altering the system configuration from something reasonably standard,
removing parts of the filesystem, moving system libraries around arbitrarily, etc,
it likely cannot cope with. It is just a script. It isn't intuitive or artificially
intelligent. It tries to make life a little easier for you, but at the end of the day
if it runs into trouble, a certain amount of knowledge on your part about
system configuration and idiosyncrasies will inevitably be necessary.

view raw


hosted with ❤ by GitHub

At this stage, the script will request elevated privileges, in order to search for prerequisite packages using the system package management utilities.

Since the disclaimer warns that the process may take a long time, I’d recommend obtaining one’s favourite beverage; ensuring that the PC used has a sufficient amount of free disk space, and is well-ventilated (if using a laptop), to prevent it from potentially overheating, and unexpectedly shutting down; and searching for something else to do in the meantime…

For some reason, the Checking for package python-gtk2 step seems to take an unusually long time on my laptop; and temporarily stopping the script yielded:

^CFailed to find just-installed command 'guile' after pre-requisite installation.
This very likely indicates that the pre-requisite installation failed
to install one or more critical pre-requisites for Gnu Radio/UHD

view raw


hosted with ❤ by GitHub

It seems that despite my best efforts to prepare things in advance, I ran out of disk space at that stage:

Checking for library libusb …Found library libusb
Checking for library libboost …Found library libboost
Checking for library libcppunit …Found library libcppunit
Checking for library libguile …Found library libguile
Checking for library libfftw …Found library libfftw
Checking for library libgsl …Found library libgsl
Fetching Gnu Radio via GIT…Could not find gnuradio/gnuradio-core after GIT checkout
GIT checkout of Gnu Radio failed!

view raw


hosted with ❤ by GitHub

Eventually, I resorted to running apt-get clean && apt-get autoclean, and moving some large files to an external disk, in order to free 1.5GB of 9.4GB; and re-ran the script, with more successful results:

Starting function uhd_build at: Thu Jul 19 13:43:39 BST 2012
Building UHD…
Done building/installing UHD
Done function uhd_build at: Thu Jul 19 14:00:07 BST 2012
Starting function firmware at: Thu Jul 19 14:00:07 BST 2012
Downloading images from:
6.94 MB/6.94 MB (100.00%)
Images successfully installed to: /usr/local/share/uhd/images
Done downloading firmware to /usr/local/share/uhd/images
Done function firmware at: Thu Jul 19 14:00:19 BST 2012
Starting function gnuradio_build at: Thu Jul 19 14:00:19 BST 2012
/usr/local/lib already in
Doing ldconfig…
Building Gnu Radio…
…Doing cmake
Application asked to unregister timer 0x45000016 which is not registered in this thread. Fix application.
Done building and installing Gnu Radio
GRC freedesktop icons install …Done
Done function gnuradio_build at: Thu Jul 19 14:41:05 BST 2012
Starting function rtl_build at: Thu Jul 19 14:41:05 BST 2012
Building rtl-sdr…
Done building/installing rtl-sdr/gr-osmosdr
Done function rtl_build at: Thu Jul 19 14:42:46 BST 2012
Starting function extras at: Thu Jul 19 14:42:46 BST 2012
Doing GIT checkout for extra module gr-baz
Building extra module gr-baz
Doing GIT checkout for extra module grextras
Building extra module grextras
Done function extras at: Thu Jul 19 14:51:02 BST 2012
Starting function mod_groups at: Thu Jul 19 14:51:02 BST 2012
This script has just modified /etc/group to place your userid '('$USER')' into group 'usrp'
In order for this change to take effect, you will need to log-out and log back
in again. You will not be able to access your USRP1 device until you do this.
If you wish to allow others on your system to use the USRP1 device, you will need to use:
sudo usermod -a -G usrp userid
For each userid you wish to allow access to the usrp
Done function mod_groups at: Thu Jul 19 14:51:03 BST 2012
Starting function mod_udev at: Thu Jul 19 14:51:03 BST 2012
Done function mod_udev at: Thu Jul 19 14:51:03 BST 2012
Starting function mod_sysctl at: Thu Jul 19 14:51:03 BST 2012
Applying updates to /etc/sysctl.conf
Group 'usrp' now has real-time scheduling privileges
You will need to log-out and back in again for this to
take effect
Done function mod_sysctl at: Thu Jul 19 14:51:03 BST 2012
Starting function pythonpath at: Thu Jul 19 14:51:03 BST 2012
You should probably set your PYTHONPATH to:
export PYTHONPATH=/usr/local/lib/python2.7/dist-packages
in your .bashrc or equivalent file prior to attempting to run
any Gnu Radio applications or Gnu Radio Companion.
Done function pythonpath at: Thu Jul 19 14:51:04 BST 2012
Done all functions at: Thu Jul 19 14:51:04 BST 2012
All Done

view raw


hosted with ❤ by GitHub

It seems that on a 64-bit Ubuntu installation, a full instance of the script’s working directory (containing all source code, and binaries) is about 520MB in size.

Notes on AirProbe installation

For readers wishing to install AirProbe using the instructions on the project’s Website, I recommend running sudo ln -s /usr/local/include/gruel/swig/gruel_common.i /usr/local/include/gnuradio/swig/ && ldconfig, after installing GNURadio, in order to avoid some frustrating bugs in various build scripts related to missing “Gruel”, and “SWIG”-related files.

Testing the result

Since this post is becoming rather long, and I’m unsatisfied with the content that I planned for this section, I’ll follow up with a second post related to testing the software post-installation, soon.