"Computing hop interval" never ending

[FrancescoTaurino]

Hello, I have a problem similar to #14, but slightly different: with the -c option I can capture the CONNECT_REQ and see all the fields (AA, CRC Init value, etc...). But when I try the -f option with the -m <AA> and -p <hop_interval>, Btlejack stucks on "Computing hop interval" never ending.

I am using two Android smartphones and Btlejack on Ubuntu and only one Micro:bit.

Thanks in advance for any suggestion.

[FrancescoTaurino]

UPDATE: Using: python btlejack -f <aa_value> -m <chm_value>, Btlejack stucks on "Computing hop interval". Using: python btlejack -f <aa_value> -m <chm_value> -p <hop_interv_value>, Btlejack stucks again on "Computing hop interval" and does not recognize Hop Interval as provided; Using python btlejack -f <aa_value> -p <hop_interv_value>, Btlejack computes che Channel map (fast, but different from the one in the CONNECT_REQ), then it recognizes hop interval as provided and then stucks on "Computing hop increment".

[virtualabs]

Btlejack did not recovered the right channel map, due to a timeout issue. I've added a timeout option (-n or --timeout) to allow adjustments to the default value used in Btlejack's firmware (2 seconds).

If a device uses a hopInterval of 210 for instance, it means it will spend 210*1.25ms=9.712s on each channel, which is far more than 2 seconds ! So first check what hopInterval this device is using by intercepting a connection request, then adjust the timeout manually. The timeout option takes a value in milliseconds as parameter.

I'll investigate the other issue (computing hop interval even if it was provided) as soon as possible.

[FrancescoTaurino]

Thanks for the feedback.

I think it would be nice to include the -t option with the -c option. Something like this: python btlejack -c any -t

So the connection is hijacked immediately after the first CONNECT_REQ packet and the fields recovery should be not necessary anymore (even if sometimes I noticed that channel map, hop interval and increment recovered are different from the values in the CONNECT_REQ).

Does it make sense?

[virtualabs]

It does make sense, indeed.

For the record, hop increment and channel map can be updated on request. I noticed many devices renegotiate their hop interval right after services and characteristics discovery (I think to allow quick discovery and then save energy), and usually regularly change channel map. Since the hop increment is computed from channel map and measured hop interval, it may sometimes differ due to connection parameters updates (if any). I won't go into details in this post, but this is a consequence of the way btlejack (and ubertooth-btle) recovers a connection's parameters.

I plan to implement new features in btlejack, but I'm currently rather busy at work. Expect some news for the beginning of 2019.

[MrZMN]

Just faced the same problem- got stuck on the 'computing hope interval'. I found it's not only determined by the channel map changing, but is also related to the noisy 2.4GHz environment. I succeed after changing to a less interference environment, even if the channel map still changes

[oncegrey]

@MrZMN - Hi there, sorry for replying to an old thread but this is something I'm working on as part of a project and need to solve this issue. How were you able to change to a less interfering environment, if you are able to remember?