Downloading Sony GPS Assist Data Manually

After having bought a new Sony DSC-HX5V digital camera, which is equipped with an integrated GPS, I discovered that it comes with windows-only software for downloading and updating the GPS almanac on the camera (the supplied PMB Portable software runs on Apple OS X, but it does not support downloading the GPS almanac).

After tinkering a bit with tcpdump(1) and friends I found out how to perform the download and update manually:

  1. Download assistme.dat
  2. Download assistme.md5
  3. Verify that the MD5 sum of the assistme.dat file matches the one in the assistme.md5 file
  4. Create a top-level folder hierarchy on the memory card for the camera (not the internal memory of the camera) called PRIVATE/SONY/GPS/
  5. Place the downloaded assistme.dat file in the PRIVATE/SONY/GPS/ folder
  6. Place the memory card in the camera and verify that the GPS Assist Data is valid

I have written a small perl script for automating the above tasks. The script takes the mount point of the memory card as argument.

Monitoring Soekris Temperature through SNMP

Here’s a quick tip for monitoring the temperature of your Soekris net4801 through SNMP on FreeBSD:

Install the net-mgmt/bsnmp-ucd and sysutils/env4801 ports and add the following to /etc/snmpd.conf:

begemotSnmpdModulePath."ucd" = "/usr/local/lib/"
extNames.0 = "temperature"
extCommand.0 = "/usr/local/sbin/env4801 | /usr/bin/grep ^Temp | /usr/bin/cut -d ' ' -f 6"

