MatthewMenze
commented
4 years ago After additional digging into the library source code, the issue appears to be due to how incoming URC's are processed in this library.
In the poll() function incoming serial data is parsed until the first newline character, then from there it is checked for various URCs, and processed accordingly.
When processing a socket read, the library then sends a command to read the indicated socket data, then waits for a response from the LTE module with the socket data. While waiting for that, if additional packets come in, and cause the LTE module to transmit another +UUSOLI URC message, it will get eaten by the loop in socketRead that is waiting for a response from the USORD command sent.
This will cause data to exist on the LTE socket without the library knowing it is there, effectively rendering that socket unusable. Eventually if this happens enough, all available sockets are filled with data, but the library doesn't know to request it, and the whole thing locks up.
I think there is a few pieces required to fix this.
- Polling needs to be buffered. Ideally you would have an interrupt service routine handle any time there was data available on the line, and then push that into a buffer for the poll() function to iterate through and handle any commands stored within.
- There needs to be logic that handles unexpected data in the socketRead() function, and does something reasonable. Maybe flush all sockets data may be sitting on? (If it's caught here, it is probably fragmented/to late)
- Waiting for a response for up to 1 second in the socketRead() is probably going to cause headaches, especially if you are not using an interrupt or similar to grab and buffer data...A lot of new events could come down the pipe in a second.
I'm working implementing some sort of work around for this, but I'm not super familiar with the library, and may need to ditch this LTE Module entirely for the sake of my clients project.
nseidle
ROSW6341
The socket close handler reports the incorrect socket closing, and seems to be related so some sort of device crash.
I am using the LTE shield with a Metro M4 Airlift Express board, using the hardware serial interface.
My firmware starts up the device, then opens 1 UDP socket to periodically writes a small JSON to the server, this socket behaves as expected, and takes up socket 0 on the LTE module.
Next my firmware opens two additional TCP sockets, which each listen on a different port for periodic data packets, taking up sockets 1 & 2. These sockets are polled with the library function poll() on every program loop. They seem to read data correctly as I send out packets. However, upon the connection closing the library reports to the socket closed callback that socket 3 has closed. After a number of connection close events, it starts reporting socket 4, then 5, then 6. When it reports socket 5/6 it stops triggering the socket read callback. Then shortly after it seems to stop functioning entirely, and I get TCP errors on my transmitting device saying unable to connect. It seems the same socket value is given regardless of which port I send a packet to (IE, the socket reported to close is unrelated to which listening socket I hit)
This issue seems to be partially mitigated if I call socketClose() on the misreported socket. Although it will still crash with enough events.
Based on experimentation, I believe this is an issue of incorrectly tracking and handling socket events, causing resources to be incorrectly de-allocated as sockets are created and destroyed. Maybe this is related to the memory issues I see mentioned in other issues and commits?