microbit key cracking reliably unreliable

[jsmif]

This could be a btlejack issue rather than a Mirage issue, but when I run

sudo btlejack -c any -d /dev/ttyACM0 -d /dev/ttyACM1 -d /dev/ttyACM2

I can successfully see a known JustWorks pairing attempt about 50% of the time (if I use 3 sniffers. Less reliable with only 1 of course.)

When I try to do the same thing from within Mirage, issuing:

sudo mirage ble_sniff SNIFFING_MODE=newConnections CRACK_KEY=yes INTERFACE=microbit0 INTERFACEA=microbit1 INTERFACEB=microbit2

I've so far only had one success (out of perhaps 20 attempts. Coincidentally(?) it was the first attempt, with a single microbit rather than the 3 which I tried to improve reliability.)

The failure is that it just prints

[INFO] Mirage process terminated !

sometimes even before I have a chance to hit the "pair" button on the Android phone.

This might be another reason to update Sniffle support, since Sniffle is pretty reliable now, whereas btlejack isn't being updated anymore AFAIK.

p.s. I notice in the example documentation it says firmware version : 3.14 for microbit. The latest released version is 2.1.1, so do I need to use this firmware to be more reliable?

[jsmif]

Concrete examples of what I'm seeing:

sudo mirage ble_sniff SNIFFING_MODE=newConnections CRACK_KEY=yes INTERFACE=microbit0 INTERFACEA=microbit1 INTERFACEB=microbit2 
[INFO] Module ble_sniff loaded !
[SUCCESS] BTLEJack device #0 successfully instantiated (firmware version : 2.1)
[SUCCESS] BTLEJack device #1 successfully instantiated (firmware version : 2.1)
[SUCCESS] BTLEJack device #2 successfully instantiated (firmware version : 2.1)
[INFO] channel: 37
[PACKET] [ CH:37|CLK:1713988452.131504|RSSI:0dBm ] << BLE - Advertisement Packet | type=CONNECT_REQ | srcAddr=AB:2C:9F:3D:33:11 | dstAddr=AD:74:92:17:ED:AF | accessAddress=0xd9d2aa9e| crcInit=0x22303c| channelMap=0x1fffffffff| hopInterval=36| hopIncrement=8 >>

┌Sniffed Connection─────────┬──────────────┬──────────────┬───────────────┐
│ Access Address │ CRCInit  │ Channel Map  │ Hop Interval │ Hop Increment │
├────────────────┼──────────┼──────────────┼──────────────┼───────────────┤
│ 0x9eaad2d9     │ 0x3c3022 │ 0x1fffffffff │ 36           │ 8             │
└────────────────┴──────────┴──────────────┴──────────────┴───────────────┘
[PACKET] [ CH:37|CLK:1713988452.141876|RSSI:0dBm ] << BLE - Control PDU Packet | type=LL_FEATURE_REQ | data=ff75000000000000 >>
[PACKET] [ CH:16|CLK:1713988452.187061|RSSI:0dBm ] << BLE - Control PDU Packet | type=LL_FEATURE_RSP | data=0100000000000000 >>
[PACKET] [ CH:24|CLK:1713988452.230301|RSSI:0dBm ] << BLE - Control PDU Packet | type=LL_VERSION_IND | data=091d00be02 >>
[PACKET] [ CH:32|CLK:1713988452.274869|RSSI:0dBm ] << BLE - Control PDU Packet | type=LL_VERSION_IND | data=0830001111 >>
[PACKET] [ CH:3|CLK:1713988452.321537|RSSI:0dBm ] << BLE - Pairing Request Packet | outOfBand=no | inputOutputCapability=0x4 | authentication=0xd | maxKeySize=16 | initiatorKeyDistribution=0xf | responderKeyDistribution=0xf >>
[PACKET] [ CH:11|CLK:1713988452.36659|RSSI:0dBm ] << BLE - Pairing Response Packet | outOfBand=no | inputOutputCapability=0x3 | authentication=0x1 | maxKeySize=16 | initiatorKeyDistribution=0x7 | responderKeyDistribution=0x7 >>
[PACKET] [ CH:20|CLK:1713988453.044627|RSSI:0dBm ] << BLE - Pairing Confirm Packet | confirm=21f8c1d87716734ff1e5bb983a785064 >>
[PACKET] [ CH:28|CLK:1713988453.124338|RSSI:0dBm ] << BLE - Pairing Confirm Packet | confirm=362ac3f2137fee49257a76c61808e122 >>
[INFO] Mirage process terminated !

That's the best case, where I hit "pair" on the phone really quick. If I'm slow, this is the common case:

sudo mirage ble_sniff SNIFFING_MODE=newConnections CRACK_KEY=yes INTERFACE=microbit0 INTERFACEA=microbit1 INTERFACEB=microbit2 
[INFO] Module ble_sniff loaded !
[SUCCESS] BTLEJack device #0 successfully instantiated (firmware version : 2.1)
[SUCCESS] BTLEJack device #1 successfully instantiated (firmware version : 2.1)
[SUCCESS] BTLEJack device #2 successfully instantiated (firmware version : 2.1)
[INFO] channel: 38
[PACKET] [ CH:38|CLK:1713988648.335499|RSSI:0dBm ] << BLE - Advertisement Packet | type=CONNECT_REQ | srcAddr=AB:2C:9F:3D:33:11 | dstAddr=AD:74:92:17:ED:AF | accessAddress=0xd29e5ee5| crcInit=0xc115a| channelMap=0x1fffffffff| hopInterval=36| hopIncrement=13 >>

┌Sniffed Connection─────────┬──────────────┬──────────────┬───────────────┐
│ Access Address │ CRCInit  │ Channel Map  │ Hop Interval │ Hop Increment │
├────────────────┼──────────┼──────────────┼──────────────┼───────────────┤
│ 0xe55e9ed2     │ 0x5a110c │ 0x1fffffffff │ 36           │ 13            │
└────────────────┴──────────┴──────────────┴──────────────┴───────────────┘
[PACKET] [ CH:26|CLK:1713988648.349243|RSSI:0dBm ] << BLE - Control PDU Packet | type=LL_FEATURE_REQ | data=ff75000000000000 >>
[INFO] Mirage process terminated !

Also even though I know this isn't to the point where there's fragmented packets, I still went ahead and pulled in the changes to ble.py from this PR, but as expected that made no difference.