nRF52 Firmware: collision between data payload and reply-to-command

[chipaudette]

As discussed in this Tympan_Library issue: Tympan/Tympan_Library#105 (comment), there is the potential for garbled communications between the BLE module and the Tympan_Library.

NOMINAL OPERATION: The Tympan processor communicates with the BLE module over a UART serial link. Two styles of communication occur over this link:

1. Commands: The Tympan sends a command to the BLE module. The BLE module responds to the command with an "OK" or "FAIL" message. The Tympan's BLE library expects a response after every command except SEND or QUEUE.
2. Data: For data coming form a remote device (tablet/phone), the BLE module receives the payload and simply pushes the payload's bytes to the Tympan via the UART serial link. There's no header or footer, just the raw bytes.

POTENTIAL CONFUSION: Data from the tablet/phone can occur at any time. So, there is the potential for confused communications if data arrives from the tablet/phone during the time when the Tympan processor is, instead, expecting a reply to its recent command. If the Tympan processor is expecting an OK/FAIL message, but the byte stream doesn't start with "OK" or "FAIL", I believe that there will be a problem of some sort (without more analysis, I'm not sure what happens).

SPECIFIC VULNERABILITY: As of BLE firmware 0.4.1, I believe that:

• The vulnerable time begins when the Tympan starts sending the first byte of its command. At this point, the Tympan will not look for bytes the returning serial link until the full message is sent. The Tympan will only start looking for bytes again once it has finished sending the command string to the BLE module. At this point, the Tympan will be expecting that any bytes will be a reply (ie, an OK or FAIL message).
• The vulnerable time ends when the BLE module has received the CR that terminates the command message from the Tympan. At this point, the BLE module will parse the command string and (I believe) will not service any in-coming BLE data until the command parsing is complete and the OK/FAIL message has been sent.
• This vulnerability does not exist for the SEND or QUEUE commands because the Tympan BLE library does not look for a reply from these two commands. This vulnerability only exists when sending the other commands.

SOLUTION OPTIONS:

• Stop the Bytes: Change the BLE firmware to disallow sending BLE payloads to the Tympan as soon as any bytes are received from the Tympan. Continue the disallowed period until a CR is received (and the reply sent) or until a time-out.
• Use GPIO Pin as Control Flow: Change the Tympan library and change the BLE firmware to use a GPIO line as flow control when sending commands. When the Tympan wants to send a command, it raises the pin HIGH so that the BLE module will hold all BLE data until the Tympan decides that the transaction is finished and lowers the GPIO again.
• Smarter RecvReply(): Change the Tympan library recvReply() function so that it is smarter about the bytes that come in. We now know that the bytes might not actually be a reply to the recently-sent command. So, we could re-write this function acknowledging the possibility that a data payload might be present, not just an OK / FAIL response.

NEXT STEPS:

• None, until priority is increased.

Tag @cab-creare-com , @eyuan-creare

[chipaudette]

Separately, we have decided to move delay() statements from the transmit portion of the Tympan's BLE Library over into the firmware of the BLE module. As this allows the Tympan processor and the BLE unit to work more asynchronously, there is the possibility that we will increase the amount of time when we are vulnerable to the bug described above.

I'm just now working through the implications of the asynchronous behavior and its implications for system-wide behaviors.