The Netbook Newbie's Guide to Linux

Original URL: https://www.theregister.com/2009/04/13/netbook_linux_guide_5/

Back to the Bluez

Posted in OSes, 13th April 2009 08:02 GMT

Episode 5 I opened up my Acer Aspire One again after a prolonged interval while I was involved in a very different project and was puzzled to discover that Live Update was offering me a "Bluetooth patch". It's not just that the hardware doesn't have Bluetooth - that's easily fixed by plugging in a dongle - but even if you do plug in a dongle, the operating system remains blissfully ignorant of it. I assumed this was because there's no Bluetooth support in the kernel supplied with the AA1's version of Linpus.

I decided to install the update anyway - with some reservations: see Is it Evil. The standard Linux Bluetooth software suite is Bluez, and presumably the Acer offering was based on this, so with hope rising in my heart I plugged in my subminiature Bluetooth dongle. You can pick these little fellers up in Maplins for around £20, but my preference was for an eBay purchase, which cost me all of £3.40 - including delivery!

When these things are conferring happily with the operating system a tiny blue light flashes in the depth of their being. The light can be faint, and you might need to cup your hands over the device to see it, but it's there. I cupped and peered. Alas, there was no blue light. Damn.

This could mean one of two things: either I was right about there being no Bluetooth kernel support, or the device itself was for some reason inherently unrecognisable by Acer's Linpus - although I knew it worked OK with Windows. A simple command line utility solved that dilemma straight away: lsusb.

My lsusb output

...and there it is, the little darling. British, too. A device that the lsusb 'list USB' utility could find, but the kernel didn't know how to use.

Clearly, what was missing were the relevant kernel modules - but see What's Really Missing. I can understand why Acer might omit Bluetooth hardware, and therefore core Bluetooth software from the machine, but to issue a "Bluetooth patch" that adds the tools without the core kernel modules seems totally daft.

I queried Acer UK marketing about this, and I'm still waiting for them to get back to me.

Meanwhile, we can fix the problem ourselves, thanks to a generous contribution from a discussion group contributor called linker3000 in the Aspire One User Group.

Download linker3000's two files, bluetooth.tgz and bluetooth2.tgz and move them, as he suggests, to the /lib/modules/2.6.23.9lw/kernel/drivers and /lib/modules/2.6.23.9lw/kernel/drivers/net directories. It's easiest to do this as root from the command line:

sudo mv <filename> <target directory>

Then you'll need to unpack them.

These are gzipped .tar files. tar is a longstanding Unix tool for bundling up directory hierarchies into a single file. gzip is the GNU equivalent of the familiar Zip compression tool. Double-clicking files like these while in the GUI obligingly unwraps them automatically, but as we're already down at the command line, let's 'get back to the blues' and do this manually. First the unzipping:

gunzip bluetooth2.tgz

This deletes the .tgz file and replaces it with the expanded .tar file. Now the next stage:

tar -xvf bluetooth2.tar

...where x stands for 'eXtract', v means 'be verbose' - ie. show me the result - and f introduces the name of the file to be untarred (see More Fun with Tar).

Now do the same for the bluetooth.tgz file in the ../drivers/net directory.

More Fun with Tar

Old Unix hands would do this in one line, using a 'pipe', like this:

gunzip < bluetooth2.tgz | tar -xvf -

...and GNU's own version of tar, gtar, even allows you to do this in one fell swoop:

gtar xvzf bluetooth2.tgz

With the kernel modules in place, we're still not quite ready to rock and roll. First, we'll have to ensure that the new modules are added to the system module inventory, a text file called modules.dep. This list makes sure that any module that requires the presence of other modules to work properly gets everything it needs at load time.

Yast's Advanced Daemon Configuration shows that the MSI Wind comes with Bluetooth software capability already installed

Managing this string of dependencies is a complex business, but happily you don't have to edit modules.dep manually - just run a tool dedicated to this task:

depmod

...to update modules.dep automatically. And now we're ready to load our new modules into the kernel and get Bluetooth running. The official Acer patch has already installed the script to do this in /etc/init.d, among all the other boot-time scripts. So we just run:

/etc/init.d/bluetooth start

...and if all's well the blue light on the dongle should start flashing. Bluetooth is working.

Now is probably the time to reboot, to make sure the Bluetooth init script is doing its job properly - loading the relevant modules and installing a Bluetooth symbol among the other notification icons down at the bottom right of the screen:

When you scan from your phone for Bluetooth devices, you should see a new one with a name like localhost-0. Right clicking on the AA1's new Bluetooth notification icon brings up a dialogue that allows you to change this to something more informative.

