feat(bt) - Enable use of RESERVED bits in COD (IDFGH-13374)

[WebDust21]

This is a very niche-case patch, one that most people should never have need to bother with.

But in my case, trying to make a replacement for an obsolete Bluetooth board, I ran into an issue with a nonstandard use of the BT COD field: the two low "reserved" bits were used! Without access to the controlling firmware (and having to maintain compatibility with the thousands of "obsolete Bluetooth boards" in the field which will not function without said "reserved" bits being transmitted in the outgoing COD), this is the neatest solution to the problem.

I did a deep dive straight into the Bluedroid stack, and found exactly where (amongst the multiple unnecessary data type changes the provided COD went through) the two bits were getting lost. The very simple changes here were successful in allowing the ESP32 to work as a drop-in replacement for the obsolete board.

[CLAassistant]

All committers have signed the CLA.

[github-actions]

Warnings

⚠️

Some issues found for the commit messages in this PR: the commit message "bt[feat] - enable use of RESERVED bits in COD": summary looks empty type/action looks empty the commit message "feat[bt] - enable use of RESERVED bits in COD": summary looks empty type/action looks empty the commit message "feat[bt] - enable use of RESERVED bits in COD": summary looks empty type/action looks empty Please fix these commit messages - here are some basic tips: follow Conventional Commits style correct format of commit message should be: <type/action>(<scope/component>): <summary>, for example fix(esp32): Fixed startup timeout issue allowed types are: change,ci,docs,feat,fix,refactor,remove,revert,test sufficiently descriptive message summary should be between 20 to 72 characters and start with upper case letter avoid Jira references in commit messages (unavailable/irrelevant for our customers) TIP: Install pre-commit hooks and run this check when committing (uses the Conventional Precommit Linter).

	Messages
📖	You might consider squashing your 3 commits (simplifying branch history).

👋 Hello WebDust21, we appreciate your contribution to this project!

---

📘 Please review the project's Contributions Guide for key guidelines on code, documentation, testing, and more.

---

🖊️ Please also make sure you have read and signed the Contributor License Agreement for this project.

---

Click to see more instructions ...

This automated output is generated by the PR linter DangerJS, which checks if your Pull Request meets the project's requirements and helps you fix potential issues.

DangerJS is triggered with each push event to a Pull Request and modify the contents of this comment.

Please consider the following:
- Danger mainly focuses on the PR structure and formatting and can't understand the meaning behind your code or changes.
- Danger is not a substitute for human code reviews; it's still important to request a code review from your colleagues.
- Resolve all warnings (⚠️ ) before requesting a review from human reviewers - they will appreciate it.
- Addressing info messages (📖) is strongly recommended; they're less critical but valuable.
- To manually retry these Danger checks, please navigate to the Actions tab and re-run last Danger workflow.

Review and merge process you can expect ...

We do welcome contributions in the form of bug reports, feature requests and pull requests via this public GitHub repository.

This GitHub project is public mirror of our internal git repository

1. An internal issue has been created for the PR, we assign it to the relevant engineer.
2. They review the PR and either approve it or ask you for changes or clarifications.
3. Once the GitHub PR is approved, we synchronize it into our internal git repository.
4. In the internal git repository we do the final review, collect approvals from core owners and make sure all the automated tests are passing.
- At this point we may do some adjustments to the proposed change, or extend it by adding tests or documentation.
5. If the change is approved and passes the tests it is merged into the default branch.
5. On next sync from the internal git repository merged change will appear in this public GitHub repository.

Generated by 🚫 dangerJS against 304a141

[esp-qing]

Hi, @WebDust21 ,Thank you for your submission! We really appreciate it. And there are two places that need to be modified:

1. Commit message: Suggest to modify it to fix(bt): Enable use of ......
2. There are three commits, suggest to merge them into one commit.

[WebDust21]

Hi, @WebDust21 ,Thank you for your submission! We really appreciate it. And there are two places that need to be modified:

1. Commit message: Suggest to modify it to `fix(bt): Enable use of ...... `

2. There are three commits, suggest to merge them into one commit.

I'm sorry, I'm not a Github whiz...I don't know how to do either of these.

