Add option to report packets with CRC error about sniffle HOT 10 CLOSED

Sorry I missed your report earlier, I think reporting of CRC errors or showing the captured CRC could be a useful addition.

Regarding the connection following failure, the other reason it can miss some connection attempts is variability in advertiser hop timing due to scan requests. It's a bit tricky for me to alter the hop timing from 37->38->39 due to latencies in packets getting from the radio core to the main processor, though I still want to look into ways to improve this.

from sniffle.

Commit 15ba641 will hopefully improve reliability of CONNECT_IND detection on channel 38 (RF channel 12). You could also experiment with adjusting the 600 ms postponement for scan req/rsp based on the actual length of the scan response. A later improvement could be to make this postponement amount dynamic based on the actual observed length of the scan response for the target MAC.

Reporting packets with a CRC error could be an addition for a later time.

from sniffle.

I made some other changes to improve connection detection reliability, especially on channel 38. I can detect CONNECT_IND with greater than 90% reliability in my own testing with the latest firmware. Hopefully this will work better for you too.

from sniffle.

Version 1.9 now brings back measurement of the advertising hop timing, so it should work with a variety of advertising hop timings.

from sniffle.

@piotrwiniarczyk-silvair On the Telink device, does the time between ADV_IND on 37/38/39 change when there is a SCAN_REQ/SCAN_RSP, or is it constant? Sniffle has logic to delay the hop to 38 if there is a scan request detected on 37, as it assumes more time will be spent on 37 to handle the scan request/response. This is the case on all devices I've looked at thus far, though I I'm curious if your Telink device that puts so much time between advertising channels behaves differently.

from sniffle.

It seems that TeLink is doing such weird thing.
See attached Wireshark scan:

No. Time    Source                Info
10 0.187296 TelinkSemico_aa:b7:3e ADV_IND
11 0.001244 TelinkSemico_aa:b7:3e ADV_IND
12 0.001202 TelinkSemico_aa:b7:3e ADV_IND
13 0.191720 TelinkSemico_aa:b7:3e ADV_IND
14 0.000487 64:9f:1b:06:d8:24     SCAN_REQ
15 0.000330 TelinkSemico_aa:b7:3e SCAN_RSP
16 0.002612 TelinkSemico_aa:b7:3e ADV_IND

Frame 11 to 10 time difference is 1244 us, same for 12 to 11. This sums up to 2446 us
There is a SCAN_REQ in frame 14, so there is no ADV_IND on channel 38 (Sniffle) didn't capture it.
The frame 16 to fame 15 time difference is 2612 us, that is roughly 150 us bigger than 2446 us.

The BLE Core specification does not state that ADV_IND packets must be in 37, 38 and 39 channel order nor it says that they must be evenly spread in time. I would not expect 100% connection sniffing success rate for a single channel radio. But still it can be better than today - Nordic sniffer is doing pretty well, but it is close source, so we cannot replicate the solution.

from sniffle.

Thanks for your input.

Regarding the 37->38->39 hop sequence, it used to be mandatory up to BLE 5.0. In Bluetooth 5.1, they made it permissible to change/randomize the hop sequence, though in practice I have not encountered any BLE controller implementations that do this.

Regarding the timings you gave, are packets 10/11/12 on channels 37/38/39, packets 13/14/15 on channel 37, and packet 16 on channel 39, with 38 skipped?

from sniffle.

Also, how long was the SCAN_RSP for the timings you gave above? It looks like the ADV_IND packet 16 on channel 39 was delayed by 983 us (2612 + 330 + 487 - 2446) compared to the usual.

For reference, including a 1 octet preamble, 4 octet access address, and 3 octet CRC, with the 1 megabit PHY, a SCAN_REQ takes 176 us, T_IFS is 150 us, and the SCAN_RSP takes 128-376 us depending on the response length. Thus, depending on the SCAN_RSP length, that can account of up to 702 us of the delay. However, as you mentioned, really the device can do whatever it wants in terms of hop timing.

One thing I could do is to trigger a hop from 37->38 immediately in case of devices with slow advertising hop intervals that don't extend their time on 37 by as much the SCAN_REQ/SCAN_RSP seqeunce takes. However, your Telink device seems to add a delay greater than the SCAN_REQ/SCAN_RSP time.

How reliable is connection detection with the Telink peripheral on the new v1.9 firmware? By the behaviour you described, I think the v1.9 firmware should work well.

from sniffle.

I agree reporting packets with a CRC error would be useful to give useful information on timings and signal quality. I'll probably keep the default to drop packets with a CRC error, and add an option to send them up to the host (but skip processing them in firmware). Including the CRC with the message (and perhaps adding a flag to indicate CRC errors) would need a breaking change in the interface between the host, so I'll do this with a major release and bump the firmware "API Level".

from sniffle.

Option to allow receiving packets with CRC errors now added to master, planned for the v1.10.0 release. Note that packets will still need to pass the sync word (access address) detection.

from sniffle.