This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

BLE sniffer limited to 65535 packets?

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?

Parents
  • @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 ?

Reply
  • @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 ?

Children
No Data
Related