Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is there a way to skip the product check? #4

Closed
gaborrell opened this issue Jan 21, 2023 · 9 comments
Closed

Is there a way to skip the product check? #4

gaborrell opened this issue Jan 21, 2023 · 9 comments

Comments

@gaborrell
Copy link

gaborrell commented Jan 21, 2023

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
Copy link
Owner

tchebb commented Jan 22, 2023

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
Copy link
Owner

tchebb commented Jan 22, 2023

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
Copy link
Author

gaborrell commented Jan 25, 2023 via email

@tchebb tchebb closed this as completed Sep 3, 2023
@tchebb
Copy link
Owner

tchebb commented Sep 3, 2023

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
Copy link
Author

gaborrell commented Sep 6, 2023 via email

@tchebb
Copy link
Owner

tchebb commented Sep 6, 2023

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
Copy link
Author

gaborrell commented Sep 7, 2023

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]

tchebb added a commit that referenced this issue Sep 8, 2023
Thanks @gaborrell (#4) and James Gregory (email) for testing this
device. Committing this now to record it, but I'm hesitant to include
this entry and the SoundLink Mini II one I added recently in a release
just yet. Two new pieces of information have come to light:

 1. All devices except the SoundLink Color II have additional .xuv
    firmware files that likely need to be flashed somehow to ensure
    correct operation. Without support for those, I don't think it's
    truthful to call ourselves "compatible". See #6.

 2. All three of the tested devices have the same normal mode PID,
    0x40fe. Assuming some untested devices do too, we should stop using
    that alone to mark a device as compatible.
@gaborrell
Copy link
Author

Hi @tchebb ,

  1. 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
Copy link
Owner

tchebb commented Sep 8, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants