search

edrosten / libblepp

Modern clean C++ Bluetooth Low Energy on Linux without the Bluez DBUS API
Other
239 stars 62 forks source link

Missing MTU response #31

Closed Stretchdude closed 5 years ago

Stretchdude commented 6 years ago

Hello,

I found (after upgrading our BLE device to newer BLE-Stack), that a request for MTU exchange is treated as an error. The state machine is bailing out with "unexpected response". After some debugging I manage to hold the connection alive by sending a faked response (which sends static 24 as MTU, the "old value" from the device).

I append my hack as patch to let you have a look.

Regards Ben

liblepp_mtu_hack.patch.txt

trace of the hack: mtu_request_ws_trace

edrosten commented 6 years ago

Hi, thanks for the bug report! I'm a bit busy at the moment so it might take me a while to figure it out.

Stretchdude commented 6 years ago

Hello,

thanks for your reply. I had made kind of progress on this issue. I was able to create a MTU denial response like gattool. But still it can get cought in a deadlock if the timing is unfortunate. If the Device hits the gap where the state machine ignores the MTU request (I am not sure when and why this exactly can happen) both communication partners wait for the other one to send a response: Device waits for MTU stuff. State machine waits for feature list (services + characteristics). Anyways - I could create a way better workaround and append as a patch. This one still feels like abusing your state machine ;-) The newer one raised the rate for successfull connections from 0% to around 80%. (The first patch was around 50%)

missingMtuWorkaround.patch.txt

Regards Ben

edrosten commented 6 years ago

I don't have any hardware that does that. Can you set the logging level to the highest setting and post the resulting log?

On Wed, 11 Jul 2018, 09:07 Stretchdude, notifications@github.com wrote:

Hello,

thanks for your reply. I had make kind of progress on this issue. But still it can get cought in a deadlock if there is unfortunate timing.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/edrosten/libblepp/issues/31#issuecomment-404082327, or mute the thread https://github.com/notifications/unsubscribe-auth/ABGW699JDrYBGOkQayv22DiiJKl8T76rks5uFbJPgaJpZM4VA3Ud .

Stretchdude commented 6 years ago

Sure, appended. Please tell me if I can try something. This is made with HEAD from your github. I could also provide a Wireshark trace from my bluetooth0 device if that is of any help (but no real BLE sniffer available). liblepp_trace_mtu_request_fail.txt EDIT: and I could catch one of the fails with my workaround (as in the patch above): liblepp_trace_mtu_workaround_fail.txt

Stretchdude commented 5 years ago

Hi, updates :-) I managed to find out, that libblepp is not even receiving some of the MTU requests. I think they may get thrown away by the kernel because connection is not ready to receive but the device is very quick with sending them. A sleep on the device side helped with the problem, but who wants to have a sleep as a fix? I don't know how to fix this without diggin into bluez kernel stuff. (and not diggin into bluez was the reason for me to search for libblepp ;-) I workarounded it now with sending just a denial always after connect. Also there is the change which handles MTU request in the state machine still active. Ugly but works for me. I guess this is a hack (again), so I don't think you like to have a pull request. Nevertheless I'll append a patch and push it to my own fork, after cleaning. If somebody has the same issue...

mtu_request_denial.patch.txt