Allowing multiple Bluetooth VSC contrib layers to coexist (OGF 0x3F opcode collisions)

[antoniovazquezblanco]

Context

Bluetooth HCI vendor-specific commands (VSCs) all live under OGF 0x3F, and each vendor numbers its own OCFs independently. Those numbers overlap across vendors, and a VSC frame on the wire carries no vendor identifier only the opcode.

This means that two contrib VSC layers can legitimately bind different packet classes to the same (ogf, ocf) / command‑complete opcode.

This was noted while adding Espressif and Zephyr VSCs:

Opcode	bluetooth_vsc_zephyr	bluetooth_vsc_espressif
0xFC01	Read Version Info	Read Memory
0xFC02	Read Supported Commands	Write Memory

This makes some tests fail, that has been mitigated by explicitly parsing the packets in the tests instead of relaying on auto-dissection. It seemed like good enough to have the tests, both vendor definitions and allowing the user to work with a single vendor loaded.

Question / Options / Ideas

While developing tools, it may be interesting to load different VSCs and to have them correctly auto-dissected.

I am unsure if the complexity would be worth it and/or what solution you may find better suited. I am also possibly missing something and you may be able to point me in the right direction!

Here are some ideas:

1. Leave as is: The user will have to work with only one vendor and that is the end of it, Tests will need partial manual parsing...
2. Isolate test campaigns: Fix the tests loading contrib layers to run in separate process/binding/reset registry between campaing. Only fixes the manual parsing in tests, The user still will only be able to use a single vendor per scapy session...
3. Use dispatch_hook: I can modify the Bluetooth layer to use a dispatch hook in this case. That is far from ideal because although right now we may be able to distinguish between the existing cases, the payloads are too short and to fuzzy to really pull it off in the long term, I think.
4. Conf/context based: Each socket is expected to only handle one vendor. If there is a socket context memory, we may use that context to know wich vendor corresponds to that socket. If an user sends vendor A packets via a socket, it is expected to decode responses as vendor A.

Any ideas guys?
Thanks!

[antoniovazquezblanco]

@XenoKovah may be interested in following this issue :)