KW41Z sniffer dongle question

[alftel]

Hello,

I am evaluating KW41Z sniffer dongle kit, and while it does work as expected, BTLE sniffer via Kinetis Protocol Analyzer Adapter is written such a way that it allows sniff only on advertising channels 37,38, and 39. I need to see how it will be able to sniff on the rest of the channels (1 to 36). Is it any (easy) way I can accomplish this? Also, I need to understand if this is just a way Kinetis Protocol Analyzer was written , or it is chip inability to listen to channel of choice in promiscuous mode?

Cheers,

Alex

[alftel]

Hello Florin,

Regarding your statement "NXP offers a sniffer solution for BLE" - can you please elaborate on this a bit? Except KW41Z I didn't see any potential candidate that were able to do this (well, except older TI part). We are well aware about frequency hoping and implications and know how to deal with it - all we needed was a 1MHz channel promiscuous sniffer and we would've take it from here. I guess it was another hope lost - back to SDR.

Cheers,

Alex

[bobgarrow]

Florin....the question was for you and you've answered it clearly.   Thx.

Cheers,

Bob G.

[bobgarrow]

Alex, Florin....

1. Like Alex, I was expecting that the KW41Z with the appropriate NXP software would support the BLE promiscuous mode.   It looks like Florin is saying that it does NOT support that mode.   Is that correct?

[florintoma]

Hello Bob,

NXP offers a sniffer solution for BLE. As BLE is a channel hopping protocol there's no direct use case for such functionality other than custom solutions. I'm not sure for whom is the question but as I was saying KW41Z can not have promiscuous mode for BLE.

Best regards,

Florin

[alftel]

Hello Carlos,

I think you deviate from the main question that we asked - to explain promiscuous bit functionality as it outlined briefly in User Manual/Guide on pages #1439 and #1454, and which directly refers to mode in question, and has nothing to do with Access Address as far as I can see/understand. The only note made there is that frame length check is bypassed. It also explicitly said "all packet filtering", which means that it is not a noise, and only frame length is bypassed. Please correct me if I am wrong - I am just reading your User Guide.  Can you re-confirm statements on pages mentioned and explain functionality behind this ? i.e. "44.2.3.3.3 PHY CONTROL (PHY_CTRL), offset 25, PROMISCUOUS, "1b - all packet filtering except frame length checking (FrameLength >=5 and FrameLength <=127) is bypassed."

This is very direct question.

[florintoma]

Hello Alexander,

There's no Promiscuous mode supported on BLE Link Layer. The bit you are looking at is for the 802.15.4 Link Layer. The chapter 44.2.3.3 is for ZLL (ZigBee Link Layer) Register Description.

ZLL indeed has a promiscuous mode but it is not useful for BLE.

As Carlos said, you may try to use the GenFSK Link Layer, set a NETWORK_ADDRESS of 1byte and a Network Address Threshold of 8 bits (to tolerate 8bits of error) but you will end up having a lot of noise which will false trigger packets detection.

Best regards,

Florin

[alftel]

Carlos,

What you explained is not promiscuous mode, since requires explicit device address, and what we asked was promiscuous mode as it stated on page #1439, BLUETOOTH LOW ENERGY MISCELLANEOUS CONTROL
(MISC_CTRL), 44.2.3.3.3 PHY CONTROL (PHY_CTRL), offset 25, PROMISCUOUS, "1b - all packet filtering except frame length checking (FrameLength >=5 and FrameLength <=127) is bypassed.", and page #1454, RECEIVE FRAME FILTER, offset 14, "1b - Provide Data Indication on all received packets under the same rules which apply in PROMISCUOUS mode.

This is what we asked confirmation about. I already escalated this question through Arrow, but it will be nice to have an answer directly from you.

On a software side, as long as we will have an access to registers via KW41Z Connectivity Software, we should be fine. BTW - sources for sniffer and not being able to provide - NXP is in a hardware business, why all of a sudden this "Broadcom" behavior? Who informed you about it? Is it an official response, or should I still try to reach NXP folks that we met at RSA 2017 in San-Francisco, and who assured us that everything is available (I believe it was your Global Segment Marketing Manager).

Cheers. 

[carlos_neri]

Alex,

Here's some feedback on the promiscuous mode:

