Re: [lwip-users] How to force-close a netconn from the server side?

[Freddie Chopin]

On Wed, 2017-01-25 at 20:49 +0100, address@hidden wrote:
> In "specialities" like this one, the netconn API is (unfortunately) 
> sometimes incomplete as the "core" and socket APIs are more widely
> used.
> 
> While you don't have to "mess" with the "so_options" field, you'd
> have 
> to call "ip_set_option(conn->pcb.ip, optname)", which should work
> for 
> you but is still not a clean solution as accessing the "pcb" member
> of a 
> netconn should not be done by client code and should not be done from
> an 
> application thread (only from tcpip_thread).

Would any additions to the netconn API be accepted, or maybe the plan
is really to add a function or two to sockets to allow netconn-like
interface (with no copying) and then netconn would be deprecated?

Anyway - I've noticed something very very strange after a few more
hours of debugging and random changes (; If I force-close the client
(and listen) connections with "netconn_close()" + "netconn_delete()",
then most of the time everything works fine, only sometimes there is a
PCB (maybe more than one) stuck in TIME_WAIT state, but in this case I
just have to wait ~2 minutes and the problem is solved. This is the
first strange thing - why sometimes the PCBs stay in TIME_WAIT and
other times (like 90%) they don't. But I guess this is network-related. 
The second strange thing is much more interesting. It works only if I
introduce a small delay between close+delete and opening of new listen
connections (I'm using a multithreading system). Something like this
works:

for (5 client connections and 5 listen connections)
{
        netconn_close(connection[i]);
        netconn_delete(connection[i]);
}

distortos::ThisThread::sleepFor(std::chrono::seconds{1});

for (5 listen connections)
{
        listenNetconns[i] = netconn_new();
        netconn_bind(listenNetconns[i], IP_ADDR_ANY, ports[i]);
        netconn_listen(listenNetconns[i]);
        clientNetconns[i] = netconn_accept(listenNetconns[i]);
}

With this code the PCBs are only sometimes stuck in TIME_WAIT state for
~2 minutes. But if I remove the "sleepFor()" call, then there is a PCB
(maybe more than one) stuck in FIN_WAIT_1 forever.

Any idea what could be the reason for this behaviour? I'm not very
comfortable with random fixes which I don't understand at all (; The
delay obviously allows main TCP/IP thread to run for a while, but what
does it change? The connections are closed and deleted anyway, so why
would lwIP behave so differently in these two cases?

Thanks in advance!

Regards,
FCh