EIRData parsing error: "0 is not a valid ADType"

[martin-flaska]

Sporadically I get this unhandled exception in EIRData.decode / Packet.decode methods.

Apr 29 12:55:40 intercom-00056 gas-daemon[31223]: An exception occurred asynchronously: {'message': 'Exception in callback Mgmt.reader()', 'exception': ValueError('0 is not a valid ADType'), 'handle': <Handle Mgmt.reader()>}
                                                  Traceback (most recent call last):
                                                    File "/usr/lib/python3.10/asyncio/events.py", line 80, in _run
                                                      self._context.run(self._callback, *self._args)
                                                    File "/usr/lib/python3.10/site-packages/btsocket/btmgmt_callback.py", line 46, in reader
                                                      pkt = btmgmt_protocol.reader(data)
                                                    File "/usr/lib/python3.10/site-packages/btsocket/btmgmt_protocol.py", line 1055, in reader
                                                      cmd_params = event_frame.decode(evt_params)
                                                    File "/usr/lib/python3.10/site-packages/btsocket/btmgmt_protocol.py", line 238, in decode
                                                      data_type.decode(pkt[pointer:pointer + param.width])
                                                    File "/usr/lib/python3.10/site-packages/btsocket/btmgmt_protocol.py", line 197, in decode
                                                      self.value[ADType(data_type)] = data[data_start:data_end]
                                                    File "/usr/lib/python3.10/enum.py", line 385, in __call__
                                                      return cls.__new__(cls, value)
                                                    File "/usr/lib/python3.10/enum.py", line 710, in __new__
                                                      raise ve_exc
                                                  ValueError: 0 is not a valid ADType

I tried to get more logs and data on which this happen - see my commit

Jun 18 14:04:08 intercom-00057 gas_daemon[832]: Packet.decode: failed to decode eir_data as EIRData. Offset: 14, width: 65535, pkt: 6d 46 2d 13 b1 b0 01 9c 00 00 00 00 1f 00 02 01 06 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 f0 ff. Error: EIRData.decode: Invalid ADType, data len: 31, data: 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 f0 ff

I was not able to parse data before 1b 00 ... f0 ff problematic advertisement chunk. There seems to be one potentially valid chunk 02 01 06 (IncompleteUUID16ServiceList ?). But I observed this happens on specific device locations, so might be related to some unsupported BT device.

Any ideas?

[ukBaz]

Sorry, there isn't anything the immediately springs to mind on this.

Could it be the parsing of the data is falling over before this part?

[ukBaz]

I took another look at this today, including asking copilot some questions to see if it had any great insight that we were missing. This is what it came up with:

---

Yes, you're absolutely on the right track—spotting that AD type 0x00 isn't officially defined in the Bluetooth Assigned Numbers makes this a strong clue. In standard Bluetooth specifications, AD type 0x00 is reserved and shouldn't be used to encode meaningful data. So seeing it in the wild like this might indicate one of a few possibilities:

1. Vendor-Specific Encoding:
   Some manufacturers define their own custom fields and may repurpose undefined AD types like 0x00 for proprietary data formats. In these cases, you'd need access to vendor documentation or reverse engineering to make sense of it.

2. Malformed or Placeholder Data:
   It could be a buggy implementation or a placeholder left unintentionally—especially if the following bytes are all 00s, which might just be padding or uninitialized memory.

3. Obfuscation or Obsolete Use:
   In rare cases, legacy or obfuscated protocols might use reserved types for internal signaling not meant to conform to the spec.

Your observation that the 0x1B correctly matches the field length supports the idea that the packet structure is otherwise intact—it’s just this field’s type that doesn’t match anything known in the standard spec.

If you're debugging or analyzing these packets further, you might:

• Log a warning if unknown AD types appear.
• Add a decoding fallback for type == 0x00 to capture and store the raw bytes for further inspection.

---

You might also want to use wireshark to analyse the BT log and see what it makes of the data you're seeing.

