Expose BLE via Socket

[RoySalisbury]

This is great that I can now access the BLE communications via a standard serial port connection. I'm using this on a Pi that talks to multiple BMS devices.

What would be nice is if it could also be exposed via a standard TCP/IP socket connection. Then I could setup a single Pi Zero that is connected to the network exposing all my BMS connections, and then form a central application I could just open up a socket to the correct port and read/write to it.

[Jakeler]

This is possible with socat, I am actually using it for testing.
So on your RPi first launch ble-serial, then listen for TCP connections:

socat -dd open:/tmp/ttyBLE tcp-l:4001

• -dd just to increase the log verbosity
• open the serial port and connect the with the tcp-listen, port 4001 (can be anything)

Now you can connect to it from your application. Or socat is also very flexible, for example:

socat -dd tcp:$RPI_IP:4001 pty,rawer,link=/tmp/ttyTCP # tcp client back to pseudo serial terminal
socat -dd tcp:$RPI_IP:4001 - # tcp client to stdin/stdout

The functionality could be also quite easily integrated into ble-serial, in the current architecture it would add a tcp server module and hook it up instead of the serial port emulation. Then it would be just a arg like --expose-tcp-port and get rid of the additional tool/process. I might add that if there is more interest.

Security is also to consider though, this is plain TCP without encryption or authentication. Don't know, your BMS also allows changing settings over this port? I would only run this on a separate local network, where nothing else can reach it. Otherwise large misconfigured batteries can be quite dangerous.

[RoySalisbury]

Great. I will give this a shot. I'd like to use it in a "closed" network where I have multiple battery banks that are not all within BLE range of the server, but I do have WiFi access. Adding in a small Pi Zero W to convert from BLE to serial and then serial to TCP/IP might help. (bypassing serial all together would be even better).

I'm not as much worried about the security, but it could be a concern for others. However, most people don't bother to change the "PIN" from the default on the BMS, and even that the PIN can be bypassed.

Roy

[RoySalisbury]

So, this works great but with a few "quirks".

1. When the client disconnects from the socket, socat exits as well. I can get around this by setting up a simple bash script in a "while true" loop that just keeps restarting socat.
2. You can send ble-serial to the background with the "&", and get it back using fg (so it can be stopped). But how would you do that in a bash script that also starts up socat. When I exit the script I would like to also stop ble-serial process.

Linux is not a "native" OS for me so I don't know a lot of the "tricks" to use.

[RoySalisbury]

I got something to work, but it has a few "gotchas".

1. When starting BLE-SERIAL and sending it to the background, it may not completely finish (or it may error out) before SOCAT starts up. I put a delay/sleep in to give it some extra time to startup, but if it fails, there is no way to detect it.

2. I tried sending a SIGINT to the background process for BLE-SERIAL, but that did not seem to properly shut things down. What does work however is to haver BLUETOOTHCTL disconnect the device .. the BLE-SERIAL will shutdown and release the /tmp/ttyBLE port. I also do this BEFORE trying to setup BLE-SERIAL so I know its in a good state to start with.

Ultimately here is what I had came up with. I'm sure there is a better way ...

#!/bin/bash

BLE_ADDRESS=70:3E:97:08:17:37
BLE_REDIRECT=/tmp/ttyBLE1
BLE_REDIRECT_PORT=4002


# Make sure the device is disconnected  before trying to setup the BLE-SERIAL redirect
bluetoothctl disconnect $BLE_ADDRESS

# Setup the redirect 
ble-serial -d $BLE_ADDRESS -p $BLE_REDIRECT &

# need to wait for the redirect to be setup
sleep 10

# Setup SOCKET listener for BLE redirect
socat -d -d -d -s open:$BLE_REDIRECT TCP-LISTEN:$BLE_REDIRECT_PORT,fork,reuseaddr &
PID1=$!

# Setup the  CTRL-C (break) handler so we can shut down the  socket listener and disconnect the BLE device.
handler()
{
    kill -s SIGINT $PID1
    bluetoothctl disconnect $BLE_ADDRESS
}

# Hook into the SIGINT trap
trap handler SIGINT

# Wait until we signal an exit
sleep 1 & wait

# Complete
echo "Done"

[Jakeler]

1. Well, you could do something like while [ ! -f $BLE_REDIRECT ] and sleep until the file actually exists
2. Should work, I would consider it a bug otherwise. If you can reproduce this without the script and direct ctrl-C then please fill out the issue template.

After all the scripting is hard to get completely without quirks.
Instead I have added a basic implementation into ble-serial now, not tested very much but if you want to try:

pip install --force-reinstall https://github.com/Jakeler/ble-serial/archive/refs/heads/tcp-socket.zip

Run it with --expose-tcp-port 4002 to use the integrated tcp server instead of the local serial port.

[RoySalisbury]

I have tried the new version and it seems to work (still testing a few read/write delay). But it suffers from the same thing that socat did at the start (dies after client disconnect). You would need the same type of "fork" logic that socat uses.

I also tried the while [ ! -f $BLE_REDIRECT ] do logic, but it never detects the new filename (/tmp/ttyBLE1). Could be that it only works on actual FILENAMES and not serial devices.

I also tried putting together a test of the CTRL-C issue. If you start ble-serial & directly, then you can kill it with the SIGTERM. But if its started in a bash script, it has no effect. Kinda odd. I'll try a few more things and then write up an issue and post it with example.

Roy

[Jakeler]

Can't reproduce this, tried connecting and disconnecting multiple times, sending weird packets etc... could not get it to die.
Note that it's limited to one connection, so it will reject all connection attempts if there is already a client connected and you should see a warning level log message.
Experiments were with socat -dd tcp:localhost:4001 -, even with a hard killall -9 socat it releases the socket and it's allowing for new connections afterwards. Let me know how you triggered the different behavior otherwise, so I can fix it.

[Jakeler]

Ok, I indeed found issues on system exceptions. For example when receiving a tcp RST or retransmission timeout (which happens after >900 sec per default). Should be fixed now via 241e4ea. You can try the new version with the same reinstall command.