service discovery issues causing disconnect

[davnustratbac]

Moved from AsteroidOs issues.
I have now made further progress in tracking this error, I believe this to be a better repo to raise the issue.
The local services seem to be able to register correctly to the bluez stack, however on request from remote connections the service discovery results appear to cause the errors below.
This can be reproduced on any pairing and SD session and does not appear to be specific to AsteroidOSsync app.
My fedora based laptop using bluez5 & supported hardware also fails.
On the latest build for dory there seems to be an issue with Bluetooth connection failing. After
numerous attempts, it seemed to successfully pair but seems to fail then disconnect. logs show failure at negotiating services. bluetoothd also reports no cache for device address.
The link below has a gist with logs for hcitrace via btmon and journalctl logs with bluetoothd in DEBUG mode.

there is approximately one connection, pairing , and disconnect in the logs which can be found here:

https://gist.github.com/davnustratbac/e99e46c098cea85796fdb2a91b189a44

Packet dump file of same timeframe:

https://s3-eu-west-1.amazonaws.com/wireshark-bucket/journalctl-debug-bluetoothd-74-105.log

3 packet overview:

ACL Data RX: Handle 64 flags 0x02 dlen 9 #94 [hci0] 86.882368
ATT: Error Response (0x01) len 4
Read By Group Type Request (0x10)
Handle: 0x0001
Error: Unsupported Group Type (0x10)

ACL Data TX: Handle 64 flags 0x00 dlen 11 #95 [hci0] 86.882940
ATT: Read By Type Request (0x08) len 6
Handle range: 0x0001-0xffff
Attribute type: Include (0x2802)

further back in time in the logs this request may be involved :

< ACL Data TX: Handle 64 flags 0x00 dlen 11 #89 [hci0] 78.332507
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x0001-0xffff
Attribute group type: Secondary Service (0x2801)

[FlorentRevest]

Hi @davnustratbac, thanks for your in-depth debugging!
It looks like the problem may lie in BlueZ itself, maybe it would be worth asking the BlueZ developers what could cause that issue?

I'm also a bit surprised by
Nov 21 16:13:13 dory bluetoothd[1109]: ../bluez-5.46/src/agent.c:agent_request_confirmation() Calling Agent.RequestConfirmation: name=:1.38, path=/org/asteroidos/launcher/agent, passkey=097704
Nov 21 16:13:49 dory bluetoothd[1109]: ../bluez-5.46/src/device.c:att_disconnected_cb()
Did you confirm the connection on the UI side? It looks like the auth agent hits some kind of timeout and cancels the connection.

[davnustratbac]

Hi, I will take this up further and investigate the bluez interaction and see what I can discover to present to the BlueZ developers.
Indeed, as you say the connection on the UI side never seems to complete. The logs show confirmation and agreement throughout, however, the relationship between the devices becomes stale and appears not to have fully initiated. Im wondering if this is due to the error raised during service discovery, without further investigation I couldnt be more certain, however it would seem rational for a timeout to make an (eventual) timely cessation. I will probably need to snoop around that area too, to verify any possible dependancy chain.
If you envisage a more efficient approach please feel free to include your further directions.