AnsweredAssumed Answered

Multiple race conditions and bugs in SOCKD

Question asked by Fredriksson.Mathias on Nov 20, 2016
Latest reply on Jun 26, 2017 by Christopher Karle
The SOCKD implementation suffers from many race conditions and bugs which makes it impossible to make robust applications without forcibly rebooting the WiFi module when it's not performing as expected.

Problems & bugs:

1. Data from client can appear before WIND (Client connected, now in Data Mode) if the client disconnects quickly:

    Hello from socket!\r\n
    \r\n+WIND:61:Incoming Socket Client:192.168.0.10\r\n
    \r\n+WIND:60:Now in Data Mode\r\n
    \r\n+WIND:59:Back to Command Mode\r\n
    \r\n+WIND:62:Socket Client Gone:192.168.0.10\r\n

2. Large messages can cause hard fault when in command mode with a connected client and entering data mode (+WIND:8:Hard Fault:CW1200RxPrs: r0 00000070, r1 00000078, r2 00000068, r3 B3E51B1F, r12 00000002, lr 08016365, pc 080163A4, psr 21000000)

3. Closing SOCKD server (AT+S.SOCKD=0) when a large message is pending can cause SOCKD to not respond even when enabled (AT+S.SOCKD=32000) until WiFi module is rebooted.

4. Entering data mode at the same time a client disconnects can cause a loss of WIND 62 (Socket client gone)

5. Entering command mode as a client connects leaves "at+s." in the buffer and prevents WINDs from arriving, "at+s." also takes ~500ms to take effect which means you have to perform arbitrary waiting and checking if you have actually exited command mode or not, taking care to clear the "at+s." with a "\r\n" if you did not receive a WIND.

6. Client connection during AT command prevents AT command from completing (see my other thread: Incoming Socket Client during AT command (HTTPGET))


Suggestion: Remove (or disable with option) Data/Command mode

This mode results in nondeterministic behavior. Instead, notifying through the UART that there is pending data and letting the application read/write N bytes of data through AT commands would solve many issues. This means we can trust the guarantees of AT command behavior instead of trying to handle all the race conditions of the Data/Command mode.

This would also fix the trustability issue of Data Mode, what I mean is that there's no way to know if data is coming from the socket client or from the WiFi module (socket client could be sending forged +WIND:xx messages).

Outcomes