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
  • Yes, the Wireshark also stopped (without any message - so I looked it up in the logfile). I did some additional testing: 65535 is not a problem "in general". The problem only occurs when all data is produced within one connected session. (We use a 10ms connection intervall with data transmitted every interval - so we reach 0xFFFF packets within under 5 minutes.) When I cut the connection within the 65535 packets and re-connect, more than 65536 packets will be displayed in Wireshark (though the problem will occur later if the transmission continues within the same connection).

Reply
  • Yes, the Wireshark also stopped (without any message - so I looked it up in the logfile). I did some additional testing: 65535 is not a problem "in general". The problem only occurs when all data is produced within one connected session. (We use a 10ms connection intervall with data transmitted every interval - so we reach 0xFFFF packets within under 5 minutes.) When I cut the connection within the 65535 packets and re-connect, more than 65536 packets will be displayed in Wireshark (though the problem will occur later if the transmission continues within the same connection).

Children
No Data
Related