Enable and start bsnmpd(1). The temperature of your Soekris net4801 can now be queried through UCD-SNMP-MIB::extOutput.0 OID (

Plotting Load Average as Floating Point using MRTG

The web is flooded with examples of how to use the popular MRTG software for plotting more exotic SNMP OIDs than just network traffic.

One of the more popular variables to graph seems to be the load average of a given system, but all of the examples I have stumpled upon online compromise when it comes to plotting the load average as a floating point value.

It is, however, possible to post-process the gathered statistics before plotting the graph and the legend using the YTicsFactor and Factor keywords as shown in the example below:

Options[load]: gauge, nopercent, noo
MaxBytes[load]: 100
Title[load]: 5 Minute Load Average
PageTop[load]: <h1>5 Minute Load Average</h1>
YLegend[load]: Load Average
ShortLegend[load]: &nbsp;
Legend1[load]: 5 Minute Load Average
Legend3[load]: Maximum Observed Load Average
LegendI[load]: &nbsp;Load Average:
YTicsFactor[load]: 0.01
Factor[load]: 0.01

The above example will gather the 5 minute load average as an integer value (average load x 100) of localhost and use a scaling factor of 0.01 before actually plotting the graph.

Judging from the examples I have found online, the noo option and the PseudoZero pseudo OID used in the example are other, often overlooked features of MRTG. The noo option specifies that no “Output” graph shall be plotted while the PseudoZero pseudo OID always returns 0 (whereas noi disables the “Input” graph and PseudoOne always returns 1).

Booting nanoBSD on the Alix2c2 SBC

A friend and I recently purchased a couple of Alix2c2 SBCs from PC Engines with the intention of running FreeBSDs nanoBSD on them.

However, getting nanoBSD to boot on the Alix board turned out to require a few customizations which I will post here in the hope of saving others the trouble.

The Alix2c2 reports the following at boot time for the noname 1GB CF card from PC Engines:

PC Engines ALIX.2 v0.99
640 KB Base Memory
261120 KB Extended Memory

01F0 Master 044A CF 1GB                                  
Phys C/H/S 1966/16/63 Log C/H/S 983/32/63

Running diskinfo(8) on the CF in an USB CF card reader on another FreeBSD machine revealed the capacity of the card:

$ diskinfo /dev/da0
/dev/da0        512     1014644736      1981728 967     64      32

Gettng nanoBSD to boot on the Alix2c from the 1GB CF card required the following customizations to the nanoBSD configuration file:

# Drive geometry
NANO_MEDIASIZE=`expr 1014644736 / 512` # size from diskinfo(8) on the UBS CF card reader
NANO_HEADS=32 # heads from the logic CHS information at boot time
NANO_SECTS=63 # sects from the logic CHS information at boot time

# Boot loader
NANO_BOOT0CFG="-o nopacket -s 1 -m 3" # nopacket seems to be required by tinyBIOS

Before booting nanoBSD, hit ‘s’ on the Alix2c2 serial console during RAM testing and switch the BIOS to LBA mode and 9600 baud serial console (default is 38400 baud, but this wont work with boot0sio). Re-attach to the serial console with 9600 baud and reboot to verify the setup.

Apple iPhone (3G) vs. FreeBSD, take I

No, this post won’t be able to tell you how to synchronize contacts, calendar, bookmarks etc. from your FreeBSD box to your iPhone or iPhone 3G, sorry – still working on that. It will, however, show you how to make FreeBSD recognize your iPhone as a camera device, so that you can download the photos taken with your iPhone to a FreeBSD host.

First of all, make sure you’re using a kernel with ugen(4) support – but either without uhid(4) support or FreeBSD 8-CURRENT in SVN revision 181482 or newer – or manually apply this patch:

[Update: I have just MFC’ed this patch to RELENG_7 (SVN revision 181636) and RELENG_6 (SVN revision 181637), so this patch will be included in FreeBSD 7.1 and 6.4].

Index: sys/dev/usb/usb_quirks.c
--- sys/dev/usb/usb_quirks.c	(revision 181481)
+++ sys/dev/usb/usb_quirks.c	(working copy)
@@ -106,6 +106,10 @@
  /* Devices which should be ignored by both ukbd and uhid */
Index: sys/dev/usb/usbdevs
--- sys/dev/usb/usbdevs	(revision 181481)
+++ sys/dev/usb/usbdevs	(working copy)
@@ -853,6 +853,8 @@
 product APPLE IPOD_08		0x1208	iPod '08'
 product APPLE IPODVIDEO		0x1209	iPod Video
 product APPLE IPODNANO		0x120a	iPod Nano
+product APPLE IPHONE		0x1290	iPhone
+product APPLE IPHONE_3G		0x1292	iPhone 3G
 product APPLE ETHERNET		0x1402	Ethernet A1277
 /* Arkmicro Technologies */

Next, make sure you have graphics/gphoto2 and graphics/libgphoto2 (the latter needs to be 2.4.2_1 or later for the iPhone 3G to work) installed.

Plug in the USB cable from your iPhone and verify using dmesg(8) that it shows up as an ugen(4) device as shown below:

kernel: ugen1: <Apple Inc. iPhone, class 0/0, rev 2.00/0.01, addr 2> on uhub4

That’s it – you should now be able to access the photos on your iPhone using ghoto2(1) – just replace ‘Apple iPhone (PTP Mode)’ with ‘Apple iPhone 3G (PTP Mode)’ for the iPhone 3G:

$ gphoto2 --camera 'Apple iPhone (PTP Mode)' -L
There is no file in folder '/'.                                                
There is no file in folder '/store_00010002'.
There is no file in folder '/store_00010002/DCIM'.
There are 7 files in folder '/store_00010002/DCIM/100APPLE'.
#1     IMG_0007.JPG                   49 KB image/jpeg
#2     IMG_0013.JPG                  389 KB image/jpeg
#3     IMG_0022.JPG                   26 KB image/jpeg
#4     IMG_0026.JPG                  358 KB image/jpeg
#5     IMG_0027.JPG                  357 KB image/jpeg
#6     IMG_0028.JPG                  381 KB image/jpeg
#7     IMG_0029.JPG                  377 KB image/jpeg
There is no file in folder '/store_00010002/DCIM/999APPLE'.

See the gphoto2(1) man page for further usage instructions.

Of course, you can also use a graphical client such as graphics/gtkam as long as it uses libgphoto2 for camera access.

Life is too short for (cheap) hardware

I recently acquired a Revoltec Alu Book USB mass storage enclosure for a 2.5″ PATA HDD, which is based on the Myson CE8818 chipset and therefore matched by the (wrongly named, as this matches all CE8818 based devices) following USB quirk in FreeBSD -current:


The enclosure worked fine for a while, but then started to fail under FreeBSD with heavy disk activity, spewing the following messages in dmesg:

kernel: umass0: on uhub4
root: Unknown USB device: vendor 0x04cf product 0x8818 bus uhub4
kernel: da0 at umass-sim0 bus 0 target 0 lun 0
kernel: da0: < > Removable Direct Access SCSI-2 device
kernel: da0: 40.000MB/s transfers
kernel: da0: 114473MB (234441648 512 byte sectors: 255H 63S/T 14593C)
kernel: (da0:umass-sim0:0:0:0): READ(10). CDB: 28 0 8 45 78 6f 0 0 48 0
kernel: (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error
kernel: (da0:umass-sim0:0:0:0): SCSI Status: Check Condition
kernel: (da0:umass-sim0:0:0:0): ILLEGAL REQUEST asc:20,0
kernel: (da0:umass-sim0:0:0:0): Invalid command operation code
kernel: (da0:umass-sim0:0:0:0): Unretryable error
kernel: g_vfs_done():da0s1a[READ(offset=71050477568, length=36864)]error = 22
kernel: vnode_pager_getpages: I/O read error
kernel: vm_fault: pager read error, pid 27989 (cp)

cp(1), which I used for reproducing the problem, said cp: /foo/bar/baz.txt: Bad address and the destination file was corrupt.

I investigated the possible course of the failure. A dying disk? A quirky chipset? A change in the FreeBSD umass(4) driver or something else?

After having spent weeks of debugging this periodical error, it eventually turned out to be a dying USB HDD enclosure.

Close examination of the PCB showed that some of the lines connecting the HDD connector to the chipset had clearly been repaired before shipping this unit, but no coat of varnish had been given afterwards – leading to corrosion of the PCB over time.

I have just replaced the USB HDD enclosure with a new one (from a different vendor, of course) – and I can no longer reproduce the above problem with the same HDD installed.

Lesson learned: Life is too short for dealing with (cheap) hardware.

FreeBSD Ports commit bit

Someone decided to punish me with a commit bit for FreeBSD Ports – ironically, that same person decided to punish himself by being my mentor :)

Erwin even handed me a sealed envelope containing a piece of paper with a large ‘1’ printed on it at our latest meeting – I must admit, it took me a while to figure out that it was a ports commit bit!

Anyways, as FreeBSD Ports is in a freeze right now, preparing for the upcoming 6.3 and 7.0 releases, I guess I won’t be committing anything interesting for now…

Soekris BIOS upgrade using cu(1) and lsx(1)

Here’s a quick HOWTO for updating a Soekris net4801 BIOS using cu(1) and lsx(1) from comms/lrzsz under FreeBSD.

First, establish contact to the BIOS using something like ‘cu -l /dev/ttyU0 -s 19200’ adjusted to fit the device node and speed used in your setup. Then follow these steps:

  1. Press Ctrl+P to enter the Soekris BIOS monitor
  2. Type download -
  3. Press ~C
  4. Type lsx /path/to/b4801_131.bin

If the XMODEM transfer was successful, continue with the following steps:

  1. Type flashupdate
  2. Type reboot
  3. Press ~. to exit cu(1)

That’s it! The BIOS should now be updated :)

