"Computing hop increment" never ending

[floyd-fuh]

I have a problem that the "Computing hop increment" is never ending.

So the -i works fine:

$ btlejack -i
BtleJack version 1.1

[i] Flashing /Volumes/MICROBIT ...
[i] Flashed 1 devices

The -s as well:

$ btlejack -s
BtleJack version 1.1

[i] Enumerating existing connections ...
[...]
[ - 87 dBm] 0xaf9a8da1 | pkts: 50
[...]

But then I do -f and even after 20 minutes the "Computing hop increment" is not finishing:

$ btlejack -f 0xaf9a8da1
BtleJack version 1.1

[i] Detected sniffers:
 > Sniffer #0: fw version 1.1

[i] Synchronizing with connection 0xaf9a8da1 ...
✓ CRCInit = 0xbbc761
✓ Channel Map = 0x1f80680043
✓ Hop interval = 2
\ Computing hop increment^C[i] Quitting

When I aborted and tried again I actually got different Channel Map values (it was still the same BLE connection). Is that a problem (I'm not very familiar with the bluetooth protocol) or expected? Here's the output of the second run:

btlejack -f 0xaf9a8da1 -j
BtleJack version 1.1

[i] Using cached parameters (created on 2018-08-21 14:07:57)
[i] Detected sniffers:
 > Sniffer #0: fw version 1.1

[i] Synchronizing with connection 0xaf9a8da1 ...
✓ CRCInit: 0xbbc761
✓ Channel Map = 0x1fc3200000
✓ Hop interval = 2
/ Computing hop increment

It's an iphone 6 talking to a Bluetooth headset (no PIN pairing, I guess it's the "just works" protocol). I'm using btlejack on MacOS.

[virtualabs]

I have a problem that the "Computing hop increment" is never ending.

You are facing a common issue I also had with some devices (such as a Galaxy Tab A) that renew a connection channel map quite often. If you are using only one sniffer (and this is the case), it may take some time to recover the channel map (a maximum time of 37 4 seconds based on the specifications, so basically around two minutes and a half). Usually, the time spent on each channel is defined by the hop interval value (channel_duration = hop_interval 1.25 ms), and rarely exceeds 500 ms (but it may depend on the device you are using).

If the channel map changes between when the sniffer is trying to recover it, then the sniffing operation will failed. To avoid this, the best way is to use multiple sniffers and let btlejack parallelize this channel map recovery step. The 37-channel range is then split into as many devices as you are using, and this speeds up the recovery.

I've also implemented a channel map update detection while sniffing, if by chance this type of packet comes on a channel we are listening to.

There is no easy way to quickly recover a connection's channel map, but using multiple sniffers will definitely speed up the process and give your far better chance to synchronize with your target connection.

You may also want to monitor this connection and the frequency of channel map updates by sniffing a new connection (-c option), and capture the traffic to a PCAP file and then analyze it with Wireshark.

[floyd-fuh]

Ah, thanks, good to know! I will try, I think we ordered around 10 Microbits anyway, at the moment I only have one and maybe next week two. I'll let you know when I tried with more sniffers!

Obviously then this is also not a MacOS issue (just tried it on Linux as well, see https://github.com/virtualabs/btlejack/pull/15, same result)

[virtualabs]

Exactly, this is a limitation due to the way some devices behave regarding a connection's channel map. You may try to sniff in a less noisy 2.4 GHz environment, it helps sometimes (less noise and therefore less channel map updates).

And no, this is a common issue due to some BLE SoCs, not some MacOS-related stuff.

[FrancescoTaurino]

@floyd-fuh Have you noticed an increase in speed with 2 or more Microbits?

[floyd-fuh]

@FrancescoTaurino thanks for reminding me, we actually ordered around 12 microbits, but they got forgotten in our other office location. I just reminded them to get them to me, I should get them mid/end December. Also, everybody and especially @virtualabs: I'm planning to take the microbits to the CCC Congress in Leipzig, so if anybody is interested to make a little meetup there, let me know.

[FrancescoTaurino]

Have you been working with only one micro so far? Have you ever seen "Computing hop increment" terminated?

[floyd-fuh]

My Coworker worked with 2 microbits, which was a little bit better but still not good. I personally have only worked with 1. So to answer your question: For certain bluetooth devices the "Computing hop increment" never terminated, for others it did with only 1 microbit.

[FrancescoTaurino]

Thank you for your feedback!