I want to use USB-KW41Z with Wireshark to be BLE sniffer to get the data packets after BLE device connected.
But now just could get advertising data from advertising channels 37, 38, 39.
After device connected, the Wireshark can't get any data. How do I get the BLE data using sniffer after the BLE device connected?
are you using the BLE sniffer together with Wireshark plugin implemented in Protocol Analyzer Adapter for the sniffing only advertising channels ? Using this sniffer is possible only for sniffing advertising channels 37, 38, 39.
I checked the functionality for those channels and it's working well. What version of Wireshark are you using ?
Yes, I am using USB-KW41Z with wireshark to get the advertising data from davertising channels.
But I want to get the BLE data after connected.
Could you get data from other channels instead of 37, 38, 39 after the BLE device connected?
For example, I want to get the Heart Rate Sensor or thermometer data, and how?
using the Wireshark plugin allows only sniffing these three advertising channels. That means you are able to see advertising data when you start the Hear Rate sensor example application but after connecting is not possible to see any communication.
I think your answer might be missing some information. A quick look at your documentation located at: https://www.nxp.com/docs/en/user-guide/USBKW41ZUG.pdf reports "USB-KW41Z sniffer/development board is primarily targeted as a BLE or 802.15.4 sniffer." and further is "Fully compliant Bluetooth v4.2 Low Energy (BLE)". So I don't think the expected behavior is to be unable to sniff a BLE compliant connection.
Additionally, here is a screen shot of it sniffing other channels in Wireshark, but failing to follow the channel map after the first few hops of looking for connection events on channels that aren't in the map.
Somewhere in the USB-KW41Z firmware/protocol-adapter implementation there's a bug that prevents it from successfully following a channel map. I only found your thread while searching for "NOT Resolved! Serious Bug in BLE Sniffer Firmware. " looking for a delivery update for the firmware. But I think your issue might actually have be more related to my understanding that, given you have only one sniffer and depending on time required for a frequency change, you have less than a 1 in 3 chance of catching the CONNECT_REQ which contains the channel map that the connected devices will hop through during the connection.
If you don't catch that event, disconnect and then try, try again. Once the bug is fixed and you capture the connection, you should be able to follow more than the first few hops. (Once the bug is fixed, you could also run multiple sniffers so each advertising channel can be watched without frequency hopping.)