Simplify extension for SilverStripe hides children pages in the SiteTree / TreeView

Simplify is an extension for the popular SilverStripe Content Management System (CMS). Its purpose is to simplify the use of the admin interface by allowing fine-grained permissions as to which users should be allowed to see which options.
Continue reading

Dissecting an Edimax IC-3116W IP camera

As an overview:

  • System-on-Chip: RealTek RTL8197D
  • Embedded CPU: RealTek RLX5281 @ 660 MHz, MIPS16 instruction set, 64KB instruction cache, 32KB data cache
  • Embedded LAN controller: RealTek RTL8196C, two Ethernet MACs (only one used)
  • Embedded USB controller: RealTek RTL8652, USB 2.0
  • External flash memory chip: Macronix MX25L6405D, 3V, 64MBit (= 8MB)
  • External RAM chip: Nanya NT5TU32M16DG-AC, 64MB
  • External WLAN controller chip: RealTek RTL8188ER, IEEE 802.11bgn, 2.4 GHz, 150 MBit
  • WLAN antenna: Internal, U.FL connector

Continue reading

Connecting to libvirtd as non-root user on openSUSE 13.1

As a revisit to my previous post on connecting to libvirtd as a non-root user on openSUSE 12.2, the way to do it on openSUSE 13.1 is the same that worked for Marek Goldmann on Fedora 18 (although he used the wheel group).

Create /etc/polkit-1/rules.d/80-libvirt-manage.rules with the following content:

polkit.addRule(function(action, subject) {
    if ( == "org.libvirt.unix.manage" && == true && subject.local == true &&
        subject.isInGroup("libvirt")) {
            return polkit.Result.YES;

And add the user accounts that should be allowed access to the libvirt group.

Patching VirtualBox guest additions for SLES12/RHEL7 guests

This may not be relevant to most of you, yet, as the SLES12 and RHEL7 beta programs are not quite open to the public, but similar problems may happen to you with other distributions that do backports of patches as well.

If you see error messages such as the following when compiling VirtualBox guest additions for your Linux guest:

/tmp/vbox.0/r0drv/linux/memobj-r0drv-linux.c: In function ‘rtR0MemObjNativeMapUser’:
/tmp/vbox.0/r0drv/linux/memobj-r0drv-linux.c:1542:26: error: ‘struct mm_struct’ has no member named ‘numa_next_reset’
                 pTask->mm->numa_next_reset = jiffies + 0x7fffffffffffffffUL;
make[2]: *** [/tmp/vbox.0/r0drv/linux/memobj-r0drv-linux.o] Error 1
make[1]: *** [_module_/tmp/vbox.0] Error 2
make: *** [vboxguest] Error 2

You should take a look at VirtualBox ticket #12638 which deals with the removal of the numa_balancing_scan_period_reset sysctl and related data structures. I just submitted a patch there that tries to address the issue of distro vendor backports of patches in a less expensive way than grepping header files.

If you want to try it out, also have a look at How to recreate / build VirtualBox guest additions ISO image VBoxGuestAdditions.iso.

How to recreate / build VirtualBox guest additions ISO image VBoxGuestAdditions.iso

As Linux kernel development progresses, so do interfaces change from time to time and kernel modules outside of the Linux kernel such as VirtualBox’s guest additions need more or less updating. Having done some patching in the VirtualBox sources, you might want to rebuild the guest additions ISO image, VBoxGuestAdditions.iso, so you can try out the patched code in your VMs more easily.

Googling for “building VBoxGuestAdditions.iso” you might find this vbox-dev mailing list thread from 2011 which suggests that the ISO could not be easily rebuilt as a special build setup would be needed. However, it turns out this is not quite true:

pief@e6400:~/vbox/src/VBox/Additions> kmk additions-iso
kBuild: copydbg /home/pief/vbox/out/linux.amd64/release/bin/additions/VBoxControl - /home/pief/vbox/out/linux.amd64/release/obj/Additions/Installer/linux/debug/bin/VBoxControl
kBuild: Installing /home/pief/vbox/out/linux.amd64/release/obj/Additions/Installer/linux/lib/VBoxGuestAdditions/mount.vboxsf
kBuild: Packing /home/pief/vbox/out/linux.amd64/release/bin/additions/VBoxGuestAdditions-amd64.tar.bz2
Header is 404 lines long

About to compress 5440 KB of data...
Adding files to archive named "/home/pief/vbox/out/linux.amd64/release/bin/additions/"...
CRC: 1167516186
MD5: eb794c6b2981e2042a81f475f060be18

Self-extractible archive "/home/pief/vbox/out/linux.amd64/release/bin/additions/" successfully created.
kBuild: mkisofs - /home/pief/vbox/out/linux.amd64/release/bin/additions/VBoxGuestAdditions.iso
/usr/bin/genisoimage -rational-rock -joliet -iso-level 3 \
-volid "VBOXADDITIONS_4.3.53_50574" -l -graft-points -o /home/pief/vbox/out/linux.amd64/release/bin/additions/VBoxGuestAdditions.iso \
[...] \

I: -input-charset not specified, using utf-8 (detected in locale settings)
Total translation table size: 0
Total rockridge attributes bytes: 269
Total directory bytes: 0
Path table size(bytes): 10
Max brk space used 0
2906 extents written (5 MB)
kBuild: Zipping image /home/pief/vbox/out/linux.amd64/release/bin/additions/
adding: VBoxGuestAdditions.iso (deflated 8%)
pief@e6400:~/vbox/src/VBox/Additions> dir

In my case, I found the new ISO image in ~/vbox/src/out/linux.amd64/release/bin/additions/VBoxGuestAdditions.iso. Copying that file to /usr/share/virtualbox should make it available to your VMs.

Flashing the D-Link DBT-120 to become a HID proxy-capable USB bluetooth adapter

As pointed out in my previous post, I was looking into flashing the D-Link DBT-120 USB bluetooth adapter with Apple’s Bluetooth Firmware update so it becomes HID proxy-capable.

D-Link DBT-120 USB bluetooth adapter

D-Link DBT-120 USB bluetooth adapter

Now I do not have any machine running MacOS X, so I could not simply download and run Apple’s tool and was therefore looking into alternatives, aiming at extracting the firmware from Apple’s download somehow and using other means to flash the firmware. And obviously I wasn’t the only one.

Extracting the firmware

After downloading from Apple you’ll have a file BluetoothFWUpdate1.2.dmg. .dmg files are basically Apple Disk images, representing so-called volumes. In the simplest case running Linux’s file utility on such a .dmg would give you an output such as:

$ file example.dmg
example.dmg: Macintosh HFS Extended version 4 data last mounted by: ’10.0′, created: Fri Jan 30 11:12:33 2009, last modified: Fri Jan 23 12:09:55 2009, last checked: Fri Feb 07 04:22:58 2009, block size: 4096, number of blocks: 6400, free blocks: 218

In such a case you would be able to mount it with a command such as modprobe hfsplus; mount -t hfsplus -o loop example.dmg /mnt.

In our case, however, things are a bit more complicated:

$ file BluetoothFWUpdate1.2.dmg
BluetoothFWUpdate1.2.dmg: VAX COFF executable

file gets a bit confused here: in reality this is a compressed .dmg file that requires a conversion with the dmg2img utility. Download it, make sure you have zlib and bzip2 development headers installed and run make to compile it. Then, run it like this:

$ dmg2img-1.6.5/dmg2img BluetoothFWUpdate1.2.dmg
dmg2img v1.6.5 (c) vu1tur (

BluetoothFWUpdate1.2.dmg --> BluetoothFWUpdate1.2.img

opening partition 0 ... 100.00% ok
opening partition 1 ... 100.00% ok
opening partition 2 ... 100.00% ok
opening partition 3 ... 100.00% ok
opening partition 4 ... 100.00% ok

Archive successfully decompressed as BluetoothFWUpdate1.2.img

Now we have a 1:1 image of a HFS+ filesystem (the filesystem Apple uses) and can mount it:

$ sudo mount -t hfsplus -o loop BluetoothFWUpdate1.2.img /mnt

If we now examine the mounted image’s contents, we’ll find a lot of MacOS X packaging-related files and a file Archive.pax.gz that we care about:

$ cp /mnt/BluetoothFirmwareUpdate1.2.pkg/Contents/Archive.pax.gz .
$ umount /mnt

This file is obviously gzip-compressed, so let’s uncompress and examine it:

$ gunzip Archive.pax.gz
$ file Archive.pax
Archive.pax: ASCII cpio archive (pre-SVR4 or odc)

cpio archives are something we know a bit about in the Unix world, so let’s create a subdirectory to extract its contents:

$ mkdir unpack
$ cd unpack
$ cpio -if < ../Archive.pax 5390 blocks

We'll now again have a quite verbose, MacOS-typical directory structure. Dive deeper and you'll find what we're looking for:

$ cd Applications/Utilities/Bluetooth\ Firmware\
$ ls
total 2324
drwxrwxr-x 17 pief users 4096 Feb 21 21:12 .
drwxrwxr-x 4 pief users 4096 Feb 21 21:12 ..
-rwxrwxr-x 1 pief users 638672 Feb 21 21:12 DeskTop.dfu
drwxrwxr-x 3 pief users 4096 Feb 21 21:12 Dutch.lproj
drwxrwxr-x 3 pief users 4096 Feb 21 21:12 English.lproj
-rw-rw-r-- 1 pief users 34690 Feb 21 21:12 FirmwareDownload.icns
drwxrwxr-x 3 pief users 4096 Feb 21 21:12 French.lproj
-rwxrwxr-x 1 pief users 994866 Feb 21 21:12 GenericCSR.dfu
drwxrwxr-x 3 pief users 4096 Feb 21 21:12 German.lproj
drwxrwxr-x 3 pief users 4096 Feb 21 21:12 Italian.lproj
drwxrwxr-x 3 pief users 4096 Feb 21 21:12 Japanese.lproj
-rwxrwxr-x 1 pief users 638672 Feb 21 21:12 Portable.dfu
drwxrwxr-x 3 pief users 4096 Feb 21 21:12 Spanish.lproj
drwxrwxr-x 3 pief users 4096 Feb 21 21:12 da.lproj

Those .dfu files are what we were looking for, because of their file sizes and, in the case of GenericCSR.dfu, also because of its file name. Remember, we’re going to flash a CSR-based device.

Now it looks like we have three files to choose from: DeskTop.dfu, GenericCSR.dfu and Portable.dfu. “Generic” does suggest to be a good choice as “DeskTop” and “Portable” sound like firmware update files for special cases, but we wouldn’t take a bet on that. Running strings on each of them does not shed light into the darkness, however. But worry not, we’ll see more in a minute once we feed the files to the flash utility.

Flashing the firmware

In general there are two ways to backup and update the firmware of CSR-based USB bluetooth adapters:

  1. under Linux with the BlueZ project‘s dfutool.
  2. under Windows with a software suite from CSR themselves called “BlueSuite”.

I played around with Linux at first, examining the D-Link DBT-120’s properties before the flash upgrade with commands such as lsusb, hciconfig hci0 version and hciconfig hci0 revision. bccmd chiprev and bccmd buildname gave me an error message about an “Unsupported manufacturer”. But, more importantly, dfutool worked and I could get a backup of the existing firmware with dfutool archive dlink-dbt120.dfu.

However, I still wasn’t sure which of the three Apple .dfu files to flash. So I looked around on the Internet for CSR’s BlueSuite software for Windows. I checked their Website and found the CSR Developer Zone. To my surprise, they would let me get myself registered without any barriers, payments or anything. I ignored the warning about the “unknown mail domain” that would cause me “not to have full access” for the moment and was pleasantly surprised to find a BlueSuite 2.5.8 download (plus a user guide) on the “Last updated” page. Nice work, CSR, that’s how things should be! :)

BlueSuite is a collection of different development-related tools, some graphical, some command line-based:

CSR BlueSuite components

CSR BlueSuite components

It also comes with a special driver for accessing the Bluetooth adapter. Prior to installing that driver, if you look at Windows’ device manager and use Microsoft’s built-in Bluetooth stack (ie. not Widcomm, BlueSoleil, CSR Harmony etc.) you should see a “Generic Bluetooth Radio” device in the “Blutooth” category (screenshots from a German Windows version):

"Generic Bluetooth Radio" entry in Windows' Device manager

“Generic Bluetooth Radio” entry in Windows’ Device manager

You should also have a blue Bluetooth icon in the task bar’s notification area.

After installing the BlueSuite’s driver by running drivers\win64\DPInst.exe the Bluetooth icon will disappear and Windows’ device manager will now list an entry “CSR BlueCore Bluetooth” in the “USB controllers” category:

"CSR BlueCore Bluetooth" entry in Windows' device manager

“CSR BlueCore Bluetooth” entry in Windows’ device manager

This is a prerequisite in order to be able to use the BlueSuite utilities including our flashing tool DFUWizard.exe:

DFUWizard's Welcome screen

DFUWizard’s Welcome screen

Choose “USB” as connection method and select one of the three .dfu files we extracted earlier. You’ll notice that DFUWizard shows human-readable descriptions that are more useful than dfutool‘s:

DFUWizard with the DFU file tp flash selected

DFUWizard with the DFU file tp flash selected

GenericCSR.dfu looks to be the right candidate. So we’ll use it for flashing.

WARNING1: Flashing can render your device unusable, eg. if power outages occur or the wrong file is flashed. Do not perform the flashing process unless you know what you’re doing! I can not help you if something goes wrong!

WARNING2: Flashing Apple’s firmware will render your DBT-120 unless you’ve taken care of obtaining hid2hci.exe! Do not ask me for this tool.

DFUWizard flashing the DBT-120 adapter

DFUWizard flashing the DBT-120 adapter

This process should take just a minute and if things go right you should get a result such as this:

DFUWizard after a successful flashing process

DFUWizard after a successful flashing process

Congratulations, you now have a DBT-120 adapter that behaves as a HID proxy. You should now try running hid2hci.exe and pair your input devices again. After a reboot, they should work in the BIOS as well. Remember that returning to Windows you will need to run hid2hci.exe again to get them working. A followup post will deal with automation of this.

The crux of finding a HID proxy-capable USB bluetooth adapter

So, for some not very profound reasons (watching demos and putting my spare Ivy Bridge CPU to a use), I ended up having a living room PC again. And as it’s the living room, input devices must be wireless. Since I’m not a fan of running proprietary wireless technologies that jam my Wifi’s 2.4 GHz band and because of increased usability with other devices such as tablets, I wanted a keyboard and a mouse based on Bluetooth technology. Because of design, functionality and good experiences I bought Microsoft’s Wedge mobile keyboard and Sculpt Touch mouse:

Microsoft Wedge Mobile Keyboard (with German layout)

Microsoft Wedge Mobile Keyboard (with German layout)

Microsoft Sculpt Touch Mouse

Microsoft Sculpt Touch Mouse

All nice and sleek and working within an installed OS but it is only when you’re trying to reinstall your operating system or need to enter your BIOS that bluetooth-based input devices still have a large drawback: they do not work without a Bluetooth driver stack. And during both OS installation and BIOS configuration you do not have one yet. Even the modern UEFI world doesn’t change that.

At least in the PC world — Apple has been using Bluetooth-based input devices for over a decade now and admittedly often went a step forward for the sake of user experience. When the Apple Wireless keyboard was introduced in September 2003, a software update was published that allowed for the wireless keyboard to take control of the boot process.

However, this was strictly speaking not Apple’s merit alone: the software update worked with Cambridge Silicon Radio (CSR)-based adapters only because that very company introduced a technique called HID proxy for its adapters in August 2003 (see their press release “CSR saves stranded mice”).

The idea behind HID proxy is that the bluetooth adapter has additional intelligence that allows it to a.) take over responsibility from the host it’s connected to run and run certain software layers itself and b.) run in this special mode until the OS’s bluetooth stack is loaded and tells it to return to “normal” operation. In HID proxy mode, the adapter communicates on its own with previously paired Bluetooth input devices and emulates to its host a USB keyboard and USB mouse through a HID interface instead of exposing the ordinary HCI interface. As the PC industry has at least succeeded in getting broad USB support into BIOS and OS installation software, this means that the Bluetooth keyboard and mouse will magically work in spite of a missing Bluetooth stack.

You see, Apple did not magically invent an Apple-only, HID proxy-capable bluetooth adapter. In fact, in 2003 the internal Bluetooth modules in their Notebooks were software-compatible with certain revisions of the D-Link USB bluetooth adapter DBT-120. They also didn’t ground-breakingly integrate Bluetooth functionality into their EFI firmware. They just made their Bluetooth hardware default to HID proxy mode until Mac OS X tells it to switch to HCI mode, that’s the whole secret.

D-Link DBT-120 USB bluetooth adapter

D-Link DBT-120 USB bluetooth adapter

However, this means that if you use such a Bluetooth adapter in HID proxy mode, the OS must be aware of it and tell it to switch to HCI mode or you will have no Bluetooth functionality once it’s loaded. And to my knowledge no Windows Bluetooth stack does, not even Microsoft’s own stack in the latest Windows 8.1.

For this very reason, Apple, on its Bluetooth Firmware Update 1.2 Download page, warned that applying that update “[…] to a D-Link USB to Bluetooth adapter will make it incompatible with non-Macintosh systems”. Which, back then, yet seems to have been overseen by a number of users, considering this FAQ page by German computer magazine c’t. Yet, this does not mean a DBT-120 flashed with the Apple update is bricked, as Edd Dumbill pointed out among others.

The other problem is: the DBT-120 is an old Bluetooth 1.1 device that’s not produced anymore and by 2014 it is next to impossible to find a HID proxy-capable USB bluetooth adapter on the market. This forum post lists four, one of them being the Apple built-in BT module (which apparantly can be modded to be hooked up to an USB port) and one being the mentioned DBT-120 from 2003. The Belkin F8T016NG mentioned seems to be still available at Amazon UK and Amazon Germany despite being listed as being “made anymore”, whereas the fourth adapter, the Belkin F8T016CW, does not seem to be available in Germany at all.

From a hardware perspective, there is no reason for this situation. As this leaked CSR presentation on their BlueCore firmware points out, having HID proxy support is merely a question of enabling it in firmware builds. It doesn’t seem to be a question of firmware size either if only integrating RFCOMM support (which nobody seems to need) requires an 8 MBit flash chip and even the DBT-120 back then could be flashed to support both HID proxy and HCI.

The real reason is the lack of software support instead: as mentioned above, even with CSR-specific drivers Windows bluetooth stacks treat the adapter as an USB HID device and do not know that it can be told to reveal its real nature in form of the HCI interface.

CSR saw that problem and provided a sample Windows command-line application, hid2hci.exe, that does exactly the job (do not confuse it with the Linux executable hid2hci from the BlueZ project). It is a small executable of 44KB size and without any external dependencies. You can optionally tell it the USB vendor ID and product ID of the bluetooth adapter to be addressed, defaulting to a vendor ID of 0x0a12, which is CSR’s ID, and a product ID of 0x1000, which is the product ID a CSR USB bluetooth adapter uses when in HID proxy mode. After running this executable, the adapter will reappear on the USB bus with a different product ID and a HID interface, causing the normal Bluetooth driver stack to take over control. This change is not permanent, so the executable needs to be run after each OS boot and after each plugging out and in the USB bus, but, as a followup post will show, that can be nicely automated.

So to summarize, what it takes to get your Bluetooth input devices working in the BIOS as well is:

  1. a USB bluetooth adapter defaulting to HID proxy mode
  2. the hid2hci.exe tool
  3. some automation magic

As for the first problem, no matter what CSR-based bluetooth adapter you own, you’d need a HID proxy-enabled firmware. The way it looks like Apple’s update is the only one freely available on the Internet, but it’s for the old D-Link DBT-120 only. Maybe you can find one on eBay. As chance would have it, I still had one flying around and tried the update without having a Mac. This followup post has more on this topic.

As for the second problem, I do not know if and in what context CSR distributes hid2hci.exe if at all. This blog post by Stephan Joseph used to have an archive with it that was even referenced inside a book called “Take control of Windows running on a Mac” but you’ll have to look for yourself. Do not ask me to provide you with a copy.

As for the third problem, look out for a second followup post — I’ve done some cool PowerShell scripting ;)

