RPi3 bluetooth for console?

[Duncan_Rowland]

I'd like to setup the RPi3's bluetooth so I can use it to connect to the console (e.g. from my laptop)
(I currently use usb-serial cables for this, but my students keep breaking them )
Thanks in advance for any pointers to achieving this,
-Duncan.

[Douglas6]

You can setup a Bluetooth serial port as a getty console, but I don't know of any Bluetooth serial programs for the laptop (what OS?). Or you can configure a Bluetooth Personal Area Network; that gets more difficult with IP addresses. Why not use WiFi?

[Duncan_Rowland]

>"You can setup a Bluetooth serial port as a getty console"
Yes, I think that's exactly what I'd like to do... do you have any pointers?
(I'm presuming this happens after boot, so I wouldn't be able to see boot messages)
>"Why not use WiFi?"
I'm just trying things out of curiosity

[Douglas6]

>Yes, I think that's exactly what I'd like to do

Start by adding the Serial Port Profile. Edit this file:

Code: Select all

sudo nano /etc/systemd/system/dbus-org.bluez.service

Add a ' -C' compataibility flag at the end off the ExecStart= line, and add a new line to add the SP profile. The two lines should look like this:

Code: Select all

ExecStart=/usr/lib/bluetooth/bluetoothd -C
ExecStartPost=/usr/bin/sdptool add SP

Save the file and reboot. Now enter this line in a terminal:

Code: Select all

sudo rfcomm watch hci0 1 getty rfcomm0 115200 vt100 -a pi

You should be able to connect with a Bluetooth serial terminal, and get a command prompt (auto-logged in as pi). If that works for you, we can automate the rfcomm command at boot.

[Duncan_Rowland]

Thanks Douglas, that's working great for me on a MacBook (El Capitan).
I included the further steps I used in case anyone else passes this way:

Make the RPi bluetooth device discoverable...

Code: Select all

$ bluetoothctl
[bluetooth]# discoverable on
[bluetooth]# quit

...and pair on the MacBook using the GUI.

This makes a couple of new devices on the mac:
/dev/cu.raspberrypi-SerialPort and /dev/tty.raspberrypi-SerialPort

Run the rfcomm process on the RPi...

Code: Select all

sudo rfcomm watch hci0 1 getty rfcomm0 115200 vt100 -a pi

...and connect to it using 'screen' (which causes the bluetooth link to connect).

Code: Select all

screen /dev/cu.raspberrypi-SerialPort 115200

Cheers, -Duncan.

[Douglas6]

Great. You can automate the rfcomm command with a service unit. Create a new file with sudo

Code: Select all

sudo nano /etc/systemd/system/rfcomm.service

and enter the following

Code: Select all

[Unit]
Description=RFCOMM service
After=bluetooth.service
Requires=bluetooth.service
 
[Service]
ExecStart=/usr/bin/rfcomm watch hci0 1 getty rfcomm0 115200 vt100 -a pi
 
[Install]
WantedBy=multi-user.target

Enable that to start at boot time with

Code: Select all

sudo systemctl enable rfcomm

Now either reboot or start it manually with

Code: Select all

sudo systemctl start rfcomm

[Duncan_Rowland]

Thanks again for the advice.
I've made a script to apply the changes to a fresh install (totally insecure):
https://github.com/DrRowland/RPi-Bluetooth-Console
Cheers, -Duncan.

FWIW, for my purposes it would be handy if this were a default install option... (save faffing about getting the IP).

[wei]

Thanks guys, your solution works for me, but there is a problem I found that the rfcomm service would keep hogging the CPU of about 35%.
Any solutions to this?

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
668 root 20 0 2036 452 384 S 34.4 0.1 0:34.79 rfcomm

[woodscooter]

Thanks guys, your solution works for me, but there is a problem I found that the rfcomm service would keep hogging the CPU of about 35%.
Any solutions to this?

Yes, I find the same thing, but it only hogs the CPU while a terminal is connected. After disconnect, everything is back to normal.

The issue is that Bluetooth running a terminal keeps the RPi processor very busy.

[chrislwood]

hogs the CPU while a terminal is connected

I encountered this as well (only when connected).

Code: Select all

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 2042 root      20   0    2036    452    384 S  33.3  0.1  21:19.97 rfcomm
 2415 root      20   0    5112   2424   2020 R   1.0  0.3   0:00.07 top
    1 root      20   0   22788   3908   2740 S   0.0  0.5   0:06.91 systemd

strace revealed rfcomm has too low a timeout to poll().

Code: Select all

ppoll([{fd=6, events=POLLERR|POLLHUP}], 1, {0, 200}, ~[HUP INT PIPE TERM CHLD RTMIN RT_1], 8) = 0 (Timeout)
wait4(-1, 0x7ebf245c, WNOHANG, NULL)    = 0
ppoll([{fd=6, events=POLLERR|POLLHUP}], 1, {0, 200}, ~[HUP INT PIPE TERM CHLD RTMIN RT_1], 8) = 0 (Timeout)
wait4(-1, 0x7ebf245c, WNOHANG, NULL)    = 0
ppoll([{fd=6, events=POLLERR|POLLHUP}], 1, {0, 200}, ~[HUP INT PIPE TERM CHLD RTMIN RT_1], 8) = 0 (Timeout)
wait4(-1, 0x7ebf245c, WNOHANG, NULL)    = 0
ppoll([{fd=6, events=POLLERR|POLLHUP}], 1, {0, 200}, ~[HUP INT PIPE TERM CHLD RTMIN RT_1], 8) = 0 (Timeout)
wait4(-1, 0x7ebf245c, WNOHANG, NULL)    = 0
ppoll([{fd=6, events=POLLERR|POLLHUP}], 1, {0, 200}, ~[HUP INT PIPE TERM CHLD RTMIN RT_1], 8) = 0 (Timeout)
wait4(-1, 0x7ebf245c, WNOHANG, NULL)    = 0