[martin-flaska]

Thank you for the answer. I did not indentify that BT device yet, I have just a remote access to it and cannot do more experiments now, as there is onging test on that device, so I cannot do more now.
I send a fix for this issue, so it won't cause app crash now and skips problematic data.
Also, it would be fine to show device address in the logs, bot I did not find any (easy) way to do that. If you have an idea, please share your idea or update the code ;).

[martin-flaska]

One more log from same source file (reader(pckt)), address 68:5E:1C:55:CE:C1 (probably some Texas Istruments device)

2025-06-19 19:49:55,053 [  ERROR] btsocket.btmgmt_protocol: Packet.decode: failed to decode eir_data as EIRData. Offset: 14, width: 65535, pkt: c1 ce 55 1c 5e 68 01 9b 00 00 00 00 1f 00 02 01 06 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 f0 ff. Error: EIRData.decode: Invalid ADType: 0x00, data len: 31, data: 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 f0 ff

2025-06-19 19:49:55,057 [  ERROR] btsocket.btmgmt_protocol: --Socket read <event_code=DeviceFoundEvent, controller_idx=0, param_len=45> <address=68:5E:1C:55:CE:C1, address_type=[BREDR], rssi=155, flags=0, eir_data_length=31, eir_data={ManufacturerData: b'\x06\x00\x01\t \x02\xc2\xed\xbd7;*\xfb\xfe#\x91P\x18\xe2\xf4Y\xa5;&\xf5t\xd6Wo'}>

The manufacturer data is: "06 00 01 09 20 02 c2 ed bd 37 3b 2a fb fe 23 91 50 18 e2 f4 59 a5 3b 26 f5 74 d6 57 6f"
No idea what device it could be...

[ukBaz]

Although this appears to be a Texas Instruments chipset, the manufacturing data suggests it’s actually a Microsoft-defined beacon. Manufacturer ID lookup can be found here:

https://www.bluetooth.com/specifications/assigned-numbers/

According to Microsoft’s documentation, the format identifies it as a Windows 10 Desktop:

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-cdp/77b446d0-8cea-4821-ad21-fabdf4d9a569

If this truly is a Windows 10 machine, I'm inclined to think the code might be misinterpreting the data, rather than assuming Microsoft is sending malformed packets. That said, I always love it when I'm proved right 🙂

[martin-flaska]

If this truly is a Windows 10 machine, I'm inclined to think the code might be misinterpreting the data, rather than assuming Microsoft is sending malformed packets.

Thank you for the info and investigation ;). Not sure I understand what you exactly mean. For now, I have prepared some hot fix for EIRData.decode and Packet.decode which just adds an exception handler for unhandled exception / missing enum value for 0 AD type and skips this chunk. Which might not be the best fix, as it hides some incoming data that could be parsed in upper layer, but at least it does not crash.
What is your idea how should be this addressed?

#14

I could probably collect more logs, if it helps you to address this problem, as this is not so hard to reproduce. It happens several times a day.
Also, I found another device with similar address (same manufacturer): 3C:E4:B0:7E:65:1B. Probably also some Windows device nearby.

Here are some logs I captured remotely (I can investigate more once I get to our office/labs this week, where I could get more info):

bt-logs.txt

[martin-flaska]

I'm inclined to think the code might be misinterpreting the data, rather than assuming Microsoft is sending malformed packets.

This might maybe require some ADType enum extension, with some proprietary enum id for type 0, if this is a common practice for some companies. But in any case, the library should properly handle this, either skip such data or identify it as some vendor specific / non-standard.

[ukBaz]

I think it would be useful if I could get a couple examples of the failing packet that gets passed to

python-btsocket/btsocket/btmgmt_protocol.py

Line 1044 in e1f8d0c

def reader(pckt):

and then I can run some debug to better understand what is going wrong.

Would that be possible?

[martin-flaska]

Sure, I captured a few more events, using the version with my fix + logs from def reader(pckt): function when this problem happens:
(see the latest commit of this branch)

2025-06-24 09:47:45,216 - btsocket.btmgmt_protocol - ERROR - Packet.decode: failed to decode eir_data as EIRData. Offset: 14, width: 65535, pkt: e4 a6 0c 98 b8 f4 01 9d 00 00 00 00 1f 00 02 01 06 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 f0 ff. Error: EIRData.decode: Invalid ADType: 0x00, data len: 31, data: 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 f0 ff
2025-06-24 09:47:45,216 [  ERROR] btsocket.btmgmt_protocol: Packet.decode: failed to decode eir_data as EIRData. Offset: 14, width: 65535, pkt: e4 a6 0c 98 b8 f4 01 9d 00 00 00 00 1f 00 02 01 06 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 f0 ff. Error: EIRData.decode: Invalid ADType: 0x00, data len: 31, data: 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 f0 ff
2025-06-24 09:47:45,222 - btsocket.btmgmt_protocol - ERROR - --Socket read <event_code=DeviceFoundEvent, controller_idx=0, param_len=45> <address=F4:B8:98:0C:A6:E4, address_type=[BREDR], rssi=157, flags=0, eir_data_length=31, eir_data={ManufacturerData: b'\x06\x00\x01\t \x02\x19\x90\xc3<\xd4\xbb\xef[\xb3#E\xea\xd8\xfbl\xb6:\xc2(\x9c\xd7\xfe\xff'}>
2025-06-24 09:47:45,222 [  ERROR] btsocket.btmgmt_protocol: --Socket read <event_code=DeviceFoundEvent, controller_idx=0, param_len=45> <address=F4:B8:98:0C:A6:E4, address_type=[BREDR], rssi=157, flags=0, eir_data_length=31, eir_data={ManufacturerData: b'\x06\x00\x01\t \x02\x19\x90\xc3<\xd4\xbb\xef[\xb3#E\xea\xd8\xfbl\xb6:\xc2(\x9c\xd7\xfe\xff'}>

2025-06-24 09:51:59,821 - btsocket.btmgmt_protocol - ERROR - Packet.decode: failed to decode eir_data as EIRData. Offset: 14, width: 65535, pkt: e4 a6 0c 98 b8 f4 01 9e 00 00 00 00 1f 00 02 01 06 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 f0 ff. Error: EIRData.decode: Invalid ADType: 0x00, data len: 31, data: 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 f0 ff
2025-06-24 09:51:59,821 [  ERROR] btsocket.btmgmt_protocol: Packet.decode: failed to decode eir_data as EIRData. Offset: 14, width: 65535, pkt: e4 a6 0c 98 b8 f4 01 9e 00 00 00 00 1f 00 02 01 06 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 f0 ff. Error: EIRData.decode: Invalid ADType: 0x00, data len: 31, data: 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 f0 ff

2025-06-24 09:51:59,832 - btsocket.btmgmt_protocol - ERROR - --Socket read <event_code=DeviceFoundEvent, controller_idx=0, param_len=45> <address=F4:B8:98:0C:A6:E4, address_type=[BREDR], rssi=158, flags=0, eir_data_length=31, eir_data={ManufacturerData: b'\x06\x00\x01\t \x02\xa6W#\xd3|\xf4o\xe2\xdc\x9e\xba\x98\x99\xf6\r\xf9\xa5\xc4e&\xc8\x94N'}>
2025-06-24 09:51:59,832 [  ERROR] btsocket.btmgmt_protocol: --Socket read <event_code=DeviceFoundEvent, controller_idx=0, param_len=45> <address=F4:B8:98:0C:A6:E4, address_type=[BREDR], rssi=158, flags=0, eir_data_length=31, eir_data={ManufacturerData: b'\x06\x00\x01\t \x02\xa6W#\xd3|\xf4o\xe2\xdc\x9e\xba\x98\x99\xf6\r\xf9\xa5\xc4e&\xc8\x94N'}>

