AnsweredAssumed Answered

NOT Resolved! Serious Bug in BLE Sniffer Firmware. 

Question asked by Phillip Beeson on Aug 19, 2017
Latest reply on Mar 12, 2018 by Jeff Skaanland

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  
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:

Original Attachment has been moved to: