Problems following BLE connection

cancel
Showing results for 
Search instead for 
Did you mean: 

Problems following BLE connection

743 Views
philbeeson
Contributor III

I'm trying to use the USB-KW41Z dongle to sniff a simple BLE 4.1 connection.   The advertising frames and scan request\response frames are captured and decoded with no problems.  However, when I capture a connect request, the sniffer seems unable to follow the connection.  Sometimes it immediately fails, with the frame immediately following the request being [mis] identified as a 285 byte L2Cap fragment, other times there are a few frames decoded and others not and then the packet capture stops, even though I can see the devices are still maintaining the connection.

 

I've attached a couple of capture files in case anyone more familiar with this than me can figure out what's going on. The connect_capture_kw41z is an immediate fail on the frame following the connect request

The kw41z_fail is an example of a partial capture before failure. 

 

I both cases I see decodes in the Kietis Adapter Information disector output that indicates the channel number being one that wasn't included in the channel map of the connection request, and also incorrect access address in the BLE link layer decode, so I'm assuming the data from the dongle is mis-decoded and/or the output of the dongle is junk.

 

I've tried this with a Nordic semiconductor sniffer and I can capture all the packets no problem, but I ultimately want to use the KW41Z to sniff BLE 4.2 with an extended MTU  (Data Length Extensions).

 

Does anyone have any suggestions ?

 

Win7 64bit

Kinetis Protocol Analyzer Adapter v1.2.4.0

Wireshark 2.2.7

 

Thanks,

Phil.

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

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

Labels (2)
0 Kudos
3 Replies

138 Views
estephania_mart
NXP TechSupport
NXP TechSupport

Hello, 

Ok,  I checked both files and I see the issue you are having .

Could you plase tell me the steps you are following so I can reproduce it as I have not been able to do so. ? 

Regards, 

Estephania 

0 Kudos

138 Views
philbeeson
Contributor III

Hi Estephania,

Any update on this yet?  I've still not managed to successfully follow a BLE connection.

Regards Phil

0 Kudos

138 Views
philbeeson
Contributor III

Hi Estephania,

I installed wireshark  2.2.7, the current download at the time

Installed the protocol analyzer adapter following the instructions.

Launched the adapter

Select All for the advertising channels, no address filter selected and hopping interval left at default

kinetisprotocoladapter1.jpg

Launched wireshark.

Selected the virtual pcap if (local area connection 7)

Start the device advertising.

Advertising frames are captured and decoded OK.

I then initiate a connect request from my phone, to try to capture the connection.   Obviously with only 1 sniffer I don't capture this every time, so if I don't see the connect and just see advertising stop, the connection occurred on a different advertising channel so I disconnect and try again.

I've tried this on 2 different PCs (one win7pro x64 and one win10pro x64),  I've used 3 different peripheral devices (TI sensor tag,  Nordic Thingy & my own development board),  I've tried 2 different USB-KW41Z dongles, 2 centrals - android phone & nordic dev board running central role and I see much the same thing every time.

I typically see a capture like this one from the TI sensor tag (capture file ti_tag.pcap):

ti_tag.jpg

In all the cases I've seen, the hop value in the connect request has a value of 1, this is regardless of device (TI or Nordic stacks), so I wonder if there's an issue decoding this since the core spec requires this to be a random value between 5 & 16.  Also in this capture the channel map only includes 2 advertising channels, I don't have enough experience with the sensor tag to determine if this is normal for the tag.   With other devices, I see a valid channel map, a hop value of 1, and on occasion when I see some fragments of the connection decoded (as in the original message in this thread),  I seem see the decoded data from the kinetis adapter header indicating that the channel being sniffed is not one of those that was in the channel map (assuming I'm not misinterpreting the data).

Thanks for your continuing help with this.

0 Kudos