Anonymous advertising packets in long nRF52840 BLE sniffer sessions cause device/MAC address filtering to fail

[kp88]

Wireshark Version 4.6.2
nrf_sniffer_for_bluetooth_le_4.1.1

I am trying to capture packets from a long BLE session using Wireshark and the nRF52840 BLE sniffer. Most times this works great and has been super helpful to development and debugging. However, while recently debugging connections between the target embedded peripheral and an Android host, I found the sniffer is also tracing "anonymous" extended advertising packets coming from the Android host despite explicitly setting the device/MAC address filtering.

I understand that I can filter out the extended advertising packets with a display filter but I am finding that eventually (after a few hours of continuous capture), peripheral specific packets are no longer captured even though for sure there is on-going traffic.  I don't understand the root cause of this bug but I can say that tracing long sessions with other hosts that don't continuously send extended advertising packets has worked well.   In other words, the anonymous extended advertising packets appear to "overrun" and/or cause MAC address filtering to fail.  

Is there any way to exclude the extended advertising packets from the initial capture?

Below is what a typical session looks like with the device filter set to "00:18:80:ff:9e:b1 public".  

What starts with:

No.	Time	Source	Destination	Protocol	Length	Info
1141	26.599660	Anonymous	ff:ff:ff:ff:ff:ff	LE LL	33	ADV_EXT_IND
1142	26.600001	Anonymous	ff:ff:ff:ff:ff:ff	LE LL	33	ADV_EXT_IND
1143	26.669038	00:18:80:ff:9e:b1	ff:ff:ff:ff:ff:ff	LE LL	60	ADV_IND
1144	26.669540	46:48:40:fd:1c:bf	00:18:80:ff:9e:b1	LE LL	38	SCAN_REQ
1145	26.669866	00:18:80:ff:9e:b1	ff:ff:ff:ff:ff:ff	LE LL	57	SCAN_RSP
1146	26.670687	00:18:80:ff:9e:b1	ff:ff:ff:ff:ff:ff	LE LL	60	ADV_IND
1147	26.671769	00:18:80:ff:9e:b1	ff:ff:ff:ff:ff:ff	LE LL	60	ADV_IND
1148	26.864814	00:18:80:ff:9e:b1	ff:ff:ff:ff:ff:ff	LE LL	60	ADV_IND
1149	26.865897	00:18:80:ff:9e:b1	ff:ff:ff:ff:ff:ff	LE LL	60	ADV_IND
1150	26.866979	00:18:80:ff:9e:b1	ff:ff:ff:ff:ff:ff	LE LL	60	ADV_IND
1151	26.953076	Anonymous	ff:ff:ff:ff:ff:ff	LE LL	33	ADV_EXT_IND
1152	26.953417	Anonymous	ff:ff:ff:ff:ff:ff	LE LL	33	ADV_EXT_IND
1153	26.953757	Anonymous	ff:ff:ff:ff:ff:ff	LE LL	33	ADV_EXT_IND
1154	27.056839	00:18:80:ff:9e:b1	ff:ff:ff:ff:ff:ff	LE LL	60	ADV_IND
1155	27.057922	00:18:80:ff:9e:b1	ff:ff:ff:ff:ff:ff	LE LL	60	ADV_IND
1156	27.058424	46:48:40:fd:1c:bf	00:18:80:ff:9e:b1	LE LL	60	CONNECT_IND
1157	27.090578	Central_...	Peripheral_...	LE LL	35	Control Opcode: LL_FEATURE_REQ
1158	27.090880	Peripheral_...	Central_...	LE LL	35	Control Opcode: LL_LENGTH_REQ
1159	27.135579	Central_...	Peripheral_...	LE LL	35	Control Opcode: LL_LENGTH_RSP
1160	27.135881	Peripheral_...	Central_...	LE LL	35	Control Opcode: LL_FEATURE_RSP

eventually ends up with nothing but this:

No.	Time	Source	Destination	Protocol	Length	Info
80709	7872.118853	Anonymous	ff:ff:ff:ff:ff:ff	LE LL	33	ADV_EXT_IND
80710	7872.403175	Anonymous	ff:ff:ff:ff:ff:ff	LE LL	33	ADV_EXT_IND
80711	7872.403516	Anonymous	ff:ff:ff:ff:ff:ff	LE LL	33	ADV_EXT_IND
80712	7872.403857	Anonymous	ff:ff:ff:ff:ff:ff	LE LL	33	ADV_EXT_IND
80713	7872.689428	Anonymous	ff:ff:ff:ff:ff:ff	LE LL	33	ADV_EXT_IND
80714	7872.689769	Anonymous	ff:ff:ff:ff:ff:ff	LE LL	33	ADV_EXT_IND
80715	7872.690110	Anonymous	ff:ff:ff:ff:ff:ff	LE LL	33	ADV_EXT_IND
80716	7872.979432	Anonymous	ff:ff:ff:ff:ff:ff	LE LL	33	ADV_EXT_IND
80717	7872.979773	Anonymous	ff:ff:ff:ff:ff:ff	LE LL	33	ADV_EXT_IND
80718	7872.980114	Anonymous	ff:ff:ff:ff:ff:ff	LE LL	33	ADV_EXT_IND
80719	7873.266937	Anonymous	ff:ff:ff:ff:ff:ff	LE LL	33	ADV_EXT_IND
80720	7873.267278	Anonymous	ff:ff:ff:ff:ff:ff	LE LL	33	ADV_EXT_IND
80721	7873.267619	Anonymous	ff:ff:ff:ff:ff:ff	LE LL	33	ADV_EXT_IND

Thanks in advance for any suggestions.

Kevin

[tesc]

Hi,

Based on the limited number of log lines that you provided, it does look like the rate of "Anonymous" transmissions stays the same, but after a couple of hours all other transmissions are missing from the sniffer trace? Will they reappear if you restart the sniffing, and what would be the steps to reproduce the issue?

Regards,
Terje

[kp88]

Hi, thank you for the reply!

Yes, stopping and starting Wireshark capture and resetting the device/MAC address capture filter will restore functionality for a while but it eventually ends up in the same state.  And yes, in this state all packets from normal peripheral advertising and host-peripheral connections are missing.

Would a full .pcapng log be helpful?

As for reproducing the issue, it is currently tied up in my test environment running a Samsung/Android host against an ADI/MAX32666FTHR peripheral, so not super easy to recreate.  The basic structure consists of running 100s of repeats of 20s connections between the host and peripheral where each connection consists of periodic (1 second) notifications from the peripheral.  I have confirmed that the anonymous extended advertising packets are coming from the Samsung/Android host but I don't understand which application/service is sending them.  My guess is something related to Android's mechanism for device discovery.

I could work to pair down the test env to something simpler if that would be helpful, e.g. using nRF52840 dongles all the way around, but that will take a little time.