Integrating Samba’s DNS server with existing dnsmasq installations

As an Active Directory encompasses not only LDAP and Kerberos but also DNS and there are funny things Microsoft does with DNS (dynamic updates, special SRV records to locate hosts etc.), running Samba as an Active Directory domain controller means running either the built-in DNS server or bind9 with a special DLZ plugin.

dnsmasq integration has been discussed but seems to have been abandoned not so much for technical reasons than rather for lack of real interest on both sides. There is at least this HOWTO that works around the technical issues by teaching dnsmasq the necessary SRV records manually, but even then you won’t have dynamic DNS updates the way Samba needs them and it is more of a hack definitely unsupported by the Samba team than a viable solution.

Running dnsmasq is feasible not so much as an alternative running on the Samba host itself, but, at least in my idea of SOHO networking, it’s pre-destined for embedded devices such as access points and routers and accordingly the default DNS forwarder in OpenWrt. Having DNS resolution depend on a “higher-level” DNS service provided by Samba would contradict that concept. Apart from the fact that Samba’s DNS server would require support for every single feature existing DNS servers (such as dnsmasq) already have — or bind be used, a software I do not really miss particularly much (think zone files).

Obviously I can’t achieve the desired isolation of a basic network service such as DNS and a productive service such as Samba with a single DNS zone, as there is no such thing as zone sharing. So I’ll need two DNS zones: and either or The latter choice would be preferable if we were to seriously use Active Directory features such as forests and sites but also mean that there would be a “parallel forest” of “conventional” DNS zones and the need to have a DNS server that supports delegations. As Samba 4 currently supports running a single Active Directory domain controller only anyway, I’ll go with the former:

DNS zone Managed by Running on dnsmasq OpenWrt-based access point/router Samba “Real” server

Now I do, of course, have only one DHCP service at my “site”. Technically it could supply multiple DNS servers but you wouldn’t want that since you can’t control your clients’ resolvers’ behavior via DHCP (ie. when which DNS server is tried). And there’s no need to, because here comes the elegant part: all clients continue to receive the IP address of an OpenWrt device as DNS server which is authoritative for Requests for * simply get delegated to the Samba host with a dnsmasq configuration such as the following:

# Local dnsmasq instance is responsible for

# DNS delegation for

# If rebind protection is on, this is
# required to avoid warnings on DNS
# rebinding attacks

# Upstream DNS server, handles everything
# outside and

Note that having two DNS zones does not imply that you need to have two IP subnets. It’s perfectly fine to have both and point at and have reverse lookup of the IP address resolve to, as long as you configure Kerberos client configuration accordingly (the rdns = false option described at the end of my sssd-ad configuration post).

This way, if the Samba server goes down, only the zone will be affected, not as a whole. Neat :)