Closed arjunbj closed 1 year ago
Yep, it looks like it's not entering the mode at all. It's interesting that your device has the same USB VID and PID as my SoundLink Color II when it's in normal mode despite being a different model: that's not something I expected, and that's why the tool says your device is supported even though it's not one I've tested. It's even stranger that it would use the same USB ID but require a different sequence to get into DFU mode.
Could you possibly use Wireshark (make sure to select USBPcap in its installation wizard if you're on Windows) to capture the USB traffic the official updater sends to your device before failing? That will hopefully let me figure out what's going wrong.
Hi @tchebb! I'm also on this trouble with my Bose Soundlink Mini II Special Edition. The only difference with @arjunbj is that my device is identified as "M3", but the rest is completely the same, even that the PID is identified as the one of SoundLink Color II.
Now I'm far from home but I will be back by the end of the month and I can gladly copy you the USB dump from Wireshark. Expect news from me around there.
@tchebb all in your email ;)
Hello there,
Firstly I wanted to congratulate you with the work you have put in @tchebb. This interface is really great and is a way better method of running Bose updates in my opinion :) I just wanted to know if/how you solved the :
bose-dfu download KCup_1.1.4_stack_plus_app.dfu Error: no devices match specification
As I am having the same issue with my Bose SoundLink Mini 2 and am curious to know how and if you were able to find the fix.
Thanks in advance for your reply :)
These are the following command lines I have typed, note that I changed the Hex values of the dfu file in order for them to match my PID and have the correct CRC :) :
bose-dfu list
05a7:40fe 00000000000000000000000 Bose SoundLink Mini II [compatible device in normal mode]
bose-dfu info
USB serial: 00000000000000000000000
HW serial: 72476P62100100A2
Device model: Cup
Current firmware: .1.4.3558
The unedited hex DFU file with the PID not matching mine :
bose-dfu file-info KCup_1.1.4_stack_plus_app.dfu
For USB ID: 05a7:4009
CRC: valid (0xe14c9cbb)
The edited hex DFU file matching my PID and with correct CRC :
bose-dfu file-info KCup_1.1.4_stack_plus_app.dfu
For USB ID: 05a7:40fe
CRC: valid (0x13dc0b5b)
bose-dfu enter-dfu -p 40fe
[INFO bose_dfu] Note that device may take a few seconds to change mode
bose-dfu download -p 40fe KCup_1.1.4_stack_plus_app.dfu
Error: no devices match specification
It seems my Bose SoundLink Mini 2 won't be in DFU mode apparently.
Thanks in advance for your help :)
I received an email in January regarding this device with the subject "bose-dfu works with SoundLink Mini II":
I've been able to use bose-dfu to update my Bose Soundlink Mini 2, so it seems to be working for that device and you may want to add it to the list of supported devices.
I'll be glad to help if you want me to gather whatever additional information you may need to fix any remaining issues, e. g. that "unknown mode" message – whatever mode the device was in seems to have been the correct one for firmware updates.
Here's what the process looked like in my terminal:
$ sudo $(which bose-dfu) info USB serial: 00000000000000000000000 HW serial: <REDACTED> Device model: Cup Current firmware: .0.11.3050 $ sudo $(which bose-dfu) list 05a7:4009 00000000000000000000000 Bose SoundLink Mini II [UNTESTED device in unknown mode] $ sudo $(which bose-dfu) file-info KCup_1.1.4_stack_plus_app.dfu For USB ID: 05a7:4009 CRC: valid (0xe14c9cbb) $ sudo $(which bose-dfu) enter-dfu [INFO bose_dfu] Note that device may take a few seconds to change mode $ sudo $(which bose-dfu) download KCup_1.1.4_stack_plus_app.dfu -f [WARN bose_dfu] Device has not been tested with bose-dfu; by proceeding, you risk damaging it [WARN bose_dfu] Cannot determine device's mode; command may damage devices not in DFU mode [INFO bose_dfu] Update verified to be for selected device [INFO bose_dfu] Beginning firmware download; it may take several minutes; do not unplug device [INFO bose_dfu::protocol] Waiting 76.797s, as requested by device, for firmware to manifest $ sudo $(which bose-dfu) info USB serial: 00000000000000000000000 HW serial: <REDACTED> Device model: Cup Current firmware: .1.4.3558
(If you wrote me this email and want credit by name, just let me know; for now, I'm erring on the side of caution and keeping you anonymous.)
Sorry for the huge delay here, all! I've gotten information about this device from lots of people, and I haven't had the time to sit down and sort it all out until now.
Luckily, the issue many of you are having seems simpler than I originally thought, and it's really my fault for not spotting it earlier: @arjunbj and @Gigzy (and maybe @ighdez too), the reason your download
and leave-dfu
commands didn't do anything is because you aren't passing the -f
flag, which tells bose-dfu to operate even on an untested/unrecognized device.
Every command except list
supports the -f
flag, and none of them will "see" untested devices without it. The only reason info
and enter-dfu
worked without that flag is because the SoundLink Mini II (at least on certain firmwares; see below) reports the same USB ID in normal mode as the SoundLink Color II, which is a tested device. But as soon as it enters DFU mode, it changes to a different ID that's not tested, so subsequent commands fail unless you pass -f
. (@Gigzy, I think if you'd run bose-dfu list
after running bose-dfu enter-dfu
you'd have seen an entry with the 05a7:4009
ID that your firmware file expects.)
As shown in the email above, DFU mode operations (download
, leave-dfu
) seem to work fine when -f
is given, so I think it's safe for me to make a new release where I mark this device as tested so -f
isn't needed anymore.
There's still one mystery, though: why do @arjunbj, @Gigzy, and @ighdez's devices have normal mode ID 05a7:40fe
(same as my SoundLink Color II), but the device of the emailer above have normal mode ID 05a7:4009
(same as the SoundLink Mini II's DFU mode)? My hypothesis is that Bose changed the normal mode ID between firmware versions (maybe from 0.x to 1.x?).
To test that hypothesis, could anyone who's still interested in helping out with this issue run the following commands and post the output? Bonus points if you can do it both on a 1.x and a 0.x firmware (although I understand if you don't want to downgrade your firmware that far on an untested device just for debugging purposes).
$ bose-dfu list
$ bose-dfu enter-dfu -f
$ bose-dfu list
$ bose-dfu leave-dfu -f
$ bose-dfu list
$ bose-dfu info -f
Hey there, I wrote that e-mail. And I can indeed confirm that my device has USB ID 05a7:40fe now. When I plug it in and run lsusb
, I get this line:
Bus 001 Device 013: ID 05a7:40fe Bose Corp. SoundLink Color II / Flex
I have no idea what the USB ID was before the upgrade. And despite the fact that it says SouldLink Color II / Flex, I'm pretty sure that that's not the model that I have. When I connect via Bluetooth, the device calls itself Bose Mini II SoundLink.
Thanks for the confirmation, @mberndt123! From your previous logs, it looks like it had ID 05a7:4009
on the old firmware, so I think my hypothesis makes sense.
Fun fact: the names shown in short lsusb
output aren't actually from the device at all—they're looked up in the Linux USB ID Repository and can be wrong, especially if multiple devices share an ID. To get the device-reported ID, use lsusb -v
and look at the strings next to iManufacturer
and iProduct
.
@mberndt123 hmm, looking at your old log again, it seems like maybe some commands got misordered. I'm specifically looking at these commands:
$ sudo $(which bose-dfu) info
USB serial: 00000000000000000000000
HW serial: <REDACTED>
Device model: Cup
Current firmware: .0.11.3050
$ sudo $(which bose-dfu) list
05a7:4009 00000000000000000000000 Bose SoundLink Mini II [UNTESTED device in unknown mode]
$ sudo $(which bose-dfu) enter-dfu
[INFO bose_dfu] Note that device may take a few seconds to change mode
The fact that info
and enter-dfu
succeeded without -f
indicates your device started in normal mode and had a recognized ID, but that's inconsistent with the 05a7:4009
shown by the intervening list
, which is not in the current list of recognized IDs and, according to all other evidence, is the ID this device shows in DFU mode. Is it possible you ran that list
while the device was in DFU mode and just put it in the wrong place while making the transcript?
I've marked this device as compatible with commit 146c51c00c950719fe3e074123d9efaeff44d1f5. I'll make a new release that includes that commit within the week.
Also, I've filed #5 to track the missing first digit in "Current firmware" for this device. If anyone wants to help fix that, it has some commands you can run.
I can help with the testing. Can I do it even if my device is currently bricked? I was waiting for the fix mentioned in this issue but I don't think it has been released yet.
@tchebb,
sorry, this is way too long ago for me to remember anything about how I made that transcript.
I can help with the testing. Can I do it even if my device is currently bricked? I was waiting for the fix mentioned in this issue but I don't think it has been released yet.
Depends how it's bricked, but if it enters DFU mode you likely can. You're right that I haven't made a release that marks this device as supported yet. My "within the week" timeline got disrupted by @gaborell's discovery that this device and others have additional .xuv
firmware files (#6). Since we don't support those files, I'm hesitant to make a release that marks these devices as fully supported. I think it should be okay if I make bose-dfu print a warning and maybe require -f
when updating devices with .xuv
firmware, though.
Until I do that, you can run the Git version if you'd like. Just keep the .xuv
issue in mind.
Hi,
I'm trying to downgrade my firmware on my soundlink mini 2 in order because it is not working and blinking red despite trying everything I saw online, my last hope is downgrading it and re-updating the firmware either with your program or on the bose website.
the issue I have is due to the USB ID of my device which is not matching with the one in the firmware bose-dfu list 05a7:40fe 00000000000000000000000 Bose SoundLink Mini II [compatible device in normal mode]
bose-dfu file-info KCup_1.1.3_stack_plus_app.dfu (same with 1.1.4) For USB ID: 05a7:4009 CRC: valid (0xe14c9cbb)
so when I'm trying either download or leave-dfu command (with or without -f) I have this message : Error: no devices match specification
how can I have my USB ID change or change the one attached to the files ?
I was about to give up on my quest to resurrect my Sound link Mini II which has been showing flashing red when I power it and thats when I found this great repo. Let me first say hats off to your effort Mr. Developer :) I had tried the regular bose updater and it shows "no dice" error when it tries to update![image](https://user-images.githubusercontent.com/22302475/180626130-1bc35f65-9faa-474b-8d04-e0ae056380ee.png)
Tried this method of firmware update, added a new entry for sound link mini II in the 70-bose-dfu.rules
Below are outputs from different commands bose-dfu info USB serial: 00000000000000000000000 HW serial: 68617963564514A4 Device model: Cup Current firmware: .1.4.3558
bose-dfu list 05a7:40fe 00000000000000000000000 Bose SoundLink Mini II [compatible device in normal mode]
bose-dfu file-info KCup_1.1.4_stack_plus_app.dfu For USB ID: 05a7:4009 CRC: valid (0xe14c9cbb)
When I try to start the process I get below responses bose-dfu enter-dfu [INFO bose_dfu] Note that device may take a few seconds to change mode
bose-dfu download KCup_1.1.4_stack_plus_app.dfu Error: no devices match specification
bose-dfu leave-dfu Error: no devices match specification
The fact that bose-dfu leave-dfu gives the same error gets me thinking maybe the device is not entering dfu mode? Any pointers/suggestions appreciated. I even tried with 1.1.3 firmware trying to repeat above steps but same error.