Wubble

The Bluetooth DUN package has been well received, but was hardly a profound programming endeavour. So, I’ve been trying to find suitable inspiration for a more substantial project. This morning, someone made a comment on the Bluetooth DUN page that there’s no way to tell if the phone has a tethered data connection or not – and he’s right: there’s no visual feedback on the phone, unlike Nokia’s Symbian devices or, I imagine, many other phones in the world. With that as a motivation, I decided to try and write a status indicator for tethering.

My first decision was language, and I went with Python as I’ve wanted to use it more and I know how laborious it would be to write this kind of utility in C. I then had to dig around to find out how to write a status area plugin in Python, and luckily there is a way, and it’sfairly well documented.
The biggest source of confusion is that the get_dbus_connection method isn’t exposed in the Python bindings. So, after that took *way* too much time to work out, I had to try and achieve the same thing with direct DBus calls (get a private connection that doesn’t kill the app if it dies), which I reckon I’ve got right.

Once you’ve got the basic stuff sorted out, it becomes really easy to iterate and test – you replace the python file and move .desktop file in and out of a specific directory and Hildon will reload it. Debugging was a real pain because the phone components that I’m talking too don’t exist inside the scratchbox dev environment – so I had to play a trial and error game on the N900 itself, where my only feedback was the icon failing to appear – what fun.

The next challenge was investigating what DBus interfaces to use to find the necessary information. The most important one is com.nokia.csd.GPRS. It’s not documented anywhere, but it’s fortunately introspectable and has obviously named methods and signals, so I was able to establish when a connection is made, suspended or disconnected.

Unfortunately, you see the same set of signals whether the connection is made by the phone itself or a tethered client, so then I had to find a way to detect if the phone was using the connection. I eventually found a way by using com.nokia.icd and com.nokia.icd2 – the first is undocumented and unintrospectable while the second is actually documented. For com.nokia.icd, I was able to use dbus-monitor to find a useful status signal and the get_ipinfo() method I needed had been explored by others. So, now I can avoid false positives from phone initiated connections.

There is one problem that remains, however: It’s possible to tether through the phone at the same time that the phone is using the connection for itself – this is apparently not as amazing as it sounds; all my old phones could do it. In this case, there appears to be no way to notice the tethered connection, so the monitor will not report it. At the moment, I’ve got no good ideas for doing this cleanly – I might be able to poke sysfs or look for pnatd processes, but neither is particularly attractive. But it’s not that common a case, so I consider the program useful before this gets solved.

And what does the program actually do? It shows an icon in the status area that reflects the connection state: disabled, attached, or suspended. I actually think that showing an icon when there’s no connection is a bad use of real eastate, so I’m going to take that out of the next release, but it’s there for now and helpful for confirming that the plugin actually started.

If you’re interested, you can grab it from extras-devel.

Enjoy!

Over the last couple of weeks, I’ve been working on packaging up my bluetooth dun script for easy consumption. It’s been through a few iterations and is now in the ‘extras-testing’ repository and should be ready to go into the main ‘extras’ repository once it has enough testing feedback.

The extras-testing repository is not intended for un-adventurous users, but if you’re interested in getting my package, it’s the place to go to. In the latest version, it will correct start the service when you install the package, and shut it down when you remove it. The actual upstart script hasn’t needed to change since I fixed the dependency issue.

And on an unrelated note, there’s now a way to reliably trigger the portrait mode ‘hack’ – if you want to try out portrait mode browsing, etc. You can find that here.

Wow, it’s been a long time since I posted anything. But I’ve got something worth coming out of hibernation for.

Perhaps, unsurprisingly, I got myself an n900 and it’s a great device; I’m using it as my primary phone and it really is impressive.

One thing that doesn’t work out of the box is DUN (Dial-Up Networking) over Bluetooth. DUN is one of the simplest ways to tether a computer to a phone, so it’s a useful feature to have. (The n900 does support DUN over USB by default). Fortunately, it’s very easy to turn on, as documented on the maemo wiki. However, if you want the feature to always be ready to go (say, after you restart your phone), you need to do a little more.

Like modern versions of Ubuntu, the n900 with Maemo 5 uses upstart to control most startup services, such as bluetooth. So, if we want the DUN service to be nicely coordinated, we should start it with upstart too. Here’s my script:


description "DUN over Bluetooth"
author "Philip Langdale"

respawn
console none

start on started bluetoothd
stop on stopping bluetoothd

pre-start script
sdptool add --channel 1 DUN
end script

exec rfcomm -S -- listen -1 1 /usr/bin/pnatd '{}'

post-stop script
sdptool del `sdptool browse local | grep Dial-Up -A 1 -m 1 | tail -n 1 | cut -d ' ' -f 3`
sleep 1
end script


So, what is this doing? As upstart is pretty new, and quite different from old style init-scripts, it’s worth explaining a bit.

The description and author fields are just for documentation. respawn means to restart if the main process exits. console none means don’t log stdout or stderr anywhere.

Now, the start on and stop on directives are the heart of Upstart. They allow you to express dependencies between services, events, and each other. In this case, we want to start the DUN server after bluetoothd is started and stop it as soon as we start stopping bluetoothd. You can express multiple start and stop conditions and the upstart site documents these.

With that done, we can move on to the functional code. From the wiki page, we see that the invocation of rfcomm is the key call. What happens here is rfcomm will wait for an incoming connectio request on channel 1 and then spawn pnatd and connect it to that channel. When the connection is complete, pnatd will exit and then rfcomm will too. Upstart either tracks a particular binary or a script. In either case, it execs the binary or script and watches the resulting process to see when it exits. So, we can conveniently transfer the rfcomm command line to an upstart exec directive.

However, there’s more to do. We have to register the service with sdpd so that clients know we offer DUN, and we have to unregister when the service is terminated. This can be done with the pre-start and post-stop blocks. This also gives us a place to enforce the one second delay suggested by the example script.

Registering the service is easy, but unregistering it is a bit of a chore. The example script can avoid it because it uses the while loop, but for upstart, the entire service is ‘inside’ the loop, so we must unregister to avoid adding an extra registration each time. The problem arises because you can only unregister by the service record ID which is selected at registration time, but not provided back to us. So, we must look for it ourselves. The long command line searches the list of services for DUN and then extracts the ID.

Now, all you have to do is drop the script into /etc/event.d/ and then execute start bluetooth-dun, assuming you name the script “bluetooth-dun”. Obviously, you must be root for both these steps.

You can download the script from here. I’ll probably package it up as a deb in due course, but I don’t have a working scratchbox environment right now.

Enjoy!

Update: It seems that it’s not perfect yet. I’ve had a report, and reproduced, it failing to start when the phone boots, even though it starts reliably if you stop/start bluetoothd. My suspicion is that there’s an additional dependency (maybe the rfcomm kernel module) that needs to be accounted for. I will investigate.