Skip to content

More Bluetooth 5.0+ packets#4905

Open
sacca97 wants to merge 12 commits intosecdev:masterfrom
sacca97:master
Open

More Bluetooth 5.0+ packets#4905
sacca97 wants to merge 12 commits intosecdev:masterfrom
sacca97:master

Conversation

@sacca97
Copy link

@sacca97 sacca97 commented Feb 3, 2026

Introduces various stuff from Bluetooth 5.0+ plus some standardized field naming across packets for clarity and interoperability. Additionally covers an edge case in the HCI command handling.

What was added:

  • HCI_LE_Meta_Enhanced_Connection_Complete
  • HCI_Cmd_LE_Set_Extended_Advertising_Parameters
  • HCI_Cmd_LE_Set_Extended_Advertising_Data
  • HCI_Cmd_LE_Set_Advertising_Set_Random_Address
  • HCI_Cmd_LE_Set_Extended_Scan_Parameters
  • HCI_Cmd_LE_Set_Extended_Scan_Enable
  • HCI_Cmd_LE_Extended_Create_Connection
  • HCI_Cmd_LE_Set_Event_Mask (update 8-byte bitmask)

What was modified:

  • atype / oatype / datype --> own_addr_type, peer_addr_type, or addr_type.
  • address / paddr / daddr --> addr or peer_addr
  • HCI receive now checks r.code in (0x0e, 0x0f) to cope with commands such as "Create Connection" which is async and returns a "Pending" status.

I also added and executed the tests in bluetooth.uts

@polydroi
Copy link

polydroi commented Feb 4, 2026

Thanks for your pr. could you please revert all changes introduced from your code formatter.

@sacca97
Copy link
Author

sacca97 commented Feb 4, 2026

@polydroi sorry for that, should be good now

@sacca97
Copy link
Author

sacca97 commented Feb 10, 2026

Added relevant tests to bluetooth.uts

I did not add tests for, e.g., HCI_Cmd_LE_Set_Extended_Scan_Parameters, as the original version did not have them either.

@sacca97 sacca97 marked this pull request as ready for review February 10, 2026 13:00
ByteEnumField("patype", 0, {0: "public", 1: "random"}),
LEMACField("paddr", None),
ByteEnumField("atype", 0, {0: "public", 1: "random"}),
ByteEnumField("peer_addr_type", 0, {0: "public", 1: "random"}),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the reason for all the name changes. Are the old names incorrect?

The change of a field name might break existing applications.

Copy link
Author

@sacca97 sacca97 Mar 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@polybassa, the latest versions of the standard refer to these fields as *_address or *_address_type. I changed them because in Scapy, some packets used the standard terminology, while others did not. So it is mostly about coherence across all packets, but yes, the "correct" field name would be the longer one.

We can also stick with atype, patype, ... for all I care, as long as all packets use the same names. If this is the preferred direction I can update the PR, but it will still break some existing applications probably.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you use

deprecated_fields = {} # type: Dict[str, Tuple[str, str]]
to make the old fields redirect to the new ones ? You'll find many examples in the rest of Scapy.

Thanks !

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

Successfully merging this pull request may close these issues.

4 participants