Sending causes ble-serial to terminate

[senglk]

I need some help. I can't seem to send (or receive) with ble-serial.

Setup 1 (Sanity testing, does not involve ble-serial):
PC(RPi5, Ubuntu 24.04) - FT232 - BLE-DEVICE - PHONE(android)

With setup 1, with serial_bluetooth_terminal on phone, and minicom on PC, I was able to send and receive between the devices.

Setup 2:
PC(RPi5, Ubuntu 24.04 | Laptop, Ubuntu 20.04) - BLE-DEVICE - FT232 - Laptop(Windows, sending via COM3 with Arduino IDE)

On PC I run ble-serial, and on another terminal, I run minicom. When I try to send even a single letter (ENTER/LF/\n in example below) on minicom, ble-serial stops:

This is the -vvv output:

19:20:49.991 | INFO | ble_interface.py: Trying to connect with FD:05:D3:64:F7:76: BLE_DEVICE
19:20:49.992 | DEBUG | client.py: Connecting to device @ FD:05:D3:64:F7:76
19:20:50.003 | DEBUG | client.py: Connecting to BlueZ path /org/bluez/hci0/dev_FD_05_D3_64_F7_76
19:20:50.997 | DEBUG | manager.py: received D-Bus signal: org.freedesktop.DBus.Properties.PropertiesChanged (/org/bluez/hci0/dev_FD_05_D3_64_F7_76): ['org.bluez.Device1', {'Connected': <dbus_fast.signature.Variant ('b', True)>}, []]
19:20:51.076 | DEBUG | manager.py: received D-Bus signal: org.freedesktop.DBus.Properties.PropertiesChanged (/org/bluez/hci0/dev_FD_05_D3_64_F7_76): ['org.bluez.Device1', {'ServicesResolved': <dbus_fast.signature.Variant ('b', True)>}, []]
19:20:51.077 | INFO | ble_interface.py: Device FD:05:D3:64:F7:76 connected
19:20:51.077 | DEBUG | ble_interface.py: No write uuid specified, trying builtin list
19:20:51.077 | DEBUG | ble_interface.py: Characteristic candidates for write: 
	0000ffe1-0000-1000-8000-00805f9b34fb (Handle: 15): Vendor specific ['write', 'notify']
19:20:51.077 | INFO | ble_interface.py: Found write characteristic 0000ffe1-0000-1000-8000-00805f9b34fb (H. 15)
19:20:51.077 | DEBUG | ble_interface.py: No notify uuid specified, trying builtin list
19:20:51.077 | DEBUG | ble_interface.py: Characteristic candidates for notify: 
	0000ffe1-0000-1000-8000-00805f9b34fb (Handle: 15): Vendor specific ['write', 'notify']
19:20:51.077 | INFO | ble_interface.py: Found notify characteristic 0000ffe1-0000-1000-8000-00805f9b34fb (H. 15)
19:20:51.088 | INFO | main.py: Running main loop!
19:21:11.640 | DEBUG | manager.py: received D-Bus signal: org.freedesktop.DBus.ObjectManager.InterfacesRemoved (/): ['/org/bluez/hci0/dev_9C_74_03_82_ED_15', ['org.freedesktop.DBus.Properties', 'org.freedesktop.DBus.Introspectable', 'org.bluez.Device1', 'org.bluez.MediaControl1', 'org.bluez.Network1']]
19:21:22.529 | DEBUG | linux_pty.py: Read: b'\n'
19:21:22.529 | DEBUG | ble_interface.py: Sending b'\n'
19:21:22.531 | ERROR | main.py: Bluetooth connection failed: [org.bluez.Error.Failed] Not connected
19:21:22.532 | WARNING | main.py: Shutdown initiated
19:21:22.532 | INFO | linux_pty.py: Serial reader and symlink removed
19:21:22.538 | DEBUG | client.py: Disconnecting ({/org/bluez/hci0/dev_FD_05_D3_64_F7_76})
19:21:24.918 | DEBUG | manager.py: received D-Bus signal: org.freedesktop.DBus.Properties.PropertiesChanged (/org/bluez/hci0/dev_FD_05_D3_64_F7_76): ['org.bluez.Device1', {'ServicesResolved': <dbus_fast.signature.Variant ('b', False)>}, []]
19:21:24.919 | DEBUG | manager.py: received D-Bus signal: org.freedesktop.DBus.Properties.PropertiesChanged (/org/bluez/hci0/dev_FD_05_D3_64_F7_76): ['org.bluez.Device1', {'Connected': <dbus_fast.signature.Variant ('b', False)>}, []]
19:21:24.919 | DEBUG | client.py: Device disconnected (/org/bluez/hci0/dev_FD_05_D3_64_F7_76)
19:21:24.919 | DEBUG | client.py: _cleanup_all(/org/bluez/hci0/dev_FD_05_D3_64_F7_76)
19:21:24.920 | WARNING | ble_interface.py: Device FD:05:D3:64:F7:76 disconnected
19:21:24.920 | INFO | ble_interface.py: Stopping Bluetooth event loop
19:21:24.921 | INFO | ble_interface.py: Bluetooth disconnected
19:21:24.921 | INFO | main.py: Shutdown complete.

