While playing with my Raspberry PI, I looked at different networking options available – Ethernet is great, if your house is already cabled, Wi-Fi is great if it isn’t (but on the other hand, not all adapters work reliably and they pull a lot of power, and generate a bit of heat).
How great would it be if you could simply attach a bluetooth adapter and be able to pull up a serial console? Turns out it’s pretty easy to do.
Step one - get a bluetooth dongle and plug it in
I’ve picked up a cheapo module for $1.95 a piece. They are all mostly the same thing.
Step two - install bluez for Linux and configure your adapter
Packages are readily available for nearly all distributions.
$ sudo apt-get install bluez
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
bluez
0 upgraded, 1 newly installed, 0 to remove and 107 not upgraded.
Need to get 0 B/895 kB of archives.
After this operation, 2075 kB of additional disk space will be used.
Selecting previously unselected package bluez.
(Reading database ... 73325 files and directories currently installed.)
Unpacking bluez (from .../bluez_4.99-2_armhf.deb) ...
Processing triggers for man-db ...
Setting up bluez (4.99-2) ...
Reloading system message bus config...done.
Starting bluetooth: bluetoothd rfcomm.
Your bluetooth device should be up and running now. To verify that the adapter was recognized by the kernel and is operational, do the following:
$ hciconfig
hci0: Type: BR/EDR Bus: USB
BD Address: 00:11:67:00:00:00 ACL MTU: 510:8 SCO MTU: 48:10
UP RUNNING PSCAN
RX bytes:27177 acl:504 sco:0 events:1654 errors:0
TX bytes:56051 acl:1309 sco:0 commands:194 errors:0
Now, let’s make it discoverable and pair it with our device. First, we’ll need to tell the adapter to put itself in discoverable mode, then we need to fire up the agent, which will respond to pairing requests. Your device should become visible, and should be paired with one click of a button.
$ sudo hciconfig hci0 piscan
$ sudo bluetooth-agent 1234
Confirmation request of 577270 for device /org/bluez/2055/hci0/dev_00_26_B0_F1_99_97
Once we’re done with this step, we can hit Ctrl-C and not worry about bluetooth-agent until we want to pair the next device.
Step three - configure the serial port emulation service and attach getty to it
We’ll be communicating over the RFCOMM protocol, which provides roughly the same functionality as TCP, and just like TCP uses ports as virtual channels, except in this case, there are only 30 of them. Because the remote device doesn’t know anything about what port (channel) we’ve decided to bind the serial port service to, we’ll need to let them know.
$ sdptool add --channel=3 SP
Serial Port service registered
$ sdptool browse local
(...)
Service Name: Serial Port
Service Description: COM Port
Service Provider: BlueZ
Service RecHandle: 0x10006
Service Class ID List:
"Serial Port" (0x1101)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 3
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"Serial Port" (0x1101)
Version: 0x0100
Now, for the slightly trickier bit. We’ll need to bind channel 3 to whatever service we wish to run on it. In our case, we want to run getty which in turn lets us log in and interact with our Raspberry Pi.
$ sudo rfcomm watch /dev/rfcomm0 3 /sbin/agetty rfcomm0 linux 115200
Waiting for connection on channel 3
This will make the adapter listen for incoming connections on channel 3, and once a connection is accepted - a new getty session will be launched on the device rfcomm0, permitting us to log in via a terminal program running on the connected client.
When a connection is made, you should see the following:
$ sudo rfcomm watch /dev/rfcomm0 3 /sbin/agetty rfcomm0 linux 115200
Waiting for connection on channel 3
Connection from 00:26:B0:F6:90:97 to /dev/rfcomm0
Press CTRL-C for hangup
Caveats
Sadly, this approach is not without shortcomings. For starters, you’ll notice that your rfcomm connection is hogging the CPU:
I’ve been able to trace this to repeated calls to ppoll(), but have not dug any further yet.