from what I read, it should be easy for your side to "squash" the commits (I do not have the option).

I do not know how to change a commit message...although as this PR extends nonstandard functionality, I would consider this a "feature", and not necessarily a "fix".

[esp-qing]

from what I read, it should be easy for your side to "squash" the commits (I do not have the option).

I do not know how to change a commit message...although as this PR extends nonstandard functionality, I would consider this a "feature", and not necessarily a "fix".

1. I can't directly modify your commit message on GitHub. It needs to be modified on your side and changed to the correct format, otherwise it can't be merged.
2. According to the commit message format, this change should be considered a fix type.

You can modify it according to the following steps:

Run the command: git rebase -i 41dd1a351b4f8630a0b9dbdd87a6bf782094dd66
After entering the following interface, change the last two pick to s

:wq Save and exit to enter the following interface

Then modify the commit information like this:

:wq Save and exit, then push it.

[esp-qing]

But in my case, trying to make a replacement for an obsolete Bluetooth board, I ran into an issue with a nonstandard use of the BT COD field: the two low "reserved" bits were used! ...

Hi, @WebDust21 In the latest Bluetooth protocol, the two least significant bits are fixed to 0b00. Could you please tell me what the model of Bluetooth board are you using? And which version of the Bluetooth protocol are you referring to? Thank you!

[WebDust21]

from what I read, it should be easy for your side to "squash" the commits (I do not have the option).
I do not know how to change a commit message...although as this PR extends nonstandard functionality, I would consider this a "feature", and not necessarily a "fix".

1. I can't directly modify your commit message on GitHub. It needs to be modified on your side and changed to the correct format, otherwise it can't be merged.

2. According to the commit message format, this change should be considered a fix type.

You can modify it according to the following steps:

Run the command: git rebase -i 41dd1a351b4f8630a0b9dbdd87a6bf782094dd66 After entering the following interface, change the last two pick to s :wq Save and exit to enter the following interface Then modify the commit information like this:

:wq Save and exit, then push it.

Thank you for the instructions; they would work if I had forked a local copy of the entire ESP-IDF to my computer. However, I just made the edits from Github.com, with no local copy--and as such, there is no place to run the commands.

But in my case, trying to make a replacement for an obsolete Bluetooth board, I ran into an issue with a nonstandard use of the BT COD field: the two low "reserved" bits were used! ...

Hi, @WebDust21 In the latest Bluetooth protocol, the two least significant bits are fixed to 0b00. Could you please tell me what the model of Bluetooth board are you using? And which version of the Bluetooth protocol are you referring to? Thank you!

Like I mentioned in the very opening comment, this is NONSTANDARD use of the two low "reserved" bits, as required for a compatibility project. This is for SPP mode (Bluetooth Classic) on an original ESP32; it is not BLE in any way, shape or form.
For whatever reason, the designers of the existing system set the two least significant bits (RESERVED bits) to 0b01--and if the ESP32 doesn't broadcast the COD with the two LSBs set to 0b01, it will be completely ignored by the existing system.

I've tested the modifications here as fully functional in getting the ESP32 to broadcast the necessary Bluetooth COD (although the "read COD" still incorrectly returns the LSBs as 0b00 for some reason. Need to dig into that further.)

[esp-qing]

Hi, @WebDust21 You don’t need to modify it anymore.. But in the original implementation, reserved_2 is not part of the minor class and is always set to 0. With your fix, reserved_2 may be non-zero, which changes the API behavior and affects users who don't want to overwrite reserved-2.

So after your commit, I made some changes to extend the functionality of the current API so that the previous API behavior does not change and allow users who want to set the reserved_2 to use the new esp_bt_cod_mode_t code.

[WebDust21]

Can I see the changes to the code?

It's worth noting that the Bluetooth device scan does return the "reserved_2" bits--which is how I was able to determine that the units used a nonstandard Bluetooth COD. It just didn't allow setting a COD with those bits used, nor can I read back a hacked COD set (although it does work when set).

[esp-qing]

@WebDust21 I‘m sorry that you can't see the changed code for now. The changes have been merged into the internal repository, but it will take a few days to see the updates on GitHub.