See the culprit in rfcomm.c source
http://code.metager.de/source/xref/linu ... comm.c#260

I pulled bluez source (same version that was installed on my RPI3/Raspbian, 5.23), changed the timeout to 200ms and rebuilt.

The result was:

Code: Select all

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
17981 pi        20   0    5276   2568   2092 R   1.0  0.3   0:00.35 top
 2015 pi        20   0   12000   3896   2868 S   0.3  0.5   0:03.24 sshd
13648 root      20   0       0      0      0 S   0.3  0.0   0:00.35 kworker/3:0
17798 root      20   0       0      0      0 S   0.3  0.0   0:00.13 kworker/u8+
17957 root      20   0    1860    348    292 S   0.3  0.0   0:00.02 rfcomm

There was no apparent negative effect (might be forced to wait a few milliseconds longer between disconnect and connect when using rfcomm watch).

This article helped me get started with BT on RPI3 so I figured I'd share what I found.

[gpolder]

anybody got this to work on debian stretch?

[gerb]

anybody got this to work on debian stretch?

I have, it works there too.
On the pi zero w:
Use bluetoothctl and give the command "discoverable on"

You need two systemd service files:

Code: Select all

~# cat /etc/systemd/system/multi-user.target.wants/rfcomm.service 

[Unit]
Description=RFCOMM service
After=bluetooth.service
Requires=bluetooth.service
 
[Service]
ExecStart=/usr/bin/rfcomm watch hci0 1 getty rfcomm0 115200 linux
 
[Install]
WantedBy=multi-user.target

Have this part in /lib/systemd/system/bluetooth.service:

Code: Select all

ExecStart=/usr/lib/bluetooth/bluetoothd -C 
ExecStartPost=/usr/bin/sdptool add SP 
ExecStartPost=/bin/hciconfig hci0 piscan 

Do a "systemctl daemon-reload" and (re)start the two services above. I think that should be it on the pi's side. On the client side, in one terminal:

rfcomm connect /dev/rfcomm0 <bluetooth mac address of the target>

in another terminal:

screen /dev/rfcomm0 115200

[AdrianTP]

First of all, thank you for this. I'm using a Pi Zero W as a cheap robot brain (no need for custom RF chips to connect controllers and to run remote diagnostics, because this has everything built-in!). This should enable me to remotely connect and run commands without having to connect via UART over USB or have the Pi paired to a WiFi hotspot. Very convenient.

I have an interesting problem, and I don't know where to begin looking for a solution since this is kind of a special case (shell over bluetooth) -- whenever I run a long-running command through this terminal connection (such as `ping google.com`) `^c` fails to stop it. The only way I could figure out how to stop it was by opening another connection and running `pkill ping`. Pretty sure this is not an issue with `screen`, seeing as I can connect to my Pi through the USB UART (which also uses `screen`) and cancel long-running commands without any problem.

I'm connecting to a (basically fresh) install of Stretch on a Pi Zero W from a paired Mac running 10.14.3 Mojave and "GNU bash, version 5.0.2(1)-release (x86_64-apple-darwin18.2.0)".

How do I troubleshoot this problem? Does anyone have any ideas on possible causes or solutions? Thanks!

UPDATE: I added the word "getty" to my search parameters and lo and behold I began finding useful information. I am currently experimenting with variations on this RPi StackExchange answer, in which the author specifically mentions having the same `^c` issue I observed. I will report back if I figure this out.

UPDATE: In the end my service file looks like this:

Code: Select all

[Unit]
Description=RFCOMM service
After=bluetooth.service
Requires=bluetooth.service

[Service]
# ExecStart=/usr/bin/rfcomm watch hci0 1 getty rfcomm0 115200 vt100 -a pi
# ExecStart=/usr/bin/rfcomm watch hci0 1 setsid /sbin/agetty -L rfcomm0 115200 vt100 -a pi
ExecStart=/usr/bin/rfcomm watch hci0 1 setsid /sbin/agetty -L rfcomm0 115200 vt100 -a pi

[Install]
WantedBy=multi-user.target

And I can use `^c` via the bluetooth console now!

[cxa205]

>Yes, I think that's exactly what I'd like to do

Start by adding the Serial Port Profile. Edit this file:

Code: Select all

sudo nano /etc/systemd/system/dbus-org.bluez.service

Add a ' -C' compataibility flag at the end off the ExecStart= line, and add a new line to add the SP profile. The two lines should look like this:

Code: Select all

ExecStart=/usr/lib/bluetooth/bluetoothd -C
ExecStartPost=/usr/bin/sdptool add SP

Save the file and reboot. Now enter this line in a terminal:

Code: Select all

sudo rfcomm watch hci0 1 getty rfcomm0 115200 vt100 -a pi

You should be able to connect with a Bluetooth serial terminal, and get a command prompt (auto-logged in as pi). If that works for you, we can automate the rfcomm command at boot.