-
Notifications
You must be signed in to change notification settings - Fork 196
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Computing hop increment" never ending #14
Comments
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. |
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 #15, same result) |
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. |
@floyd-fuh Have you noticed an increase in speed with 2 or more Microbits? |
@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. |
Have you been working with only one micro so far? Have you ever seen "Computing hop increment" terminated? |
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. |
Thank you for your feedback! |
I have a problem that the "Computing hop increment" is never ending.
So the -i works fine:
The -s as well:
But then I do -f and even after 20 minutes the "Computing hop increment" is not finishing:
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:
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.
The text was updated successfully, but these errors were encountered: