Sniffing BLE 5.0 packets

RE: Sniffing BLE 5.0 packets

Hung Bui — Mon, 13 Nov 2017 15:38:41 GMT

If you use our sniffer, you will only able to sniff BLE 4.0 . But it's not a problem because from the trace we still can see what's going on and can see if there is any feature of BLE 4.2 or 5.0 is requested (before the sniffer loses the connection).

RE: Sniffing BLE 5.0 packets

Ankit — Fri, 10 Nov 2017 15:38:10 GMT

I am able to capture logs for other devices which are BLE 4.2 supported. But I doubt that the device which I am not able to capture logs is supported by BLE 5.0.

But still I will send you the trace file.

RE: Sniffing BLE 5.0 packets

Hung Bui — Fri, 10 Nov 2017 14:59:49 GMT

Can you just upload the sniffer trace file, instead of the snapshot? You can send me via PM if there is anything confidential.

From what I'm seeing, it seems more like the sniffer couldn't capture all packets from the peers. You need to make sure you leave the sniffer close to both of the 2 devices (dozens of cm) Which board did you use as the sniffer ?

RE: Sniffing BLE 5.0 packets

Ankit — Fri, 10 Nov 2017 11:46:48 GMT

Here I am attaching a snapshot of captured BLE packets.pimgpsh_fullsize_distr.png

RE: Sniffing BLE 5.0 packets

Hung Bui — Tue, 17 Oct 2017 11:20:24 GMT

Hi Ankit,

Beside connection request and empty PDUs, what else can you capture ? Can you capture the Security encryption request ? Or PHY change request ? and Feature request ?

The feature request and response will reveal if 4.2 is supported or not.

Could you post a screenshot of a captured session ?

The nRF51 sniffer should be able to BLE mesh packets, as long as the Mesh use the default advertising access address 0x8E89BED6. But it was not made to parse them and follow a communication (SAR packets for example)