We have moved to a new Sailfish OS Forum. Please start new discussions there.
9

BLE GATT/GAP Server in bluez5 not working as expected

asked 2018-05-09 17:08:50 +0300

pigg gravatar image

updated 2018-05-12 19:23:15 +0300

While writing an app that does BLE GATT to a watch, i found that I get disconnected routinely every 15 minutes. I logged all the traffic from an android device, and found that every 120 seconds, the watch does the following command: Read By Type Request, Device Name, Handles: 0x0001..0xffff

On android, this returns the device name as expected. On sailfish, this returns 'Request not supported' as per the following btmon log:

ACL Data RX: Handle 6 flags 0x02 dlen 11 #1086 [hci0] 820.764748 ATT: Read By Type Request (0x08) len 6 Handle range: 0x0001-0xffff Attribute type: Device Name (0x2a00) < ACL Data TX: Handle 6 flags 0x00 dlen 9 #1087 [hci0] 820.765724 ATT: Error Response (0x01) len 4 Read By Type Request (0x08) Handle: 0x0000 Error: Request Not Supported (0x06)

Bluez devs believe this works fine upstream, and tested it, so put the blame on the mer build.

Are there any patches that would break this? Any config needed to enable this?

Next step for me is to write a quite desktop app and see what bluez on my deskop returns.

edit retag flag offensive close delete

Comments

1

Tested on laptop, and it does indeed return the device name

ACL Data RX: Handle 3585 flags 0x02 dlen 11 #52 [hci0] 61.863403 ATT: Read By Type Request (0x08) len 6 Handle range: 0x0001-0xffff Attribute type: Device Name (0x2a00) < ACL Data TX: Handle 3585 flags 0x00 dlen 24 #53 [hci0] 61.863711 ATT: Read By Type Response (0x09) len 19 Attribute data length: 18 Attribute data list: 1 entry Handle: 0x0003 Value: 4368726f6d654c696e75785f41344645

pigg ( 2018-05-09 20:02:31 +0300 )edit
1

For info, i tried building bluez5 from upstream git, with no patches, and the behaviour was the same. Could this be kernel related if its not in bluetoothd? ( i doubt it, but struggling now!)

pigg ( 2018-05-10 08:38:24 +0300 )edit
1

After an extensive debugging session, I found that the GATT db IS created when i click on the watch from the Sailfish BT settings GUI. This causes all the correct code to be executed in bluetoothd to create the GATT/GAP db and services.

The problem seems to be that none of that code is executed when my Qt all creates the connection.

Im open to suggestions, the debugging continues!

pigg ( 2018-05-12 11:04:45 +0300 )edit

Perhaps https://bugreports.qt.io/browse/QTBUG-46819 is relevant.

I think, if the dbus api was used, then the gatt server would be created, but because bluetooth in qt 5.6 uses the l2cap api (afaict) it doesnt create the gatt server. Cant decide if it is a bluez bug, or a qt bug!

pigg ( 2018-05-12 19:22:02 +0300 )edit
3

Qtconnectivity in 5.11 will fix all this. Salfish will likely switch to 5.9 in 3.0. according to the bug report, connectivity from .11 can be built for 5.9 with some minor changes changes, perhaps Jolla could consider this?

pigg ( 2018-05-14 12:40:31 +0300 )edit

1 Answer

Sort by » oldest newest most voted
8

answered 2018-05-19 10:45:19 +0300

pigg gravatar image

So, to work around this limitation, i wrote my own wrapper around the bluez dbus api. It currently does everything i need it to from the qt api, and get the gatt server running.

See https://github.com/piggz/harbour-amazfish/tree/master/qble and feel free to use it. I ought to make it a seperate project and use it as a git sub project.

edit flag offensive delete publish link more

Comments

1

Seems as no one has helped you or has done anything with this protocol. Maybe you could address this topic in a different channel, because I think the Jolla devs are not very present here on TJC. Some topics are here for years and never got any fix :/

SaimenSays ( 2018-05-19 15:59:56 +0300 )edit
Login/Signup to Answer

Question tools

Follow
2 followers

Stats

Asked: 2018-05-09 17:08:50 +0300

Seen: 815 times

Last updated: May 19 '18