Is there a way to skip the product check?

[gaborrell]

I just bought a used Bose qc35II and the prev owner did somethign with the FW so it now show that it is a Bose SoundSport. Official BTU says it has the latest FW (For that product) so I cannot replace the FW with the official tool... I just downloading and installing your tool but I wonder if there is any way to skip or disable the check which is for the connected device and for the FW which will be loaded. I know its a safety feature but in my case it would be a help I think...

Error: this file is not for the selected device: file for 05a7:4020, device is 05a7:4012

BTW the device enter and leave DFU as I see from the messages.

Thanks, Gabor

[tchebb]

Yes, all subcommands support a -f flag that forces the operation if you have an unknown device connected. The only time that flag won't work is if your device has been tested and explicitly found not to work. The QC35 II is completely untested with this tool.

[tchebb]

Ignore my last comment—I misread the error you want to bypass. There's currently no way to skip that error, so you'll have to do one of two things:

1. Clone the code yourself, comment out or delete these lines, and then build and run the modified version with cargo run -- <your arguments>.
2. Use a hex editor to edit the DFU suffix in the last 16 bytes of the firmware file to set the PID to the one your device currently reports (or to ffff, which will produce a bypassable warning), then fix the CRC field so the file validates correctly. bose-dfu file-info will tell you the PID as well as the actual and expected CRCs, so you can use that to make sure you've changed the right bytes before you attempt to flash the device.

Edit: fixed the name of the file-info command and the ffff PID value, both of which I'd misremembered.

[gaborrell]

Hi Tom,

It worked. I used option 1. So My device is a Bose QC35II (Serial number ends with AE if that matters). Now it runs the latest FW but I used your app to replace it several times and it always worked.. Now the Bose BTU also works.

So all good :)

Thanks for your help!

Cheers, Gabor

On Sun, Jan 22, 2023 at 3:37 AM Tom Hebb @.***> wrote:

Ignore my last comment—I misread the error you want to bypass. There's currently no way to skip that error, so you'll have to do one of two things:

1. Clone the code yourself, comment out or delete these lines https://github.com/tchebb/bose-dfu/blob/2a0df151a725dbdaf4f2e5fbd1d4e7acf5b68413/src/main.rs#L187-L194, and then build and run the modified version with cargo run -- <your arguments>.
2. Edit the DFU header at the end of downloaded file to set the PID to the one your device currently reports (or to 0000, which will produce a bypassable warning), then fix the CRC field so the file validates correctly. bose-dfu info will tell you the expected CRC for a file that fails validation.

— Reply to this email directly, view it on GitHub https://github.com/tchebb/bose-dfu/issues/4#issuecomment-1399389221, or unsubscribe https://github.com/notifications/unsubscribe-auth/A5MP2WVXQ6ERRJ22SEGRYGDWTSMOLANCNFSM6AAAAAAUCTGASU . You are receiving this because you authored the thread.Message ID: @.***>

[tchebb]

Glad to hear you got it working! Could you do me a favor and post the output of bose-dfu list for your device (with the correct firmware) both in normal mode and in DFU mode (after bose-dfu enter-dfu)? That'll give me the full set of USB IDs needed to mark the device as "tested" so others don't have to pass the -f flag. Thanks!

[gaborrell]

Hi Tom, Will try to get the output later today. In the meantime may I ask you if you have any idea around the BT part and maybe buttons on the headphone itself? Sometimes BT is not connecting properly and also I think the range is very poor and I'm curious if the BT Firmware is part of the SW or its separate Firmware? I mean in the meantime I did update with the Bose utility as well and went back to some older release but same issue. And around the control buttons (volume) its strange as when I did the FW change with Bose-dfu it worked with an android phone but after upgrade to newest FW its gone and on IOS never worked. Checked the cables inside the headphone but looks ok so it should be again some SW issues but no idea... When I download the SW from Bose 3 files comes with it but when flashing the bose-dfu using just 1... So thats why I'm thinking maybe the other files could contain something... What do you think? Thanks, Gabor

On Sun, Sep 3, 2023 at 7:32 PM Tom Hebb @.***> wrote:

Glad to hear you got it working! Could you do me a favor and post the output of bose-dfu list for your device (with the correct firmware) both in normal mode and in DFU mode (after bose-dfu enter-dfu)? That'll give me the full set of USB IDs needed to mark the device as "tested" so others don't have to pass the -f flag. Thanks!

— Reply to this email directly, view it on GitHub https://github.com/tchebb/bose-dfu/issues/4#issuecomment-1704359572, or unsubscribe https://github.com/notifications/unsubscribe-auth/A5MP2WQ2CO7RJJYNYK3ITA3XYS5MTANCNFSM6AAAAAAUCTGASU . You are receiving this because you authored the thread.Message ID: @.***>

[tchebb]

When I download the SW from Bose 3 files comes with it but when flashing the bose-dfu using just 1

Thanks for bringing this up! I hadn't realized that other devices had more files, as updates for my device have only the .dfu file and nothing else. I think it's likely that bose-dfu's failure to handle the .xuv files could cause functional issues with a device. I'm not confident that's what you're experiencing given that you subsequently used the official updater, which presumably put everything back in order, but it's worth investigating. If you can get a USB capture of the official updater, that'll let me see how it handles them. I've filed #6 to track .xuv file support, so let's continue the discussion there.

As for the volume button issues, I know that newer firmwares for my speaker added support for AVRCP Absolute Volume (where, as I understand it, the speaker doesn't set its own volume but instead lets source device dictate it). That broke volume control completely for some of my computers, which didn't support Absolute Volume themselves properly. Perhaps you're experiencing a similar issue? I would expect any reasonably modern phone to support that fine, though, so it might be something else.

[gaborrell]

Glad to hear you got it working! Could you do me a favor and post the output of bose-dfu list for your device (with the correct firmware) both in normal mode and in DFU mode (after bose-dfu enter-dfu)? That'll give me the full set of USB IDs needed to mark the device as "tested" so others don't have to pass the -f flag. Thanks!

Hi,

Here is the output.

C:\Windows\System32>bose-dfu list
05a7:40fe 077061Z8167G565AE Bose QC35 II [compatible device in normal mode]

C:\Windows\System32>bose-dfu enter-dfu
[INFO  bose_dfu] Note that device may take a few seconds to change mode

C:\Windows\System32>bose-dfu list
05a7:4020 077061Z8167G565AE Bose QC35 II [UNTESTED device in unknown mode]

[gaborrell]

Hi @tchebb ,

2. Seems that PID is good for identification only in DFU mode right...? BTW how the device name "Bose QC35 II" is coming? Is the Device sending it or you have some list in the application? If the device sending the name then it could be used right? (Only problem with this is like in my case someone else f.cked the FW and it was for a different product and made the product name and DFU mode PID looked completly different. But I guess the Bose updater also used that info as the device was identified in the updater as the other product...

[tchebb]

Yeah, I think device name is the way to go. I want to see if I can confirm that's what the official updater uses, though, since it's best to stay as close to it as possible.