RX packets with invalid length

[twvd]

I've been receiving packets from rbc_mesh_event_get (RBC_MESH_EVENT_TYPE_CONFLICTING_VAL) with a valid register number, but an invalid data length (249) and an unknown BLE source address. This usually occurs with a high volume of traffic on the mesh.

To illustrate this, see the following packet (captured in vh_rx):

p_packet	0x20002A50 (g_packet_pool + 80)	R6	mesh_packet_t *	
    header	<struct>	0x20002A50	ble_packet_header_t	
        type	'\0' (0x00)	0x20002A50	uint8_t	
        _rfu1	'\0' (0x00)	0x20002A50	uint8_t	
        addr_type	'.' (0x01)	0x20002A50	uint8_t	
        _rfu2	'\0' (0x00)	0x20002A50	uint8_t	
        length	'\a' (0x07)	0x20002A51	uint8_t	
        _rfu3	'\0' (0x00)	0x20002A52	uint8_t	
    addr	<array>"ÇÊEe*t"	0x20002A53	uint8_t[6]	
        [0]	'Ç' (0xC7)	0x20002A53	uint8_t	
        [1]	'Ê' (0xCA)	0x20002A54	uint8_t	
        [2]	'E' (0x45)	0x20002A55	uint8_t	
        [3]	'e' (0x65)	0x20002A56	uint8_t	
        [4]	'*' (0x2A)	0x20002A57	uint8_t	
        [5]	't' (0x74)	0x20002A58	uint8_t	
    payload	<array>""	0x20002A59	uint8_t[31]	
        [0]	'\0' (0x00)	0x20002A59	uint8_t	
        [1]	'.' (0x16)	0x20002A5A	uint8_t	
        [2]	'ä' (0xE4)	0x20002A5B	uint8_t	
        [3]	'þ' (0xFE)	0x20002A5C	uint8_t	
        [4]	'©' (0xA9)	0x20002A5D	uint8_t	
        [5]	'*' (0x2A)	0x20002A5E	uint8_t	
        [6]	'.' (0x03)	0x20002A5F	uint8_t	
        [7]	'\0' (0x00)	0x20002A60	uint8_t	
        [8]	'u' (0x75)	0x20002A61	uint8_t	
        [9]	'a' (0x61)	0x20002A62	uint8_t	
        [10]	'Ð' (0xD0)	0x20002A63	uint8_t	
        [11]	'²' (0xB2)	0x20002A64	uint8_t	
        [12]	'â' (0xE2)	0x20002A65	uint8_t	
        [13]	'\f' (0x0C)	0x20002A66	uint8_t	
        [14]	'l' (0x6C)	0x20002A67	uint8_t	
        [15]	'.' (0x02)	0x20002A68	uint8_t	
        [16]	'.' (0x01)	0x20002A69	uint8_t	
        [17]	'.' (0x06)	0x20002A6A	uint8_t	
        [18]	'.' (0x02)	0x20002A6B	uint8_t	
        [19]	'Ø' (0xD8)	0x20002A6C	uint8_t	
        [20]	'.' (0x05)	0x20002A6D	uint8_t	
        [21]	'.' (0x01)	0x20002A6E	uint8_t	
        [22]	'Ù' (0xD9)	0x20002A6F	uint8_t	
        [23]	'>' (0x3E)	0x20002A70	uint8_t	
        [24]	'.' (0x03)	0x20002A71	uint8_t	
        [25]	'Ù' (0xD9)	0x20002A72	uint8_t	
        [26]	'>' (0x3E)	0x20002A73	uint8_t	
        [27]	'.' (0x03)	0x20002A74	uint8_t	
        [28]	'+' (0x2B)	0x20002A75	uint8_t	
        [29]	'*' (0x2A)	0x20002A76	uint8_t	
        [30]	'Õ' (0xD5)	0x20002A77	uint8_t	

p_adv_data	0x20002A59 (g_packet_pool + 89)	R4	mesh_adv_data_t *	
    adv_data_length	'\0' (0x00)	0x20002A59	uint8_t	
    adv_data_type	'.' (0x16)	0x20002A5A	uint8_t	
    mesh_uuid	65252	0x20002A5B	uint16_t	
    handle	10921	0x20002A5D	uint16_t	
    version	3	0x20002A5F	uint16_t	
    data	<array>"<snip>"	0x20002A61	uint8_t[23]	
        ...snip, see above...

Call stack:

The BLE-address (c7 ca 45 65 2a 74) is unknown in my test setup. It is always the same, even though my test setup has about 12 nodes.
Apparantly, this packet gets through all the error checks in the mesh code and ends up in the event queue with a data length of 249 because adv_data_length here is 0 and later the length is calculated like this in vh_rx:

evt.params.rx.data_len = p_adv_data->adv_data_length - MESH_PACKET_ADV_OVERHEAD;

Unfortunately, I haven't been able to trace this condition all the way back to radio_control (yet) to see if this comes out of the radio like this or it is memory corruption somewhere, because I'm not sure how to break the code there on this condition. However, because I can reproduce this easely and the packet index differs every time, I suspect it comes out of the radio like this.

So, my questions are;
What could this packet be?
What's up with the mysterious BLE address?
How come the mesh puts this, seemingly invalid due to miscalculated length, packet into the event queue to be processed like nothing is wrong? How is the error checking done?

[trond-snekvik]

Looks like you may have some strange packets coming in..
Since your length field only includes the 0 at the beginning of the payload, I'm guessing the rest of the packet is uninitialized memory from previous uses of the same packet memory. Does the first bytes of payload ([0x75, 0x61, 0xd0...]) look familiar?

Having a single 0 byte AD data structure is technically legal according to the BLE spec, but shouldn't be produced by any mesh device. Could this be some other BLE device in your vicinity?

I'll mark this issue as a bug, as those packets shouldn't make it all the way to your application anyway. The correct fix is changing transport_control.c line 372 to
if (p_mesh_adv_data != NULL && p_mesh_adv_data->adv_data_length >= MESH_PACKET_ADV_OVERHEAD), alternatively a similar fix here

[twvd]

Since we produce quite a few BLE devices nearby in the building it could very well be a non-mesh device producing this. I'll apply the fix you described.

I'm curious though - what happens to packets where the first byte does exceed MESH_PACKET_ADV_OVERHEAD? Is there any secondary error checking to confirm the packet is actually a valid mesh packet to prevent the bogus data propagating over the mesh?

[trond-snekvik]

The radio control module uses the hardware CRC check as per the BLE specification, to remove any on-air bitflip errors, which are quite common. We also search for the correct AD type, with a Nordic-owned 16 bit service UUID, and ensure that we don't go beyond the max length (causing overflow) over in mesh_packet.c.