Force Bluetooth connection to same device after Timeout

[KreAch3R]

Hello @manio!

I've been using my solution with your aa-proxy-rs on my car for a couple of days now and it works beautifully. I have noticed a minor inconvenience. If, for some reason, it throws a USB read/write" and/or "TCP deadline has elapsed and it disconnects, it won't re-connect to bluetooth on its own and the only way to make it restart is to restart the rpi, if you are driving. I suspect this is because the phone thinks it is already connected so it won't try to re-connect. I am talking about using it without the "-c connect" option.

These are the running parameters:

AA_PROXY_RS_ARGS="-b NaviPi --hostapd-conf /etc/hostapd/hostapd.conf -k"

This is the log:

2025-01-25, 14:35:55.605 [INFO] 🛸 aa-proxy-rs is starting, build: 20241228_022643, git: 20241224-38a633c-dirty
2025-01-25, 14:35:55.637 [INFO]  main:  📜 Log file path: /var/log/aa-proxy-rs.log
2025-01-25, 14:35:55.637 [INFO]  main:  ⚙️ Showing transfer statistics: disabled
2025-01-25, 14:35:55.692 [INFO]  proxy:  🛰️ Starting TCP server...
2025-01-25, 14:35:55.692 [INFO]  proxy:  🛰️ TCP server bound to:  0.0.0.0:5288
2025-01-25, 14:35:55.692 [INFO]  proxy:  💤 waiting for bluetooth handshake...
2025-01-25, 14:35:55.766 [INFO]  usb:  Using UDC: "dummy_udc.0"
2025-01-25, 14:35:55.767 [INFO]  usb:  🔌 Initializing USB Manager
2025-01-25, 14:35:55.767 [INFO]  usb:  🔌 USB Manager: Disabled all USB gadgets
2025-01-25, 14:35:55.768 [INFO]  bluetooth:  🥏 Bluetooth alias: NaviPi
2025-01-25, 14:35:55.890 [INFO]  bluetooth:  🥏 Opened bluetooth adapter hci0 with address B8:27:EB:86:FF:AE
2025-01-25, 14:35:55.979 [INFO]  bluetooth:  📱 AA Wireless Profile: registered
2025-01-25, 14:35:55.981 [INFO]  bluetooth:  🎧 Headset Profile (HSP): registered
2025-01-25, 14:35:55.981 [INFO]  bluetooth:  ⏳ Waiting for phone to connect via bluetooth...
2025-01-25, 14:36:15.748 [INFO]  bluetooth:  📱 AA Wireless Profile: connect from: 30:74:67:AF:9C:C2
2025-01-25, 14:36:15.749 [INFO]  bluetooth:  📲 Sending parameters via bluetooth to phone...
2025-01-25, 14:36:15.749 [INFO]  bluetooth:  🛜 Sending Host IP Address: 10.0.0.1
2025-01-25, 14:36:15.749 [INFO]  bluetooth:  📨 stage #1 of 5: Sending WifiStartRequest frame to phone...
2025-01-25, 14:36:15.997 [INFO]  bluetooth:  📨 stage #2 of 5: Received WifiInfoRequest frame from phone (⏱️ 247 ms)
2025-01-25, 14:36:15.997 [INFO]  bluetooth:  🛜 Sending Host SSID and Password: NaviPi, AANaviPi
2025-01-25, 14:36:15.997 [INFO]  bluetooth:  📨 stage #3 of 5: Sending WifiInfoResponse frame to phone...
2025-01-25, 14:36:15.998 [INFO]  bluetooth:  📨 stage #4 of 5: Received WifiStartResponse frame from phone (⏱️ 0 ms)
2025-01-25, 14:36:20.143 [INFO]  bluetooth:  📨 stage #5 of 5: Received WifiConnectStatus frame from phone (⏱️ 4143 ms)
2025-01-25, 14:36:20.143 [INFO]  bluetooth:  🚀 Bluetooth launch sequence completed
2025-01-25, 14:36:20.143 [INFO]  proxy:  🛰️ TCP server: listening for phone connection...
2025-01-25, 14:36:20.882 [INFO]  proxy:  📳 TCP server: new client connected: 10.0.0.20:34940
2025-01-25, 14:36:20.882 [INFO]  proxy:  📂 Opening USB accessory device: /dev/usb_accessory
2025-01-25, 14:36:20.883 [INFO]  proxy:  ♾️ Starting to proxy data between TCP and USB...
2025-01-25, 14:36:20.971 [INFO]  usb:  🔌 USB Manager: Switched to accessory gadget
2025-01-25, 14:36:20.971 [INFO]  bluetooth:  🥷 Unregistering default agent
2025-01-25, 14:36:20.971 [INFO]  bluetooth:  📱 Removing AA profile
2025-01-25, 14:36:23.473 [WARN]  bluetooth:  🎧 Error waiting for HSP profile task: deadline has elapsed
2025-01-25, 14:36:23.473 [INFO]  bluetooth:  💤 Bluetooth adapter stays on
2025-01-25, 14:58:46.080 [ERROR]  proxy:  🔴 Connection error: USB write: deadline has elapsed
2025-01-25, 14:58:47.437 [INFO]  proxy:  ⌛ session time: 22m 27s 707ms 590us 457ns
2025-01-25, 14:58:47.437 [INFO]  proxy:  💤 waiting for bluetooth handshake...
2025-01-25, 14:58:47.441 [INFO]  main:  📵 TCP/USB connection closed or not started, trying again...
2025-01-25, 14:58:48.443 [INFO]  usb:  🔌 Initializing USB Manager
2025-01-25, 14:58:49.090 [INFO]  usb:  🔌 USB Manager: Disabled all USB gadgets
2025-01-25, 14:58:49.090 [INFO]  bluetooth:  🥏 Bluetooth alias: NaviPi
2025-01-25, 14:58:49.159 [INFO]  bluetooth:  🥏 Opened bluetooth adapter hci0 with address B8:27:EB:86:FF:AE
2025-01-25, 14:58:49.224 [INFO]  bluetooth:  📱 AA Wireless Profile: registered
2025-01-25, 14:58:49.230 [INFO]  bluetooth:  🎧 Headset Profile (HSP): registered
2025-01-25, 14:58:49.231 [INFO]  bluetooth:  ⏳ Waiting for phone to connect via bluetooth...
2025-01-25, 17:54:10.801 [INFO] 🛸 aa-proxy-rs is starting, build: 20241228_022643, git: 20241224-38a633c-dirty

