On 2022-04-12, Simon Goldschmidt <goldsi...@gmx.de> wrote: > >>> I'm running into a problem where netconn_connect always returns OK >>> immediately, even when the connection was refused by the server (it >>> replies to the SYN with a RST). Subsequent attempts to write to the >>> connection return -14 (ERR_RST) or -11 (ERR_CONN). > >>I'm still stumped by this. It's 100% reliable: netconn_connect() >>returns ERR_OK even though the server responded to the SYN >>with a RST. Subsequent writes to that connection fail. >> >>I get the same resutls using the socket api. The call to connect() >>returns 0, but then send() fails. >> >>Nobody else has seen this? > > No, but if you think this is a bug, please file a bug report!
After doing more investigation, I have a hard time believing it's a bug in the stack that nobody else has run into. It's just way too obvious. I think it's more likely a bug in my 'arch' code, but I'm having a hard time identifying something that would affect netconn_connect() but nothing else. I've discovered one more symptom. There was a "sleep" call immediately following the netconn_connect() call (the exact time didn't seem to matter). With the sleep call removed, the code that followed immediately after the call to netconn_connect() will exhibit unpredicatable behavior. My current theory is that the call to netconn_connect() is returning immediately instead of waiting for the TCP handshake to finish. When the handshake does finish the tcp thread is doing something that affects the stack of the thread that called netconn_connect(). If that thread is actaully running when that happens, the thread locks up or behaves unpredicatably. If that thread is blocked/asleep until after the TCP handshake actually finishes, then it can resume OK (even though it may have the wrong status). What's odd is that I can run as many TCP "servers" as I want (either blocking with one thread per connection or single-threaded with callbacks) along with UDP send/receive simultaneously in multiple threads with no problems. It's only the netconn_connect() call that seems to have problems. Any suggestions for "arch" features that are used only by (or differently by) netconn_connect() would be welcomed... -- Grant _______________________________________________ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