2025-06-24 09:53:21,908 - btsocket.btmgmt_protocol - ERROR - Packet.decode: failed to decode eir_data as EIRData. Offset: 14, width: 65535, pkt: e4 a6 0c 98 b8 f4 01 9c 00 00 00 00 1f 00 02 01 06 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 f0 ff. Error: EIRData.decode: Invalid ADType: 0x00, data len: 31, data: 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 f0 ff
2025-06-24 09:53:21,908 [  ERROR] btsocket.btmgmt_protocol: Packet.decode: failed to decode eir_data as EIRData. Offset: 14, width: 65535, pkt: e4 a6 0c 98 b8 f4 01 9c 00 00 00 00 1f 00 02 01 06 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 f0 ff. Error: EIRData.decode: Invalid ADType: 0x00, data len: 31, data: 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 f0 ff

2025-06-24 09:53:21,916 - btsocket.btmgmt_protocol - ERROR - --Socket read <event_code=DeviceFoundEvent, controller_idx=0, param_len=45> <address=F4:B8:98:0C:A6:E4, address_type=[BREDR], rssi=156, flags=0, eir_data_length=31, eir_data={ManufacturerData: b'L\x00\x12\x02\x00\x00'}>
2025-06-24 09:53:21,916 [  ERROR] btsocket.btmgmt_protocol: --Socket read <event_code=DeviceFoundEvent, controller_idx=0, param_len=45> <address=F4:B8:98:0C:A6:E4, address_type=[BREDR], rssi=156, flags=0, eir_data_length=31, eir_data={ManufacturerData: b'L\x00\x12\x02\x00\x00'}>

2025-06-24 09:56:32,111 - btsocket.btmgmt_protocol - ERROR - Packet.decode: failed to decode eir_data as EIRData. Offset: 14, width: 65535, pkt: e4 a6 0c 98 b8 f4 01 9c 00 00 00 00 1f 00 02 01 06 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 f0 ff. Error: EIRData.decode: Invalid ADType: 0x00, data len: 31, data: 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 f0 ff
2025-06-24 09:56:32,111 [  ERROR] btsocket.btmgmt_protocol: Packet.decode: failed to decode eir_data as EIRData. Offset: 14, width: 65535, pkt: e4 a6 0c 98 b8 f4 01 9c 00 00 00 00 1f 00 02 01 06 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 f0 ff. Error: EIRData.decode: Invalid ADType: 0x00, data len: 31, data: 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 f0 ff

2025-06-24 09:56:32,114 - btsocket.btmgmt_protocol - ERROR - --Socket read <event_code=DeviceFoundEvent, controller_idx=0, param_len=45> <address=F4:B8:98:0C:A6:E4, address_type=[BREDR], rssi=156, flags=0, eir_data_length=31, eir_data={ManufacturerData: b'L\x00\x12\x02\x00\x02'}>
2025-06-24 09:56:32,114 [  ERROR] btsocket.btmgmt_protocol: --Socket read <event_code=DeviceFoundEvent, controller_idx=0, param_len=45> <address=F4:B8:98:0C:A6:E4, address_type=[BREDR], rssi=156, flags=0, eir_data_length=31, eir_data={ManufacturerData: b'L\x00\x12\x02\x00\x02'}>

Pls, let me know if this is enough or you can modify the code / add more logs so I can retest.

[ukBaz]

I've found what appears to be a device with a similar signature to what you are seeing.

Using the data I captured, I've created a new test, which I've pushed to this branch:
main...issue13

To assist with diagnostics, I've added additional debug statement to the btmgmt_protocol module. With debugging enabled, the device of interest reports:

2025-06-24 21:43:07,778 - btsocket.btmgmt_protocol - DEBUG - Socket Packet: b'\x12\x00\x00\x00-\x00\xbc\x07CR\xef2\x02\xd9\x04\x00\x00\x00\x1f\x00\x1e\xff\x06\x00\x01\t "&\xfb\x84\xd3F+\ny\x18\xec\xcc\xd1%J\xe9\x9cJ\xf2\xeb\xe0\xffN\xfe'
2025-06-24 21:43:07,778 - btsocket.btmgmt_protocol - DEBUG - Decoding event_code as type EvtCode
2025-06-24 21:43:07,778 - btsocket.btmgmt_protocol - DEBUG - Decoding controller_idx as type Controller
2025-06-24 21:43:07,778 - btsocket.btmgmt_protocol - DEBUG - Decoding param_len as type ParamLen
2025-06-24 21:43:07,778 - btsocket.btmgmt_protocol - DEBUG - Decoding address as type Address
2025-06-24 21:43:07,779 - btsocket.btmgmt_protocol - DEBUG - Decoding address_type as type AddressTypeField
2025-06-24 21:43:07,779 - btsocket.btmgmt_protocol - DEBUG - Decoding rssi as type IntUL
2025-06-24 21:43:07,779 - btsocket.btmgmt_protocol - DEBUG - Decoding flags as type IntUL
2025-06-24 21:43:07,779 - btsocket.btmgmt_protocol - DEBUG - Decoding eir_data_length as type IntUL
2025-06-24 21:43:07,779 - btsocket.btmgmt_protocol - DEBUG - Decoding eir_data as type EIRData
2025-06-24 21:43:07,779 - btsocket.btmgmt_protocol - DEBUG - Socket read <event_code=DeviceFoundEvent, controller_idx=0, param_len=45> <address=32:EF:52:43:07:BC, address_type=[LEPublic], rssi=217, flags=4, eir_data_length=31, eir_data={ManufacturerData: b'\x06\x00\x01\t "&\xfb\x84\xd3F+\ny\x18\xec\xcc\xd1%J\xe9\x9cJ\xf2\xeb\xe0\xffN\xfe'}>

While this debug output is quite verbose, it’s been useful for capturing the raw input to btmgmt_protocol.reader, as reflected in the new test.

Could you capture the Socket Packet debug output for your problematic device? It would help me determine whether the issue lies in how we're parsing the data or if the data itself is malformed.

Thanks!

[martin-flaska]

I got only one event today, HTH:

2025-06-25 13:13:53,432 - btsocket.btmgmt_protocol - ERROR - Socket Packet: b'\x12\x00\x00\x00-\x00\xd6\xbeEJ\xe7h\x01\x9e\x00\x00\x00\x00\x1f\x00\x02\x01\x06\x1b\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\xf0\xff'

2025-06-25 13:13:53,435 - btsocket.btmgmt_protocol - ERROR - Packet.decode: failed to decode eir_data as EIRData. Offset: 14, width: 65535, pkt: d6 be 45 4a e7 68 01 9e 00 00 00 00 1f 00 02 01 06 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 f0 ff. Error: EIRData.decode: Invalid ADType: 0x00, data len: 31, data: 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 f0 ff

2025-06-25 13:13:53,438 - btsocket.btmgmt_protocol - ERROR - Socket read <event_code=DeviceFoundEvent, controller_idx=0, param_len=45> <address=68:E7:4A:45:BE:D6, address_type=[BREDR], rssi=158, flags=0, eir_data_length=31, eir_data={Flags: b'\x1a', TXPower: b'\x0c', ManufacturerData: b'L\x00\x10\x07<\x1f\xc2\xbe\xa7M\x18'}>

[martin-flaska]

and one more from this morning:

2025-06-26 06:09:15,513 - btsocket.btmgmt_protocol - ERROR - Socket Packet: b'\x12\x00\x00\x00I\x00[\xe9={\x10\xb4\x01\x9f\x00\x00\x00\x00;\x00\x02\x01\x06\x1b\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\xf0\xff\x12\tlime-931303585874\x05\x12\x06\x00\x06\x00\x02\n\x00'

2025-06-26 06:09:15,515 - btsocket.btmgmt_protocol - ERROR - Packet.decode: failed to decode eir_data as EIRData. Offset: 14, width: 65535, pkt: 5b e9 3d 7b 10 b4 01 9f 00 00 00 00 3b 00 02 01 06 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 f0 ff 12 09 6c 69 6d 65 2d 39 33 31 33 30 33 35 38 35 38 37 34 05 12 06 00 06 00 02 0a 00. Error: EIRData.decode: Invalid ADType: 0x00, data len: 59, data: 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 f0 ff 12 09 6c 69 6d 65 2d 39 33 31 33 30 33 35 38 35 38 37 34 05 12 06 00 06 00 02 0a 00

2025-06-26 06:09:15,518 - btsocket.btmgmt_protocol - ERROR - Socket read <event_code=DeviceFoundEvent, controller_idx=0, param_len=73> <address=B4:10:7B:3D:E9:5B, address_type=[BREDR], rssi=159, flags=0, eir_data_length=59, eir_data={ManufacturerData: b'L\x00\x12\x02\x00\x01'}>

[ukBaz]

I looked at your last example first

b'\x12\x00\x00\x00I\x00[\xe9={\x10\xb4\x01\x9f\x00\x00\x00\x00;\x00\x02\x01\x06\x1b\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\xf0\xff\x12\tlime-931303585874\x05\x12\x06\x00\x06\x00\x02\n\x00'

And the problem part in there is:

b'\x02\x01\x06\x1b\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\xf0\xff\x12\tlime-931303585874\x05\x12\x06\x00\x06\x00\x02\n\x00'

The first part is :

b'\x02\x01\x06'
which is fine it is setting the flags.

The problem part is:

b'\x1b\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\xf0\xff\x12\tlime-931303585874\x05\x12\x06\x00\x06\x00\x02\n\x00'

I think Lime Microsystems Ltd have just put this value in with the wrong endian. I leave the length value first but swap the endianness of the rest of it to:

b'\x1b\xff\xf0\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'

Now that’s a much more promising EIR data structure! Let’s break it down:

EIR Field Breakdown

EIR fields follow the format:

[Length][Type][Value...]

Let’s interpret the first few bytes:

• 0x1B = 27 → This field is 27 bytes long (including the type byte)
• 0xFF = Type: Manufacturer Specific Data
• 0xF0 0x02 = Company Identifier (little-endian) → 0x02F0 = 752

The remaining 24 bytes are the manufacturer-specific payload:

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

---

Company ID 0x02F0

Looking up Bluetooth SIG-assigned company identifiers:

• 0x02F0 (752) is registered to Lime Microsystems Ltd.

That matches the earlier "lime-931303..." device name — so this is almost certainly a Lime Microsystems BLE device.

---

Summary

Field	Value
Length	27 bytes
Type	0xFF (Manufacturer Specific Data)
Company ID	0x02F0 (Lime Microsystems Ltd.)
Payload	24 bytes of 0x00

This is a valid and well-formed Manufacturer Specific Data field.

---

Parser Behaviour

Based on that one example my conclusion is that:

• the btsocket parser handles valid EIR data correctly.
• The malformed data originates from the device (likely a Lime Microsystems product).
• Isolated the issue to a specific malformed advertising packet.

---

Next Steps

Even though the bug is upstream, it’s still valuable to make btsocket more robust. A parser that gracefully skips malformed fields is obviously more resilient in the wild and this makes btsocket more useful and helps others who encounter similar issues.

I'll look at the other example you posted to check that isn't finding a bug in parser. Assuming that is is also bad data, then I'll look at the fix you've created

[ukBaz]

The next one was a lot quicker when you know what you are looking for... Same issue.

I'll look at how to make the parser more resilient now I've got some test cases.