Bluetooth tethering with a 2021 Debian

The bluetooth part

The basic operation for bluetooth tethering is straightforward: Open a serial-like connection (“rfcomm”) to the phone, then start a pppd on top of it. It's the little details that make this tricky.

The first detail for me is that I have a deep distrust of bluez (and even the bluetooth drivers). I hence keep bluetooth off and blocked most of the time, and before opening any bluetooth connection, I have to manage this bluetooth state, which I'm going to do in a plain shell script. I'm sure there's a very elegant way to do this in systemd, but then I'd say this is a case where the clarity of a shell script is hard to beat.

So, I created a file /usr/local/sbin/bluenet containing this:

#!/bin/sh
# Configure/deconfigure an rfcomm bluetooth connection

DEVICE_MAC=<YOUR PHONE'S BLUETOOTH ID>

case $1 in
  start)
    /usr/sbin/rfkill unblock bluetooth
    /sbin/modprobe btusb
    /usr/sbin/service bluetooth start
    /usr/bin/rfcomm bind /dev/rfcomm0  $DEVICE_MAC
    sleep 2 # no idea what I should really be waiting for here, but
      # bluetooth clearly needs some time to shake out
    ;;
  stop)
    /usr/bin/rfcomm release /dev/rfcomm0
    /usr/sbin/service bluetooth stop
    /sbin/rmmod btusb
    /usr/sbin/rfkill block bluetooth
    ;;
  default)
    echo "$1 start|stop"
    exit 1
esac

All that you really need if you don't mind having bluetooth on are the two rfcomm command lines; the advantage of having this in a separate script (rather than just hack the rfcomm calls into the ifupdown stanza) is that you can say bluenet stop after a failed connection attempt and don't have to remember what exactly you started and what the stupid rfcomm command line was. Oh: Resist the temptation to keep this script in your home directory; it will be executed as root by ifupdown and should not be writable by your normal user.

To figure out your phone's bluetooth id, I think what people generally use these days is bluetoothctl (and for interactive use, it's fairly nice, if scantily documented). Essentially, you say scan on in there and wait until you see something looking like your phone (you'll have to temporarily make it discoverable for that, of course). While you're in there, run pair <mac>, too – at least for me, that was really straightforward compared to the hoops you had to jump through to pair bluetooth devices in Linux in the mid-2000s.

With this, you should be able to say:

sudo /usr/local/sbin/bluenet start

and then talk to a modem on /dev/rfcomm0. Try it with a terminal program:

minicom -D /dev/rfcomm0

In minicom, type AT and return, and try again if it doesn't work on the first attempt[1]; the phone should respond with OK. If it does, you're essentially in business. If it doesn't, try rfcomm -a – which should show something like:

rfcomm0: DE:VI:CE:MA:CA:DD:RE channel 1 clean

Oh, and bluetootctl may be your (slightly twisted) friend; in particular info <mac> has helped me figure out problems. I still don't understand why my N900 doesn't show the rfcomm capability in there, though – again, I'm not nearly enough of a bluetooth buff to tell if that's normal in any way.

The PPP part

Assuming, on the other hand, you have your rfcomm connection, the rest is standard pppd fare (which, of course, makes me feel young again). This means you have to give a provider-specific pppd configuration, conventionally in /etc/ppp/peers/bluez (replace bluez with whatever you like), which for me looks like this:

/dev/rfcomm0
115200
debug
noauth
usepeerdns
receive-all
ipcp-accept-remote
ipcp-accept-local
local
nocrtscts
defaultroute
noipdefault
noipv6
connect "/usr/sbin/chat -v -f /etc/ppp/chat-bluez"

lcp-echo-interval 300
lcp-echo-failure 10

Some of this is a good idea whenever there's not actually a serial port in the game (local, noctsrts), some may break your setup (noauth, though I think that's fairly normal today), and the lcp-echo things I found useful to detect lost connections, which of course are rather common on cellular data. Oh, and then there's the noipv6 that you may object to.

Anyway: you may need to gently adapt your pppd peers file. Use your common sense and browse the pppd man page if you can't help it.

The chat script /etc/ppp/chat-bluez mentioned in the peers file for me (who's using a German E-Netz reseller) looks like this:

TIMEOUT 5
ECHO ON
ABORT 'ERROR'
ABORT 'NO ANSWER'
ABORT 'NO CARRIER'
ABORT 'NO DIALTONE'
'' "ATZ"
OK-ATZ-OK ATE1
OK 'AT+CGDCONT=1,"IP","internet.eplus.de","0.0.0.0"'
TIMEOUT 15
OK "ATD*99***1#"
CONNECT ""

Essentially I'm doing a modem reset (ATZ), and (to accomodate for the swallowed initial characters mentioned above) I'm trying again if the first attempt failed. The ATE1 enables echo mode to help debugging, and then comes the magic in the CGDCONT (“Define packet data protocol (PDP) context”) AT command – you will have to adapt at least the string internet.eplus.de to your provider's APN (there are public lists of those). The rest you can probably keep as-is; nobody really uses more than one profile (the 1) or a PDP type other than IP (well, there IPV4V6 that might interest you if you've removed the noipv6 statement above), or uses the PDP address in the last argument.

The final dial command (the ATD) is, I think, fairly standard (it says, essentially: Call the PDP context 1 set up in CGDCONT).

All this assumes your provider does not require authentication; I think most don't these days. If they do, say hello to /etc/ppp/pap-secrets and the pppd manpage (you have my sympathy).

Finally, the various components are assembled in a stanza in /etc/network/interfaces:

iface n900 inet ppp
  pre-up /usr/local/sbin/bluenet start
  provider bluez
  post-down /usr/local/sbin/bluenet stop

That's it – your tethered network should now come up with ifup n900, and you can take it down with ifdown n900. If the thing gets stuck, meaning the interface won't come up as far as Debian is concerned, the post-down action will not be run. Just run bluenet stop manually in that case.

Amazing endurance

One thing blew my mind when I did this: A good decade ago, the Nokia N900 didn't come with the profile rfcomm uses enabled (it's called “DUN” there; don't ask me why). It didn't need much to enable it, but you needed to drop some magic file for the upstart init system running in the N900's maemo into some strategic location, and some kind soul had packaged that up. Not expecting much I simply ran apt-get install bluetooth-dun – and it just worked. Whoever still keeps up these ancient maemo repositories: Thanks a lot, and I'm impressed. If we ever meet, remind be to buy you a $BEVERAGE.

[1]	In the communication with the N900 with its ancient bluetooth stack, for some reason the first character(s) tend to get swallowed somewhere on the way. I've not tried to ascertain who is to blame; perhaps it's the autoconnection of rfcomm?