Re: [lwip-users] netconn_connect returns OK when connection refused?

[Grant Edwards]

On 2022-04-12, Simon Goldschmidt <goldsimon@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