First setup dependancies
sudo apt-get install bluez
Then ensure your pi is discoverable:
sudo hciconfig hci0 piscan
Now append the following to /etc/inittab (using nano - and substituting for your own):
#Bluetooth Channel 22
BS22:23:once:/usr/bin/sdptool add --channel=22 SP
BT22:23:once:/usr/bin/rfcomm -r watch 0 22 /sbin/agetty -L rfcomm0 115200
Now reboot. Your other device should be able to discover and pair for a serial device. Connect to that serial at 115200, and you will have a login shell!
Long explanation (after a short while of learning all this stuff):
I spent a little time understanding the bluetooth stack for linux - Bluez, and bluetooth in general. SPP is the serial port protocol - bluetooth emulation of a serial port. rfcomm is a layer below this - packet protocol for bluetooth. sdp is the service discovery protocol - advertising services. I read some of the bluez code, examples, and even some of the history of why it is how it is now.
The next part I played with on an ubuntu machine - where I had a detour killing modem-manager as it was outputting AT sequences to my new serial port - I had to hide the binary to stop it respawning as upstart tinkering was not stopping it. However, this revealed a clue - a critical one. All these bits somewhere assume that a serial port will attach to a modem - clearly not the case.
I then read agetty's man page, and it does assume a modem, and waits for carrier detect. The '-L' option sets it to be local - and will not try that.
Channel 22 - common sdp channel for spp. Beware - other channels may be in use for other protocols.
Knowing that piscan makes your device discoverable was also important - and I may need more testing to be clear if this is needed on every cold boot..
Then putting this in inittab so it will be available upon boot and using bluetooth-agent to accept pairing requests with the right pin.
The shell has no job control - I may need to understand more about bashes "jobs.c" file to get to why not. It can't be just some trust thing as this shell can sudo.
If you hang the shell and hang up (close your putty session), you will have to reboot or ssh into the pi - the /dev/rfcomm0 device will still be in use. If you can ssh in, you can lsof to find the rogue bits and kill them.
What I want next?
- Obex file browsing too. Obex + Serial give a pretty nice programming/debugging aide when using the Pi without the keyboard mouse - when all I have is the laptop, pi and bluetooth dongle.
- PAN networking - looks tricker to set up, but since it provides an IP layer may ultimately be more solid than the serial port - without the issues above. SSH + tunneled X too for UI interactions?