Re: [lwip-users] Raw TCP, intermittent long delays in accept after after close

[Geoff Simmons]

On 10/20/22 21:53, goldsimon@gmx.de wrote:
> Am 20.10.2022 um 20:22 schrieb Geoff Simmons:
> > [..]
> > When the server is ready to close, it calls tcp_close(); if tcp_close()
> > does not return ERR_OK, it calls tcp_abort(). If it was tcp_abort(),
> > then tcp_arg and the tcp_poll and tcp_err callbacks are retained.
> > tcp_poll or tcp_err then initiate finalizing the pcb. Otherwise
> > (tcp_close() succeeded), the pcb is finalized right away.
> >
> > The pcb is finalized by setting tcp_arg and all of the callbacks to NULL.
>
> See these comments on tcp_abort:
>
> "The pcb is deallocated"
>
> and
>
> "ATTENTION: When calling this from one of the TCP callbacks, make
> sure you always return ERR_ABRT (and never return ERR_ABRT otherwise
> or you will risk accessing deallocated memory or memory leaks!"

Ah, okay. I did notice the part about returning ERR_ABRT (and just 
checked again that it always happens).

But if the pcb is deallocated immediately, then it's obviously not right 
to keep some of the callbacks around. That makes things a bit simpler -- 
always finalize the pcb (by setting everything to NULL) on close, rather 
than do things differently depending on whether tcp_abort() was called.

> This might indicate a use-after-free error after your tcp_abort calls?

If it's use-after-free -- if you mean libc's free(3) -- I would have 
expected much worse problems, such as the app crashing. As it is, there 
isn't always a problem, and if there is, everything seems to recover 
after about 10 or 20 seconds.

But if by "free" you meant pbuf_free(), which IIUC might entail 
returning the pcb to a pool, that might be it. For example if the pcb is 
in an invalid state when it's taken from the pool the next time.

The app doesn't use MEM_LIBC_MALLOC. With MEMP_STATS I have seen that 
mempools are used for tcp_pcbs.


Thanks,
Geoff