Bluetooth Advertising Interval is variable-length (2, 3, or 4 bytes) in newer specs, not just 2 bytes

[XenoKovah]

Brief description

After I went to try and use PR #4612 for adding AdvData type 0x1A (Advertising Interval) I went and looked at the Bluetooth Core Specification Supplement (CSS) v12. I found that it's not just a single 2-byte value like it used to be (as of CSS v9 and earlier). It's now apparently either 2, 3, or 4 bytes long, depending on how large of a value they need to send.

Above and beyond this, the only sample I have for data of type 0x1A appears to be sending non-conforming data with a single byte rather than 2 bytes. This consequently leads to mis-parsing of subsequent AdvData fields by Scapy and Wireshark which assume a single 2 byte field. (Attached)
sample_test_type_0x1A_malformed.pcap.tar.gz

The solution (including handling non-spec packets) seems like it would be adjusting the interpretation of the field to the length given in the AdvData (which is the length of the single byte type (0x1A) + the length of the actual data). If that was done for 1-4 byte lengths it would handle spec-conformant and non-conformant packets.

@antoniovazquezblanco and I thought the maintainers might have some thoughts on how to handle this variable-length case (and whether you want to handle the spec-non-compliant 1 byte data case)?

Scapy version

a28d74a

Python version

3.13.1

Operating system

macOS 15.2

Additional environment information

No response

How to reproduce

I don't have any compliant packet samples but this is more a matter of specification interpretation.

Actual result

No response

Expected result

No response

Related resources

No response

[antoniovazquezblanco]

On top of wether scapy is interested in handling the non-conformant variant or not, if the answer to that is to not support non-conformant packages I would like to ask and think about the following:

Would it make sense to make scapy more "resilient" to this kind of packages by parsing the length, discarding that particular EIR and being able to parse the remaining bytes? Or would you prefer to leave as-is making it misinterpret the remaining packet information?

Thanks!