NOT Resolved! Serious Bug in BLE Sniffer Firmware.

[philbeeson]

I've been posting on this forum for a few weeks now to try and get help with sniffing a BLE connection and getting nowhere.  It seems the majority of folks out there are using KW41Z for 802.15.4.

However I've now identified the issue and conclude that the USB-KW41Z with it's current firmware has a fundamental flaw.

To assist in identifying the problem,  I set up the a BLE peripheral configured to advertise on only channel 37 and used Nordic Semiconductor's nRF Connect Android app.  I set up 2 sniffers simultaneously, both using Wireshark 2.4.0.  One sniffer was the USB-KW41Z with the protocol analyser adapter V1.2.6  the other was a Nordic Semiconductor nRF51 dongle with their sniffer version 1.0.1.   Both sniffers were configured to sniff channel 37 only so the connection event would not be missed.

Both capture files are attached.  Note that the Nordic dissector is included in Wireshark 2.4.0 - to get nordic encapsulation decoding working:
    go to edit->preferences->protocols->DLT_USER
    edit the encapsulation table and add "user10 (DLT=157)" with "nordic_ble" in payload protocol field.

Each file contains a single connection event.  That connection event specifies a channel map of [0, 1, 2, 3, 4, 5, 6, 28, 29, 30, 31, 32, 33, 34, 35, 36] and a hop value of 15.   Note that Wireshark currently has a bug in the BLE dissector that incorrectly decodes the Hop and Slave Clock Accuracy field (See wireshark bug 13990).

Looking first at the sniffer capture the channels selected for each connection interval are as follows:

Nordic: 36, 30, 29, 28,  1,  0, 31, 30, 29,  2,  1, 32, 31, 30,  3,  2, 33, 32
NXP:    15, 30,  8, 23,  1, 16, 31,  9, 24,  2, 17, 32, 10, 25,  3, 18, 33, 11

It can be seen that the NXP channel hopping pattern is selecting channels that are not valid as they are not included in the channel map specified in the connection event. 

What the NXP sniffer is doing is calculating the next channel as (last_channel + hop) % 37.   THIS IS WRONG!!!!!

The correct algorithm for selecting the next channel is given in the Bluetooth core specification V4.2 Volume 6 Part B Section 4.5.8.2.  
IF the result of (last_channel + hop) % 37 is a channel that is not specified in the channel map, then it has to be remapped to one that is.

This is simply not being done with the NXP sniffer - thus unless all channels are included in the channel map, the NXP sniffer cannot work for following BLE connections.

Having identified the problem, I hope that NXP can provide a fixed version of the sniffer firmware ASAP. 

Original Attachment has been moved to: t802_connect1_kw41z.pcapng.zip

Original Attachment has been moved to: t802_connect1_nrf51.pcapng.zip

[philbeeson]

Just in case anyone is following this,  the Wireshark bug I referred to above (Hop and Sleep clock accuracy decoding) has been fixed in release 2.4.1.      Big thanks to the Wireshark team for getting the fix into the codebase so quickly.

Now, NXP,  any chance we could get that sort of response speed to issues in your software\firmware?

estephania_martinez‌,  any news from your engineering team yet?

[philbeeson]

One month since I raised this problem and no response from NXP, no confirmation (or denial) that the bug exists nor any suggestion that there's a fix on the horizon.

To say I'm disappointed would be an understatement,  to express my real feelings would be a violation of the terms and conditions of the forum. 

 estephania_martinez, you were going to refer my concerns to the engineering team, what did they say?

[estephania_mart]

Hello, 

 I'm sorry for the late response I can understand how you are feeling right now.

The issue has been solved but they are working now on how and when is it going to be delivered.

Sorry for the inconvenience this might cause you. 

Best Regards, 

Estephania 

[philbeeson]

So here we are, pretty much one month on from when I was told the problem is fixed - and still no fix has been released.

Very disappointing, so unresponsive.

NXP really shouldn't be selling the USB-KW41Z as a bluetooth sniffer - it just does't (yet) do the job.

[estephania_mart]

The new sniffer code will be released on the next KW41Z maintenance release planned for Dec 7th.

[philbeeson]

It's now Dec 12th, I've just gone to download the latest KW41Z connectivity software from this page:

USB-KW41Z|Wireless Packet Sniffer|NXP 

And guess what, it's still the same 2016 version with the sniffer bug.  So what happened to the Dec 7th release?

4 Months since I reported the issue, 3 months since Estephania reported that it had been fixed and was just awaiting release and still no solution to a bug, that quite honestly should be an embarrassment to NXP.

[zabto]

This looks fixed in the 1/21/2018 build of the sniffer binaries; Make sure you get the most up to date ones as it's easy to download an archived version that still has the 08/xx/2017 binaries in .\tools\wireless\binaries.

[estephania_mart]

Hello, 

Sorry Phillip the maintenance release got a delay as they are more fixes that needed to be added.

I'm really sorry for the inconvenience, I'll comment here when the release it's available. 

Best Regards, 

Estephania 

[chetkaufman]

Estephania,

The SDK for USB-KW41Z was updated online on January 19^th.  An example directory structure below shows you where the pre-built binaries are loaded, including the sniffer versions at the bottom.   Can you confirm this new update solves the BLE sniffer issue detailed in this thread?

[philbeeson]

estephania_martinez‌  Is there any update on a release of this fix yet?   Is there any way I can get a pre-release beta?  This is going on way too long!

Regards,

Phil Beeson.

[philbeeson]

Any news on a release date for the fix yet?

[philbeeson]

Hi Estephania,

Thank you for the progress update.

I hope the firmware update comes soon in a new release of the MKW41Z_Connectivity_Software package which includes the binaries for the sniffer to allow us to update our sniffers as soon as possible.

Regards,

Phil Beeson.

[philbeeson]

estephania_martinez‌, aleguzman‌  - It would be really nice to know if anyone has looked at this and if my findings have been verified.