"The only possible way to scan only one specific Data channel is to know the Access Address. KW41Z must have a sync address and from previous tests a sync address smaller than 3 bytes will cause a lot of noise to false trigger as packets. Which means that if we set a sync address of 1 byte and 8 bits of tolerated error on that one, it will still fail because it will trigger a lot of receptions on noise and not on packets."

Previously you said that site survey is one of the use cases you're looking for. For this purpose, probably getting RSSi on the specific channel is required. Besides the method I've provided before that would require an access address, you could also get the current RSSI the transceiver is measuring with the following API:

XcvrFskGetInstantRssi()

What else do you require for the site survey? 

Regarding the source code, I'd recommend you to follow up with your Arrow or NXP FAE so they make the request.

[alftel]

Common guys, anybody from NXP? It's your product, question is straight forward and refers to your own user guide. Any references to resources who can answer this? Anybody? I met with NXP reps at RSA 2017 in San Francisco and was assured that forum is assigned to knowledgeable employees - where are you guys?

[carlos_neri]

I've talked with SW and HW guys and they recommended using GFSK mode on KW41Z configuring the packet as BLE with the same access address you would use in connect state or any address you know will be available (connectivity_test_genfsk configures the packet in a similar way but with access address 0x8E89BED6) and configure the channel you want to survey based on the GFSK channel map:

F = 2360 + Channel

For instance, to use data BLE data channel 20 (2.446Ghz) you'll need to set up GFSK channel 86.

Regarding the sources for the sniffer (Firmware and PC tool) I was informed that we don't disclose them.

[alftel]

Hello Carlos,

It's been a while since my follow-up question. Information provided in User Guide brings an impression that promiscuous mode is supported. Can you please answer my previous posting or at least refer us to right resources at NXP that will be able to confirm/deny User Guide statements? It is a really simple question for engineer who designed the silicon.

Cheers,

Alex

[alftel]

Hello Carlos, thanks again for the timely response. We do understand that Kinetis Protocol Analyzer software does not support this feature (by simply not allowing to tune to channels other then 37,38,39 in BTLE sniffer mode), and probably sniffer software is not tuned to do this either. Our question was more along the line like - does chip support promiscuous mode fo channels 1-36? User manual, even though not referring to this explicitly verbatim, has (looks like) corresponding registers to accomplish this (see my previous references). Since part is a relatively new offering, it could've be a typo as well. We are designers of wireless security appliances, and a reason why do we need this is very simple - to accomplish a full band sweep for the dynamic wireless site survey. Right now we perform it in WiFi domain, but would like to add BTLE and Zigbee as well. So, here you go:

1) Does WK41Z, as silicon design goes, support promiscuous RX on BTLE channels 1-36? (as per User Guide)

2) How one can tune/change/modify Kinetis Protocol Analyzer and sniffer software to accomplish this for try-out?

3) Where we can get Kinetis Protocol Analyzer and sniffer firmware source code?

Best regards,

Alexander

[alftel]

Hello Carlos,

Thanks for the reply. Following connection is not what we were looking for (this one is easy, and any BT chip can do this) - we are after promiscuous mode on a channel, similar to what TI CC5240 has, or similar to what KW41Z has for 802.15.4 Packet Processor (page #2086 "Supports “Promiscuous” mode, to receive all packets regardless of address- and
rules-checking"). On the other hand, we see on page #1439, BLUETOOTH LOW ENERGY MISCELLANEOUS CONTROL
(MISC_CTRL), 44.2.3.3.3 PHY CONTROL (PHY_CTRL), offset 25, PROMISCUOUS, "1b - all packet filtering except frame length checking (FrameLength >=5 and FrameLength <=127) is bypassed.", and page #1454, RECEIVE FRAME FILTER, offset 14, "1b - Provide Data Indication on all received packets under the same rules which apply in PROMISCUOUS mode, however acknowledge those packets under rules which apply in non-PROMISCUOUS mode". I read it like exactly what we are looking for - can you please confirm it?

Cheers,

Alex

[carlos_neri]

Just received confirmation that neither the firmware nor the Kinetis Protocol Analyzer have the feature you are looking for. Is there a chance you share an insight of why you need such feature?

[carlos_neri]

The KW41Z sniffer is able to follow the BLE connection when the CONN_REQ is received. To achieve this, you must start sniffing the ADV channels.

Section 4.1 of USB-KW41Z Wireless Protocol Sniffer Quick Start Guide.pdf provides information on the sniffer usage for BLE.