Thingy beacon - malformed packet?

[Richard D.]

I think there's a problem with the beacon advertisement sent by Thingy52.  I'm seeing the problem in my own PC code and also air sniffer.  The advertising data packet looks like this:

0x02 0x01 0x06 0x03 0x03 0xaa 0xfe 0x13 0x16 0xaa 0xfe 0x10 0xee 0x03 0x67 0x6f 0x6f 0x2e 0x67 0x6c 0x2f 0x70 0x49 0x57 0x64 0x69 0x72 0x00

Breaking the packet down by advertising fields we get:

0x02 0x01 0x06
0x03 0x03 0xaa 0xfe
0x13 0x16 0xaa 0xfe 0x10 0xee 0x03 0x67 0x6f 0x6f 0x2e 0x67 0x6c 0x2f 0x70 0x49 0x57 0x64 0x69 0x72
0x00

The first 3 fields are a total of 27 bytes, but the transmitted packet is 28 bytes.  That last 0 byte would be the length of the 4th field which doesn't exist.

There was another report of malformed packet 2 years ago which may be the same thing: here

[Håkon Alseth]

Hi,

 

I cannot see that this is a corrupt frame. The PDU length is 34; 6 byte address and 28 byte adv data (where your eddystone URL payload starts from 0x10 0xee ...).

If you are thinking of the 0x00 byte at the end, this looks to be a zero-termination of the string.

 

Best regards,

Håkon

 

[Richard D.]

The relevant Bluetooth specification is the Core specification, Volume 3, Part C, Section 11 "Advertising and Scan Response Data Format".

Advertising data is a variable length payload consisting of a series of structures. Each structure contains 3 fields, a length byte, a type byte and length-1 data bytes.

The beacon packet consists 3 properly formatted advertising structures and one improperly formatted structure:

0x02 0x01 0x06
     Length = 2, type = 1 (flags), and a single flags byte
0x03 0x03 0xaa 0xfe
     Length = 3, type = 3 (list of 16-bit UUID's), two bytes 0xFEAA indicating Eddystone URL
0x13 0x16 0xaa 0xfe 0x10 0xee 0x03 0x67 0x6f 0x6f 0x2e 0x67 0x6c 0x2f 0x70 0x49 0x57 0x64 0x69 0x72
   Length = 19, type = 22 (service data), 18 bytes of service data
0x00
   Length = 0, rest of the structure is missing.

Looking at the code, the problem is perhaps in m_get_adv_packet() function of advertiser_beacon_timeslot.c

It's not particularly egregious, but it is incorrect and I thought Nordic developers would want to know.

[Håkon Alseth]

Hi,

 

I believe you're right. There's a bug here in the implementation that causes a zero to be added at the end of the packet.

I believe that this line in advertiser_beacon_timeslot.c should be moved to line 119, as there are three bytes that should be excluded from the length.

Could you try this and see if this sorts it out at your end?

 

Best regards,

Håkon

[Richard D.]

Hi Håkon,

Yes, your fix works and the packet length is now correct.

Richard