Closed aefrtyi closed 1 year ago
From the logs, we can see that BlueZ does not add D-Bus objects for the services and characteristics. BlueZ hides certain services, so it could be possible that the device doesn't have any services that are not hidden. Or there could be issues with the BlueZ cache which can be fixed by removing the device from BlueZ and manually deleting a cache file (see troubleshooting section of the docs).
I've checked but as far as I know, my device does not have hidden services or characteristics. I followed the troubleshooting section to clear the cache, but it seems my device is not in cache at all:
[bluetooth]# remove 53:4E:48:00:00:07
Device 53:4E:48:00:00:07 not available
root@iot-gate-imx8:/var/lib/bluetooth/14:F6:D8:45:10:04/cache# ls
00:21:AD:13:13:20 90:78:B2:A8:BB:4E 90:FD:9F:A7:EE:EF D8:4D:72:F9:22:2D ED:7B:67:62:26:66
38:18:4C:BF:37:05 90:FD:9F:A7:ED:39 CC:98:8B:E0:6A:3A E4:B3:66:BE:30:94 F0:2E:89:CE:50:4E
The next thing I would try is logging bluetooth packets using wireshark on Linux to see what is going on there and compare it to the same on windows.
I do not have a GUI on the linux device I used, so I used tshark instead of wireshark. I already attached the results in my first post. Bellow are the results I got on windows using the same scripts. wireshark_comm_windows.log wireshark_scan_windows.log
The linux "wireshark" logs don't include the actual packet data, so are not as useful as they could be. The windows logs seem to contain TCP data, not bluetooth.
I'll see if I can get the packet data. For windows, I tried all interfaces shown by wireshark and I used the only one that had data when I ran my scripts. The only other interface that had data was the wifi one
There is a special external program from Microsoft required on Windows. See the Bleak troubleshooting docs for details.
My bad, completely missed this part. Here are the files with packet data tshark_comm_linux.log wireshark_scan_windows.log wireshark_comm_windows.log tshark_scan_linux.log .
Thanks. From the tshark_comm_linux.log
:
BlueZ requests an MTU of 512, but the device replies that it wants to use 517. So BlueZ agrees and asks if the device wants to use 517, but then the device says that is invalid. BlueZ then disconnects. So the problem appears to be with the device.
On Windows, we can see the MTU exchange was successful.
bluetoothctl -v
) in case of Linux: 5.55Description
I have a ble peripheral device that has a custom scan response data in EIR 0x42. I previously used bluepy on linux to scan and communicate with it, but I wanted to be able to use my code on both windows and linux, so I switch to bleak.
I managed to scan my device with the expected data on windows and communicate with it successfully, however, when I try to do so on linux, BleakClient.get_services() returns an empty dict, and I am unable to find the adv data I'm looking for.
What I Did
Scanner:
which gives me the following result on linux:
Communication on windows:
As for the discovery of services, using the example get_services(), just changing the mac address, I obtain the following:
I did find when reading the bluetooth service logs
but I'm unsure if it's the related to my issue.
I'm also attaching the bleak logs I got during scan and get_services() as well as the bluetooth trafic captured with tshark in case it could help. bleak_log_comm.log wireshark_scan.log wireshark_comm.log bleak_log_scan.log