How can a USB Bluetooth Dongle be used as login TTY

Question

I would like to be able to use a Bluetooth Dongle - not the HC06 module, but a simple USB dongle (the pretty generic kind, or even poundshop type) as a serial login console/tty.

I have already tried the following: hcitools and bluez are installed. lsusb shows the device, hcitools dev shows it, and hcitools scan shows other devices.

I've used bluez-simple-agent to pair it with a laptop, and then attempted to use rfcomm bind to a channel, getting a /dev/rfcomm1 device.

I have attempted to advertise the channel with sdptool add --channel=1 SP.

I have used rfcomm watch /dev/rfcomm1 1 echo hello to test it (as well as a more complicated variation with getty), and cannot get the hello. It is listening, and with it there, the laptop (windows) does think there is a serial device, but I cannot then use putty to connect to a comm port created, and get a thing out of it.

This sounds possible - has somebody done this, and could they point me at the right changes to make?

This is similar - but as a serial client Bluetooth as ttyUSB*.

Answer 1

Short answer:

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
PA22:23:respawn:/usr/bin/bluetooth-agent <passkey>
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.

---

Problems remaining

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?

Answer 2

I've poured over the internet for some hours to try and answer this very question. I've successfully setup the serial connection via Bluetooth from a PI Zero W and my desktop. I was troubled by the same job control issues while using putty to access my PI. With some more research I found that adding setsid solves the job control issue and my inability to send ctrl - c.

I'm using systemd service

/etc/systemd/system/rfcomm.service

[Unit]
Description=Terminal on Bluetooth Serial

[Service]
ExecStart=/usr/bin/rfcomm watch rfcomm1 1 setsid /sbin/agetty -L rfcomm1 9600 linux

[Install]
WantedBy=multi-user.target

CLI would look like

sudo rfcomm watch rfcomm1 1 setsid /sbin/agetty -L rfcomm1 9600 linux

Adjust you device parameters appropriately. Hope this helps someone in the future.

Joe-