This is what the ble-scan result shows:

Found device FD:05:D3:64:F7:76: BLE_DEVICE (out of 1)
SERVICE 0000ffe0-0000-1000-8000-00805f9b34fb (Handle: 14): Vendor specific
     CHARACTERISTIC 0000ffe1-0000-1000-8000-00805f9b34fb (Handle: 15): Vendor specific ['write', 'notify']
         DESCRIPTOR 00002902-0000-1000-8000-00805f9b34fb (Handle: 17): Client Characteristic Configuration
     CHARACTERISTIC 0000ffe2-0000-1000-8000-00805f9b34fb (Handle: 18): Vendor specific ['write']
SERVICE 00001801-0000-1000-8000-00805f9b34fb (Handle: 10): Generic Attribute Profile
     CHARACTERISTIC 00002a05-0000-1000-8000-00805f9b34fb (Handle: 11): Service Changed ['indicate']
         DESCRIPTOR 00002902-0000-1000-8000-00805f9b34fb (Handle: 13): Client Characteristic Configuration

Completed deep scan of FD:05:D3:64:F7:76

I wonder what am I missing to get ble-serial to work on PC?

[senglk]

After further analysis, it was concluded that this is either due to how blueZ work, or more likely, some specific requirement by the device. See hbldh/bleak#1692. For this particular device, unfortunately, I will have to modify the code so as to force a pair() instead of a connect() to write and notify.

[Jakeler]

Interesting and weird, usually you can pair devices beforehand and it works. What device is it exactly?

Looking at your linked analysis/discussion I wonder why it says HC-05, which would be a Bluetooth 2 BR/EDR (classic) module. At the same time the scan result shows a LE profile. Maybe related to #84?
Unfortunately I don't have a dual mode device to test, but the linked issues look a bit similar. Also hbldh/bleak#701 (comment) hints that bonding affects the selected mode. Bonding is permanent storage of pairing keys so maybe it acts the same only if the pairing is fresh.
You could try if it works with legacy tools like rfcomm or Android in classic mode too.
For BLE you can try with bluetoothctl directly connect ... - menu gatt - select-attribute 0000ffe1-0000-1000-8000-00805f9b34fb - write "0x42 0x4C 0x45" for example, to make sure it's not caused by bleak etc.

[senglk]

I don't know what device it is, all I know is that it isn't an HC-05, given that it doesn't have SPP and consequently not work with rfcomm (that's why I need ble-serial!). I don't think it is dual mode (first time hearing this) given that I don't see other characteristics.

Variations bluetoothctl commands you have provided was what I used to "discover" that I had to make a "fresh" pairing get write/notify to work - If only connect was done without prior pair, the connection is successful but is almost immediately disconnected. If pair was successful, the device is connected, and thus write can be performed successfully. However, if pair - disconnect - connect was done, write would return with some error to the tune of "could not write".

Maybe my unknown device doesn't store keys after a bond, necessitating a constant need to pair to generate working keys.

[Jakeler]

Hmm ok, do you get "Bonded: yes" from info?
Otherwise idk, have never seen this before. Only wild guesses without seeing the firmware of this device.