BLE sniffer limited to 65535 packets?

[Karl-E.]

Hi! I'm using the nRF Sniffer software (Windows 1.0.1 Rel.1111) with nRF51-DK Board (Rev. 1.1.0) and Wireshark (1.12.5). Everything works fine until the number of 65535 (0xFFFF) captured packets is reached. In the log.txt lost packets are reported before reaching "the end" than transmission stops with several "INFO: UART read timeout (2 seconds)." messages.

Exerpt from log:

12-Jun-2015 11:40:45 ERROR: Invalid packet: packet list not valid: [6, 41, 1, 155, 206, 6, 10, 1, 31, 79, 74, 102, 150, 0, 0, 0, 103, 50, 173, 222, 10, 21, 0, 17, 0, 4, 0, 29, 41, 0, 170, 33, 0, 0, 0, 158, 0, 0, 0, 10, 21, 0, 17, 0, 4, 0, 29, 41, 0, 170, 33, 0, 0, 0, 160, 0, 0, 0, 0, 54, 90, 14, 0, 177, 138, 37]
12-Jun-2015 11:40:45 INFO: gap in packets, between 52890 and 52900 packet before: [6, 19, 1, 154, 206, 6, 10, 11, 31, 46, 74, 102, 179, 37, 0, 0, 103, 50, 173, 222, 13, 0, 165, 65, 70] packet after: [6, 24, 1, 164, 206, 6, 10, 3, 22, 45, 79, 102, 50, 37, 0, 0, 103, 50, 173, 222, 2, 5, 1, 0, 4, 0, 30, 45, 137, 144]
12-Jun-2015 11:41:48 INFO: gap in packets, between 65535 and 0 packet before: [6, 19, 1, 255, 255, 6, 10, 11, 15, 46, 2, 127, 178, 37, 0, 0, 103, 50, 173, 222, 13, 0, 165, 65, 70] packet after: [6, 40, 1, 0, 0, 6, 10, 1, 15, 63, 2, 127, 150, 0, 0, 0, 103, 50, 173, 222, 10, 21, 17, 0, 4, 0, 29, 41, 0, 170, 33, 0, 0, 0, 250, 0, 0, 0, 0, 62, 81, 15, 0, 78, 72, 211]
12-Jun-2015 11:41:53  INFO: UART read timeout (2 seconds).
12-Jun-2015 11:41:55  INFO: UART read timeout (2 seconds).
12-Jun-2015 11:41:57  INFO: UART read timeout (2 seconds).   

[...and so on...]

Tested on different computers (all Windows 7) and different USB-Ports. Same results.

Is this a limitation in soft- or hardware or just a bug that might be fixed?

[Karl-E.]

Hi! As I mentioned, I already did that v1.10 test - without success. Regarding the number of packets: I suspect that only packets within the connection count. There are also advertising packets and lost packets (see log) - so the counter stops somewhere above 65xxx. I even tried a connection which I stopped at around 32000 packets. Then re-connected and about 65xxx packets later the protocol stopped...

[Hung Bui]

@Karl-E: Sorry that I missed that part that you tried with Wireshark v1.10 already. There was only 20 advertising packets, and I believe we only count the packets we received. So still it's pretty strange number.

Which central device did you use for testing ? Could you update another trace ? In your trace I saw that the last packet from the central was a channel map update. If this appear to be the same on other trace then it could tell something.

I assume that the connection was kept, independent of the issue on the sniffer ?

[Karl-E.]

I use custom devices based on the Alpwise BLE Stack. I'm not able to do another trace in the moment, but I remember the channel map update event being the last event in a former trace. And yes, the connection is kept.

[Hung Bui]

I would suggest you next time to try with a phone, Android or iOS and also with our nRFMaster Control Panel on PC.

In the log on my PC here I am seeing the same info report

16-Jun-2015 13:28:17 (W. Europe Daylight Time) INFO: gap in packets, between 65535 and 0 packet before: [6, 19, 1, 255, 255, 6, 10, 11, 31, 43, 142, 248, 21, 28, 0, 0, 165, 67, 101, 80, 1, 0, 41, 242, 246] packet after: [6, 19, 1, 0, 0, 6, 10, 9, 31, 43, 142, 248, 151, 0, 0, 0, 165, 67, 101, 80, 5, 0, 250, 244, 246]

But the sniffer managed to follow the connection with no issue.

[Kai Harrekilde]

@Hung Bui: I'm also seeing this issue (UART read timeout). nRF51-Dongle (PCA10031) module with the 1.0.1_1111 sniffer software. I programmed the unofficial SNIFF150 FW that you posted here, but I still get this issue.