RS-232 level converter for the Linksys WRT54G

Some time ago I got my hands on a bunch of more or less broken Linksys 802.11 APs and wireless routers. They have been sitting in my closet until recently, when I decided to mock a bit with one of the WRT54G models.

First things first – I had to establish contact with the onboard firmware. Since the board didn’t respond on any of the ethernet interfaces I set out to construct an RS-232 level converter to use with the onboard 3.3V TTL serial interface.

Judging from google, people use all kinds of weird and somewhat complicated (not to mention quite expensive) circuits in order to convert the voltage levels of the WRT54G serial interface to RS-232 levels. I decided to go with my own simple, cheap and effective design based on the Maxim MAX3232 as shown below:

RS-232 Level Converter

The pinout of the IDC connector on the Linksys WRT54G – X3 in the diagram above – is as follows (thanks to Rod Whitby for posting information on the pinouts, saved me a bit of trial-and-error):

Pin # Description Pin # Description
1 3.3V 2 3.3V
3 Tx (ttyS1) 4 Tx (ttyS0)
5 Rx (ttyS1) 6 Rx (ttyS0)
7 NC 8 NC
9 GND 10 GND

The onboard firmware of the WRT54G provides a console on ttyS0 at 115200 1N8. Since the above pinout lacks RTS/CTS lines we have to rely on software flow control.

To connect to the console one might use a command like cu(1):

$ cu -l /dev/ttyU0 -s 115200

Below is a couple of action-shots of the circuit in use:

Action Shot 1

Action Shot 2

The next logical step is to get FreeBSD/mips up and running on this thing ;-)

System monitoring wallpaper

Several people have asked me about the system monitor running on the root window of my ThinkPad X60s’ X11 desktop – not many of them had spotted that is was actually just conky with an advanced configuration and a custom wallpaper:


My ~/.conkyrc can be downloaded from here. The panel at the bottom center is from FluxBox, my window manager of choice. The panel to the left is fbpager, a desktop pager for use with FluxBox.