0.5.3-8 issues with bleno

[alecfriedman3]

Hi, not sure where to file this issue but this seems like the best place. We're using bleno in an iot project at my company and noticed a problem connecting to our devices specifically when using v0.5.3-8 of this project. Devices will connect and pair, but when trying to actually communicate the connection doesn't respond. In a chrome browser (where we're connecting to the gatt server from) we get an error that says No Services matching UUID <uuid> found when trying to retrieve the primary service by uuid. This problem isn't exhibited when using earlier versions of this project (0.5.3-7 works as expected)

This commit seems like it could be a source of the problem 3ebb846 (by process of elimination looking at other commits between the two latest releases)

We have a simple nodejs bleno project that exhibits the issue when switching between versions if you need to see the problem; it's running on debian buster, node 12. We don't have the resources to find an actual fix here and are going to lock our versions on the previous ones, but thought someone should be made aware of what seems like a bug here

[rzr]

hi thx for feedback, may @splitice help you can propose a revert change at worst case.

[Zwimber]

Same issue here, after updating new problems have arrissen.

[splitice]

Perhaps someone who understands bleno can work out the behavioural difference?

Ive never used bleno but the change has a huge positive impact on noble (devices actually can be connected to reliably).

I'm not the original author of the patch thats @sandeepmistry . I only fixed an observed issue, tested that it resolved our issues and presented it for PR.

Unfortunately I'm not sure documentation on the workaround from the original hci socket even exists?

The patch does multiple things perhaps if you have a repeatable failure work out which part of it causes issue (e.g the re-ordering of the workaround, the proc writes etc). perhaps the proc control settings isnt suitable for an end device ?

[rzr]

you can propose a revert fix until a better solution is found

[splitice]

Honestly I think someone needs to nut this out on the bleno side. There is no documentation on either the original workaround or the new. It could well be that neither is completely working and one works for noble and the other bleno. We won't know why until people who use bleno troubleshoot I think.

As I said I have no experience with bleno but this fixes noble.

[splitice]

We had our team meeting today, if someone on the bleno side can work out which element of the patch causes problems (or useful information) we will integrate and test in our present product iteration.

The more information that can be provided the better. I'll also drop any notes from in-advance research in this issue.

We are going to take a look at both work arounds and see what we can figure out regarding it. Our interest lies with noble but am happy to improve components for the good of the community (within the resources available).

[splitice]

My first guess regarding bleno issues is that the connect/disconnect workaround did not apply originally for this use case (i.e on connect) but now does (or visa versa). This can be tested by putting a printf in the connect (if block) and seeing if for each version the block is triggered.

My second guess would be that bleno requires the l2cap socket to be maintained throught the connection (instead of just used to force a flush as was originally intended). This can be tested by removing the close().

[splitice]

Third guess

data[7] == 0x01 is if connecting to a slave device (i.e no workaround for bleno devices) this was introduced in the imported patch and worth removing for testing.

[goofiw]

This might be an edge case. But I have bleno working on my mac, but am unable to discover services when running on a raspberry pi 4 in a docker container (pi is on ubuntu, docker is using buster). Devices do scan, and Noble is working fine.

[Apollon77]

Which MacOS version? Apple broke discovery with macos 12.3 ... could be fixed by 12.3.1

[splitice]

I am currently looking into (what I suspect) is issues when connections are terminated by supervisor timeout with one device (noble not bleno) currently. I don't (yet) know why.

Honestly this work around is really bad. But fixing it would likely mean at-least API change.

In a nutshell the work around ensures that there is a Linux socket created for each connection (preventing gc of connection).

There however exists races with that cleanup. And multiple connection creation / disconnection methods with some being racey.