\ndescription \"DUN over Bluetooth\"
\nauthor \"Philip Langdale\"<\/p>\nrespawn
\nconsole none<\/p>\n
start on started bluetoothd
\nstop on stopping bluetoothd<\/p>\n
pre-start script
\n sdptool add --channel 1 DUN
\nend script<\/p>\n
exec rfcomm -S -- listen -1 1 \/usr\/bin\/pnatd '{}'<\/p>\n
post-stop script
\n sdptool del `sdptool browse local | grep Dial-Up -A 1 -m 1 | tail -n 1 | cut -d ' ' -f 3`
\n sleep 1
\nend script
\n<\/code><\/p><\/blockquote>\n
So, what is this doing? As upstart is pretty new, and quite different from old style init-scripts, it’s worth explaining a bit.<\/p>\n
The description<\/i> and author<\/i> fields are just for documentation. respawn<\/i> means to restart if the main process exits. console none<\/i> means don’t log stdout or stderr anywhere. <\/p>\n
Now, the start on<\/i> and stop on<\/i> 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.<\/p>\n
With that done, we can move on to the functional code. From the wiki page, we see that the invocation of rfcomm<\/i> is the key call. What happens here is rfcomm will wait for an incoming connectio request on channel 1 and then spawn pnatd<\/i> and connect it to that channel. When the connection is complete, pnatd<\/i> will exit and then rfcomm<\/i> will too. Upstart either tracks a particular binary or a script. In either case, it exec<\/i>s the binary or script and watches the resulting process to see when it exits. So, we can conveniently transfer the rfcomm<\/i> command line to an upstart exec<\/i> directive.<\/p>\n
However, there’s more to do. We have to register the service with sdpd<\/i> 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<\/i> and post-stop<\/i> blocks. This also gives us a place to enforce the one second delay suggested by the example script.<\/p>\n
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.<\/p>\n
Now, all you have to do is drop the script into \/etc\/event.d\/<\/code> and then execute start bluetooth-dun<\/code>, assuming you name the script “bluetooth-dun”. Obviously, you must be root for both these steps.<\/p>\nYou can download the script from here<\/a>. I’ll probably package it up as a deb in due course, but I don’t have a working scratchbox environment right now.<\/p>\nEnjoy!<\/p>\n
Update:<\/strong> 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.<\/p>\n","protected":false},"excerpt":{"rendered":"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 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[],"class_list":["post-74","post","type-post","status-publish","format-standard","hentry","category-maemo"],"_links":{"self":[{"href":"https:\/\/blog.intr.overt.org\/index.php?rest_route=\/wp\/v2\/posts\/74"}],"collection":[{"href":"https:\/\/blog.intr.overt.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.intr.overt.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.intr.overt.org\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.intr.overt.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=74"}],"version-history":[{"count":0,"href":"https:\/\/blog.intr.overt.org\/index.php?rest_route=\/wp\/v2\/posts\/74\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.intr.overt.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=74"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.intr.overt.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=74"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.intr.overt.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=74"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}