Open maichai opened 3 years ago
Hi, Can you provide me the output of lsusb please ? Thanks.
Will do when I come back where I have th ehardware. You are aware that the client needs to fit the firmware version?
lsusb identifies the board as: Texas Instruments, Inc. CC1352R1 Launchpad
in /dev/serial/by-id/
both ports of the launchpad can be seen. It also works using the sniffle python clients, so it is a problem with the client code in mirage. You are aware that the client needs to fit the firmware version?
I tried again with SniffLE 1.6, Injectable/ButteRFly NRF Dongle, modified BTLEjack firmware for MicroBit: Result: -butterfly0 and microbit0 show advertisements, also new connections, but must of the info is missed, cracking does not happen. -sniffle0 show nothing: mirage says it is using firmware 1.5 (actually the device has firmware 1.6!), my guess is that your mirage code was written for an older version of SniffLE, e.eg. 1.5 and does not work with 1.6 SniffLE firmware. I had the same problem when I upgraded the firmware to 1.6 and did not upgrade the command line tools for SniffLE.
In order to verify my hypothesis I flashed the old SniffLE firmware 1.5 on my board and that works fine with Mirage.
I suggest you take a look at the changes from 1.5 to 1.6 in the SniffLE command line tools and update your code in mirage accordingly.
Sniffle firmware v1.6 did break compatibility with v1.5 clients due to changes in the firmware->host message format. Some time soon (still working on things), I'll be releasing a Sniffle v1.7 firmware that again breaks compatibility with client software for v1.6, due to a baud rate change (working around a latency issue with the XDS110 USB to UART). Hopefully that'll be the last client-breaking change for a while. Once v1.7 is out, I'll look into getting Mirage working with it again.
Hi @sultanqasim , any updates on this topic ? Is the current sniffle API stable enough to implement it in Mirage?
I ended up not changing the baud rate as I made a workaround (custom XDS110 firmware) to fix the latency issue in the stock TI firmware. The API should remain stable now I'd say.
Great news, thanks ! I'll try to implement the support for sniffle as soon as possible :)
@RCayre just as an FYI Sniffle fw v1.8 is released now, and I tried it with Mirage and saw the same error as the person above; i.e. that it says it's on 1.5 and it prints nothing out. With v1.8 just released, now would be a good time for an update :)
~~> load ble_sniff
[INFO] Module ble_sniff loaded !
<< ble_sniff >>~~> set INTERFACE sniffle0
<< ble_sniff >>~~> set SNIFFING_MODE advertisements
<< ble_sniff >>~~> run
[SUCCESS] Sniffle device #0 successfully instantiated (firmware version : 1.5)
^C[INFO] Mirage process terminated !
Also a misc request if you're doing an update: can you create CHANNELA
/CHANNELB
and PCAP_FILEA
/PCAP_FILEB
options too, so that I can set up 3 Sniffle instances to sniff 37, 38, and 39 separately? I recently found this to be required for some devices.
I just released v1.9 today, it also adds a command to retrieve the firmware version, so in the future software can check the firmware version for compatibility. My intention is to update the API Level field of the firmware version whenever there is a breaking change to the UART interface with the host.
I have a SniffLE 1.6 device and it works wll with the SniffLE python clients. The integration in Mirage seems to be using older firmware, as ble_scan and ble_sniff do not show anything, but the original clients show something.
Important note: I edited the issue from version number 1.5 to 1.6. The firmware version 1-5 actually works fine with Mirage, it is firmware version 1.6 that does not work. Sorry, my bad.