MSI Wind owners don't have to do any of this - Bluez is already installed and ready to run, even if there's no on-board Bluetooth hardware.

Asus Eee PC users may be less lucky with Bluetooth. The very full instructions on the Eee PC User Group web page point out that "the Eee install of Linux comes with Bluetooth support enabled, but there is no way to configure or use it from the graphical interface. The command-line must be used".

Readers of previous episodes here shouldn't have much of a problem with that. But the User Group guidelines go on to add, fatefully: "However, this is trivial."

'Trivial' in the special sense of 'not possible', that is - at least if my experience is anything to go by. Although Linux seems recognise the Bluetooth dongle as powered up, I simply couldn't get its LED to flash at all.

A quick chat with Phil Simes on Cambridge Silicon Radio's support desk confirmed that the problem might be that the Asus machine was delivering marginally less power than the dongle was expecting. As the latest generation of Eee PCs are already Bluetooth enabled there didn't seem much point in pursuing this.

Has anyone else got this working? If you have, please let me know how, by posting a comment or emailing me using the byline link above.

What's Really Missing

In the very early days of Unix, features like Bluetooth capability - not that such a thing existed then - would be compiled into the kernel, but for over a decade now the practice has been to create them as separate modules, optionally loadable either by user intervention or - more commonly - automatically on demand. Plug in your Bluetooth USB dongle: the operating system recognises it and loads the relevant modules. All modern operating systems work like this.

But unlike Windows, or Mac OS X, the kernel at the heart of the Linux operating system - or, strictly speaking, the Linux at the core of the GNU/Linux system - has been evolving very fast. So although a Mac OS X "kernel extension" (a .kext) created five years ago might be expected to work with the current Mac OS X, a kernel module compiled to run with some random version of Linux probably won't work with the 2.6.23.9lw kernel at the heart of the AA1's Linpus.

This has always been true of Linux/Unix, and although it sounds like a headache, it's actually part of the great strength of an operating system that runs across a huge range of different hardware. It works because kernel modules are traditionally distributed as source code, something made possible by the fact that every full version of Linux is also a development system, with its own set of compilers, linkers and all the other paraphernalia necessary to crunch source code into binary executables.

Every version of Linux - except, that is, for the pre-cooked, locked-down Linuxes turning up on today's netbooks. In the case of the AA1, I see that it may not be as grim as that. The Package Manager - which you can get to if you followed the instructions for attaining the AA1's "advanced mode" in Episode 3 - promises a set of Development Tools and Libraries, which should bring Linpus up to full spec. I haven't installed any of this because the spirit of this series is not to get too hairy.

Acer's Bluetooth Patch: is it Evil?

The official Acer 'Bluetooth Patch' presents itself as a script file. The abiding Unix advantage of doing a lot of stuff using plain text shell scripts is that they're transparent - you can read 'em to find out what they think they're doing. All the scripts in /etc/init.d that start up the various Linux services, for example, work along these lines. But not this 'Bluetooth Patch' script.

Some of it is readable. The opening comment line says that it's been constructed with a utility called Makeself. Makeself is a utility devised by Stéphane Peter that makes .tgz files self-extractable. The .tgz files are embedded in the Makeself scripts, so although they run like scripts, they're mostly full of binary code that completely conceals their actions.

At least that's how it seemed. I dropped an email to Stéphane suggesting that short of setting up a VMware Linpus sandbox, running the script and then walking through the whole system with find, I couldn't think of any way of determining the workings of this kind of script that can create executables or other scripts at will, and then run them. So, is Makeself evil? I asked him.

No, he says. No less so than any other installer. He explained that you can quiz a Makeself file from the command line about its contents:

[user@localhost bluetooth.sh]$ ./bluetooth.sh --info
Identification: install bluetooth patch
Target directory: bluetooth
Uncompressed size: 9768 KB
Compression: gzip
Date of packaging: Sat Oct 11 14:37:37 CST 2008
Built with Makeself version 2.1.4 on linux-gnu
Build command was: /usr/bin/makeself.sh \
    "bluetooth" \
    "bluetooth.sh" \
    "install bluetooth patch" \
    "./install.sh"
Script run after extraction:
     ./install.sh
bluetooth will be removed after extraction

Stephane goes on to say: "To examine the contents of the archive itself, and thus get a better idea of what happens, you can use the --noexec and --target options to simply extract the files, ie.

sh makeself.run --noexec --target /tmp/archive

You can then just peruse the contents of /tmp/archive in this example."