Controlling Bluetooth DUN with Upstart
 

Hi all,

I spent some time today writing a suitable upstart script to control bluetooth DUN. This will let it start automatically and generally act seamlessly.

You can read the details and get the script from my blog post

Re: Controlling Bluetooth DUN with Upstart
 

Thank you for sharing!
I was searching for somethinig like this since long time!
I'll try it in the next week and will post the results. :)

Re: Controlling Bluetooth DUN with Upstart
 

Is there a way to package this into a .deb and push it into extras or otherwise make it simple for users to do? I'd hate that a cool thing like this that could benefit a lot of people and demonstrate the benefits of an open source platform ends up being exclusive to users who actually know what bluetooth DUN, upstart etc. are.

Re: Controlling Bluetooth DUN with Upstart
 

Great! I don't have the device yet but your script is going to be one of the first things I'll install. So, thanks :)

One thing I'd like to know - if there are any symbian experts around - is *if* and *how* a symbian phone can connect to the internet by tethering to another phone through bluetooth dun. This is because I am going to have my voice sim in a symbian phone and my data sim into the N900. Occasionally I'd like to use some symbian apps that go online, and the simplest way could be to tether. Any hint?

Re: Controlling Bluetooth DUN with Upstart
 

What happens if Bluetooth is disabled at startup and is enabled manually after that? I only want to enable Bluetooth when I need it and then it should be already possible to connect my notebook to the N900 and use the 3G connection from the N900.

Re: Controlling Bluetooth DUN with Upstart
 

So, when you disable bluetooth in the UI, the hardware is turned off but all the software keeps running, so that doesn't cause any issues.

Re: Controlling Bluetooth DUN with Upstart
 

Hi ... I tried to setup the upstart script as per your suggestion:
However the job doesn't seem to automatically start after rebooting the N900:
I need to start it manually via:
Do you have any idea?

Re: Controlling Bluetooth DUN with Upstart
 

Looks like I underspecified the starting constraints. It probably needs something that could start after bluetoothd. I'll have to investigate and find out what it is.

Re: Controlling Bluetooth DUN with Upstart
 

Has anybody got DUN connection working with Windows Vista?

Re: Controlling Bluetooth DUN with Upstart
 

I too had a problem with bluetooth-dun not starting after a clean boot.

I'm also going to document, for posterity, the steps I had to go through to get DUN running between a Gentoo Linux laptop and T-Mobile, using the N900 as the relay.

The N900 setup was more or less what you specified (specifically putting http://intr.overt.org/misc/bluetooth-dun into /etc/event.d and running `start bluetooth-dun`) except that I kept getting "spawning too fast" messages when testing.

For my laptop, I first had problems pairing--I'm sure this is some bug with the bluez version I was using, but I eventually gave up and put the line "34:7E:39:24:88:FC 9339" in /var/lib/bluetooth/*/pincodes where the "34:..." is the bluetooth address (from `hciconfig -a` on n900) and 9339 is the pin I wanted. A `rfcomm connect 0 34:7E:39:24:88:FC` then forced a pairing attempt and I was able to enter the pin 9339 on the n900. Also, the n900 was unable to see the laptop during discovery until I ran `hciconfig hci0 piscan` I don't think this was important to my efforts because the rfcomm explictly requested the pairing.

I have, more or less, the following contents of my /etc/bluetooth/hcid.conf:
------------------------------------
options {
autoinit yes;
security user;
pairing multi;
}
device {
name "BlueZ@%h (%d)";
class 0x3e0100;
iscan enable; pscan enable;
lm accept;
lp rswitch,hold,sniff,park;
}
------------------------------------

/etc/bluetooth/rfcomm.conf
------------------------------------
rfcomm0 {
bind yes;
device 34:7E:39:24:88:FC;
channel 1;
comment "N900 connection";
}
------------------------------------

/etc/conf.d/net
------------------------------------
config_ppp0=( "ppp" )
link_ppp0="/dev/rfcomm0"
username_ppp0='guest'
password_ppp0='guest'
pppd_ppp0=(
"debug"
"ipcp-accept-remote"
"ipcp-accept-local"
"holdoff 3"
"defaultroute"
"usepeerdns"
"noauth"
"noipdefault noaccomp noccp nobsdcomp nodeflate nopcomp novj novjccomp local"
"921600"
"modem crtscts"
)
phone_number_ppp0=( "*99#" )
chat_ppp0=(
'ABORT' 'BUSY'
'ABORT' 'ERROR'
'ABORT' 'NO ANSWER'
'ABORT' 'NO CARRIER'
'ABORT' 'NO DIALTONE'
'ABORT' 'Invalid Login'
'ABORT' 'Login incorrect'
'TIMEOUT' '5'
'' 'ATZ'
'OK' 'ATM0'
'OK' 'ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0'
'OK' 'AT+CGDCONT=1,"IP","internet2.voicestream.com"'
'OK' 'ATDT\T'
'TIMEOUT' '60'
'CONNECT' ''
'TIMEOUT' '5'
'~--' ''
)

preup() {
case "${IFACE}" in
ppp*) modprobe ppp_generic; modprobe ppp_async;;
esac
return 0
}
postdown() {
case "${IFACE}" in
ppp*) rmmod ppp_async; rmmod ppp_generic;;
esac
return 0
}

------------------------------------

Note my use of internet2.voicestream.com and the username/password of guest/guest. One of those two changes (from internet3.voicestream.com and no username/password) was what I had to do to get DUN working over and above what has been documented here to date.