I will try to increase the --timeout-secs parameter and see if this decreases the frequency, but the root problem of not re-connecting to bluetooth remains.

I thought of a solution; What if we save the connected bluetooth mac somewhere, and in the case of a timeout/connection error, we try to reconnect to the same bluetooth device? Only on the next restart, the default behavior will still hold, i.e. wait for any bluetooth connection. What do you think?

[manio]

Hi,

What if we save the connected bluetooth mac somewhere, and in the case of a timeout/connection error, we try to reconnect to the same bluetooth device?

Isn't it what -c does but without any MAC-address argument?

[KreAch3R]

Hmm is that so?

What happens if you run it with the -c argument but for the first time for a new phone/raspberry pi? I'd have to test that again. I think that in my tests, it didn't do anything, so I had to remove it. I'm trying to make it use one command for the whole sequence of setting up and installing, the user shouldn't need to mess with the command line afterwards.

[KreAch3R]

Ok, so I've went on some long drives and the disconnect happened a couple of times. The '-c` option did work, but it kept cycling through all connected devices, see screenshot:

I think this won't be easy to solve. Currently, I am using the --keepalive option. That means, aa-proxy-rs doesn't kill the bluetooth connection. When the disconnect happens, aa-proxy-rs tries to restart the whole connection sequence, and can't "properly" re-connect to the phone, because the phone shows up as connected. This doesn't trigger the Android Auto launching sequence, and it shows up as "Unavailable" on the OpenAuto-Pro. If I restart the aa-proxy-rs service AND kill the connection from the phone, then the device successfully re-connects. Do you imagine any way of automating this so it can run itself when it detects a disconnect?

I upped the timeout value to 15s but I'm not sure that is the reason of the disconnect. It always drops when I pass by certain locations, so I'm thinking it's more of a Wi-Fi jamming/dropping issue, than a device timeout issue.

[manio]

kept cycling through all connected devices

It is cycling all devices which are saved for your BT adapter in /var/lib/bluetooth/... The problem is that in single configuration like raspberry pi for only android auto there is usually only a single device (your phone) - but I know you're using it differently so you have a plenty of other devices (btw: the TPMS is a bluetooth device for reading your tire sensors?).
What if you pass: -c 30:74:67:AF:9C:C2?

When the disconnect happens, aa-proxy-rs tries to restart the whole connection sequence, and can't "properly" re-connect to the phone, because the phone shows up as connected.

Is it because the keepalive? Normally if aa-proxy-rs detects transfer stall (no matter if it is because of WiFi or USB), then it is triggering the connection recovery.

[KreAch3R]

It is cycling all devices which are saved for your BT adapter in /var/lib/bluetooth/... The problem is that in single configuration like raspberry pi for only android auto there is usually only a single device (your phone) - but I know you're using it differently so you have a plenty of other devices (btw: the TPMS is a bluetooth device for reading your tire sensors?). What if you pass: -c 30:74:67:AF:9C:C2?

Yeah, if I pass the mac, it will try to only connect to the phone. But that hardcodes the mac address and doesn't make it easy to connect another phone, set it up from the beginning etc. I get what you are saying, it should work as a fix, but wouldn't it be cleaner if, after successful connection, aa-proxy-rs caches the mac address somewhere and tries to only connect to it, like I suggested in the first post?

And yes, the TPMS devices are bluetooth internal tpms sensors which I have integrated into my OpenAuto-Pro setup. Check it out here: https://github.com/KreAch3R/tpms-oap :)

Is it because the keepalive? Normally if aa-proxy-rs detects transfer stall (no matter if it is because of WiFi or USB), then it is triggering the connection recovery.

Yeah, maybe it's because of the keepalive. The connection recovery tries to re-connect but the phone is still connected, somewhing happens with the bluetooth driver there and it stalls. It doesn't kill the existing bluetooth connection with the phone. A restart of the bluetooth service or a whole unit restart fixes it.

I guess I can try to remove the keepalive for a while and check what happens. I need it alive so I can bluetooth tether the phone to provide internet to the rpi.

[manio]

after successful connection, aa-proxy-rs caches the mac address somewhere and tries to only connect to it, like I suggested in the first post?

that wouldn't work in my scenario when my wife wanted to use it after me :)

It doesn't kill the existing bluetooth connection with the phone. A restart of the bluetooth service or a whole unit restart fixes it.

so maybe the solution would be to force bluetooth disconnection when it discover transfer stall (with keepalive switch)?

[KreAch3R]

that wouldn't work in my scenario when my wife wanted to use it after me :)

Ah I see. Conflicting user cases :)

so maybe the solution would be to force bluetooth disconnection when it discover transfer stall (with keepalive switch)?

yeah it could work, can we do it?

[manio]

yeah it could work, can we do it?

I'll look into this when I have some free time (rather next week)

[manio]

Try this: https://github.com/manio/aa-proxy-rs/tree/keepalive-bt-test