Closed FrancescoTaurino closed 1 year ago
Btlejack does not implement on-the-fly packet decryption, so it cannot catch the encrypted LL_CONNECTION_UPDATE_REQ and therefore cannot stay synchronized with the connection.
Btlejack may fail at recovering hop increment if the hop interval is too high. You may want to use the -n option to force a timeout value in milliseconds that btlejack will use when recovering the channel map.
Btlejack does not implement on-the-fly packet decryption, so it cannot catch the encrypted LL_CONNECTION_UPDATE_REQ and therefore cannot stay synchronized with the connection.
Ok, it makes sense indeed.
Btlejack may fail at recovering hop increment if the hop interval is too high. You may want to use the -n option to force a timeout value in milliseconds that btlejack will use when recovering the channel map.
Can you give an example of the use of -n
option?
Thank you for the reply.
After the CONNEC_REQ, the pairing procedure (and some other packets), Btlejack always loose the connection.
I used crackle to analyze the packets and I noticed that the last packet captured before the the lost is always a LL_CONNECTION_UPDATE_REQ.
One way to recover the connection wolud be to run
btlejack -f 0xxxxxxxxx
immediately after, but I have only one Micro:bit and the params recovery is very slow (I have never seen it completed, because btlejack always stucks on hop increment).Maybe it is necessary to modify the firmware code. Any advice?