BLE HID sample fails to reconnect on Windows 10 tablets #12362
Comments
|
@pdunaj @Qbicz @jhn-nordic have you seen MIC failure when using HID as well? |
|
Hi @Olivier-ProGlove, we recently had some interoperability testing and there was indeed a problem with Surface Pro. Updating the Bluetooth drivers on Surface Pro helped a lot, and instead of failing most of the time it failed very rarely. I can later post an update what version of Surface it was. |
|
@Olivier-ProGlove I had similar and other problems with Surface Pro (2017 version). Marvell AVASTAR Bluetooth Radio Adapter Updating Bluetooth drivers solved them. Working drivers: Driver Date: 18/05/2018 Also updating Windows 10 from v10.0.16299 to v10.0.17134 helped with Bluetooth stability on this platform. |
|
Thanks a lot @Qbicz and @wiminordic for your valuable comments. I found a way to force update on Windows 10 Surface Pro 4 tablet. Until now, I was relying on Microsoft update mechanism. I noticed I could update Surface Pro drivers manually using this page: https://www.microsoft.com/en-us/download/details.aspx?id=49498 The tablet now uses OS Build 17763.195 (19/12/2018) and the Marvell AVASTAR driver 15.68.9125.57. I am still testing Zephyr Which version of Zephyr have you tested? |
|
The fw-nrfconnect-zephyr v1.13.99-ncs2 release: |
|
I made a quick retest with latest fw-nrfconnect-zephyr. |
|
@wiminordic @Qbicz so is this a Surface Pro issue? |
|
@carlescufi It is hard to say without detailed debugging. I have witnessed a lot of issues with Windows 10 platforms. Many of them were solved by updating drivers but not all of them (like this one). Windows 8 Surface 2 was getting BSOD on Bluetooth reconnection to Zephyr based HID device. So in general there is some instability there, but it could be caused by incorrect operation on Zephyr side. |
|
I made another retest with the zephyr from the fw-nrfconnect-zephyr v1.13.99-ncs2 release. Edit: Zephyr version seems to have no impact after all, latest is also sometimes working. |
|
Could it be the default 2 Mbit phy that causes issues? Just a wild guess, but that is a "new" feature
Få Outlook for Android<https://aka.ms/ghei36>
…________________________________
From: wiminordic <[email protected]>
Sent: Wednesday, January 9, 2019 4:15:47 PM
To: zephyrproject-rtos/zephyr
Cc: Nistad, Jon Helge; Mention
Subject: Re: [zephyrproject-rtos/zephyr] BLE HID sample fails to reconnect on Windows 10 tablets (#12362)
I made another retest with the zephyr from the fw-nrfconnect-zephyr v1.13.99-ncs2 release.
It seems to work better than latest fw-nrfconnect-zephyr. Issue was reproduced few times but at least several runs were successful (I was able to reconnect to Zephyr HID after it was reset).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#12362 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/Ai0HXAxW8hkp2o-eLgYvdu6gxYqGAX40ks5vBgejgaJpZM4Z0BUr>.
|
|
We have a BLE HID third-party commercial product that works well with the same Windows 10 Surface 4 Pro (using any version of the driver). The device can reconnect to Windows 10 Tablet without any issue. So it could also be a (legacy?) feature not supported by Zephyr or an advanced feature supported by Zephyr but not well supported by the Windows 10 driver. |
|
@carlescufi @wiminordic @jhn-nordic I have just tested So the issue is likely to be Zephyr specific. |
|
@Olivier-ProGlove maybe it would be helpful if you could reproduce with |
|
Thanks @carlescufi I added the two configuration settings Here are the logs for Android Samsung J5 (no problem on this Android Phone) and Microsoft Windows Surface Pro 4 (reconnection problem on this platform) |
|
@Olivier-ProGlove can you also enable |
|
@carlescufi Here are the log with ... Still nothing obvious. Last week I tried to dump more I am working on dumping the HCI commands/events on UART1 to see if I can see something (and avoid packet losing due to logging subsystem)... |
|
@Olivier-ProGlove what would be good is to print the LTK that is being stored in flash and then loaded and used with |
|
@carlescufi I don't see anything obvious in the logs. It'd be super helpful to get the HCI logs to see the exact content of the exchanged SMP PDUs. Is is possible Windows10 lacks the bonding flag, i.e. does no-bonding, but Soft Device ignores it and holds on to the LTK? |
|
@jhedberg but Windows 10 is the central, so why would it initiate encryption if it didn't have keys? |
|
@carlescufi my speculation/theory is that it does have the keys. It's just that it didn't set the bonding flag, which causes Zephyr to discard the keys. |
|
@Olivier-ProGlove could you re-run this against the Windows 10 tablet with the following patch applied: That should then help prove/disprove my bonding flag theory. |
|
No changes between Android and Window 10 Surface. I also printed the value of Full logs: I continue to work on my HCI dump. I will post it later today... Feel free to request me additional logs in the meantime. |
Ok, so we can disregard my no-bonding theory then. Next step would be the HCI logs. Anyone know the link to the documentation page the explains how to enable this? On a high-level you need to disable the stdout console and CONFIG_BT_DEBUG_LOG, enable CONFIG_BT_DEBUG_MONITOR, and then on the Linux PC side you need to use "btmon --tty /dev/ttyACM0" (or whatever is your Zephyr console) to capture the logs. |
|
What I am doing for HCi dump is to redirect HCI sent/receive/acl commands (printed in hexadecimal) on the second UART of Nordic Dev Kit. It works fine. I am doing a basic formatting to help you and I am done to send you the logs. What I have at the moment is something like that: Is it good enough? |
|
@jhedberg Here are the logs and HCI logs for Android and Windows 10 Surface Pro Tablet: Android.log Note: The hexadecimal after the opcode is the data (without the size). |
|
@jhedberg I had a look to BT_DEBUG_MONITOR and got it working. Usual logs: |
|
The latest logs do confirm the MIC failure: However, I don't see anything wrong with this on our side - the LTK value is the same that was successfully used for the first connection: |
|
We have another device that does dual boot Android and Windows 10 (CHUWI Hi10 Pro) that has a similar issue (ie: Works fine for Android but MIC Failure on reconnection with Windows 10). Here are the logs for this platform: Something I already noticed for the previous case (Samsung Android phone and Windows 10 Tablet) and I noticed again with the Chuwi tablet: On Android it uses a Random Peer Address type: While on Windows 10, it always uses a Public Peer Address type: |
|
@jhedberg more logs. As I mentioned in my initial issue message when using the USB ASUS BT-400 controller on the Windows Surface Pro 4 (the Windows10 Tablet that fails the reconnection test) I can successfully connect. Here are the btmon log for the USB ASUS BT-400 controller on the Windows Surface Pro 4: The observation I made in my previous message is not valid anymore. The ASUS BT-400 also uses a public address: When comparing the btmon log between the default bluetooth controller and the ASUS one on the same tablet, I can see these two commands being sent during pairing with the default controller while there are not sent for the ASUS controller:
|
|
Something else Could it be Zephyr do not update the encryption algorithms on the reconnection? |
|
@carlescufi @jhedberg I am still looking at this issue and pushing towards this issue is due to the 'missing' I printed the values of: after the first pairing and the failing reconnection.
Could the fact Zephyr do not not 'restore' the previous security level and encryption status be the reason of the I tried to add a dirty hack to workaround this 'missing' I added this code to I booted a first time without this hack for pairing the device and then enable this hack and flash the firmware to see if it fixed my issue. I could confirm it switched to Any comment on the 'missing' |
|
@Olivier-ProGlove can you provide a trace of it working as expected and one failing. Your air traces collected while Windows traces are also recording would help us analyze and provide recommendations to you. |
|
Thanks a lot @FrankGorgenyi for jumping in this thread 😃 😃 😃 I actually think I found the issue this afternoon (German time). I will try to get more information tomorrow to know exactly if it a Zephyr issue or a Surface Pro Bluetooth controller issue. But it is likely that the issue (if my theory is confirmed) could be mitigated by the Surface Pro Bluetooth controller. Here is the
From what I observed, Zephyr Link Layer ( I noticed Zephyr has a My next step is too check the timing to know if it is Zephyr who cannot cope with the controller BLE intervals or if it is the Surface Pro controller that does not respect the timings (ie: timeout too early). A mitigation would be to negociate the interval before Few connection parameters on reconnection (before being renegociated):
You could notice Chuwi in Windows mode (dual boot table) uses the same parameters as the MS Surface Pro bluetooth controller. I also noticed when I use the ASUS USB BT-400 controller on the MS Surface Pro I also have the same connection interval. But Nordic's nRF52840 dev kit with Zephyr can successfully connect on the Surface Pro with the ASUS USB BT-400 controller while it cannot with SurfacePro controller and Chuwi controller in Windows mode. I am quite keen to try the Windows Bluetooth trace tool (first time I hear about it). And from what I understand I can capture radio info too 👍 |
|
More data/timing on latest Zephyr ( Here are the results of my testing on few devices: WindowsSurfacePro
WindowsSurfacePro + ASUS BT-400
Samsung J5 Android Phone
Chuwi Android
Chuwi Windows
Windows TraceHere are the Windows Trace you asked me:
|
|
Command disallowed to an LTK Request Response. Any clues? |
|
@cvinayak @joerchan could you take a look at the Wireshark traces? |
|
@joerchan suggests the issue might be that:
The issue seems to be that the master should respond to the feature request first and then send the encryption request, so it looks like a bug in the Windows tablet controller.
|
|
"If at any time during the encryption start procedure, the Link Layer of the You can see in the HCI log that there is a disconnect event with this error code. So that confirms the behaviour of the slave. |
Some old peer central controllers respond with Unknown Response PDU to our local Slave Initiated Feature Request after the peer initiated the Encryption Setup Procedure. The peer has voilated the Bluetooth Specification by sending the Unknown Response during the Encryption Setup Procedure, but as a workaround to IOP with such controller our local implementation is updated to not disconnect the connection but accept the voilating Unknown Response PDU. Relates to zephyrproject-rtos#12362. Signed-off-by: Vinayak Kariappa Chettimada <[email protected]>
Some old peer central controllers respond with Unknown Response PDU to our local Slave Initiated Feature Request after the peer initiated the Encryption Setup Procedure. The peer has voilated the Bluetooth Specification by sending the Unknown Response during the Encryption Setup Procedure, but as a workaround to IOP with such controller our local implementation is updated to not disconnect the connection but accept the voilating Unknown Response PDU. Relates to #12362. Signed-off-by: Vinayak Kariappa Chettimada <[email protected]>
|
I took me a while to get the right trace. To be short, while it seems to work much better there might still be an issue. Environment of test:
Here are the log files: 2ndReconnectionFail.zip
Here are part of the logs for the respective reconnection: First reconnection (successful)
Second reconnection (fail with MIC Failure)
I will redo btmon+sniffer traces with |
|
Here are the traces (logs+btmon+sniffer) of the same settings +
|
|
Follow up on this still existing issue in this new ticket with more information: #14044 |
Describe the bug
BLE HID sample fails to reconnect on (some?) Windows 10 tablets. I only have two Windows 10 tablets (including the Windows Surface Pro 4) to check. I cannot duplicate the issue on a Windows 10 laptop (Lenovo laptop in my case), Linux and Android.
The two bluetooth controllers are (Windows 10 says I am using the latest drivers):
The Surface Pro has USB slots. Connecting the ASUS BT-400 USB controller on the Surface Pro makes the BLE reconnection successful.
I only tested with Nordic nRF52 MCUs (particularly nRF52840) as a BLE peripheral.
To Reproduce
Expected behavior
Windows 10 should automatically reconnect to the dev kit as it advertises on restart
I tested on Zephyr (from 4 days ago):
I added logging traces in the bluetooth controller to get an idea of the issue:
And here is the result:
I used the Nordic sniffer to try to get some insights. Here are the few Wireshark traces I manage to get:
Windows10TabletIssue-Wireshark.zip
The text was updated successfully, but these errors were encountered: