Re: [lwip-users] Netconn API, e.g. lwip_close, netconn_close, or netconn_delete, sometimes does not return, with suggested fixes.

[Simon Goldschmidt]

Mike,

You're mixing up various things here, I'll try to sort them out below. Anyway, 
possible bug reports like these are better off on lwip-devel and even better in 
the bug tracker.
 
Mike Stitt wrote:
> Within the suggested fixes, there are 3 areas of improvement
> 
> 1)#define TCP_CLOSE_ALWAYS_RETURNS 1
> Targets the cases where tcp_enqueue_flags can not allocate buffer space for 
> the segment needed
> to add the FIN bit. With TCP_CLOSE_ALWAYS_RETURNS, we choose to return an 
> error in this case rather
> than letting tcp_slowtmr try to resolve the memory issue later.

This is what O_NONBLOCK is for. There might be bugs that prevent correct 
behaviour of nonblocking close, but adding yet another config option to check 
this is not a good idea.
 
> 2)#define TCP_DO_NOT_ADD_FIN_TO_RST 1
> Targets a corner case that occurs in this scenario where lwIP has decided 
> that the connection should
> be RST, but has not been able to push out the segment with the RST, and now 
> on the close, wants to
> add a FIN.  By setting TCP_DO_NOT_ADD_FIN_TO_RST we close the connection 
> without trying to add the FIN
> in this case.


I'm curious, how can this happen? RST segments should normally be sent out 
right away, since they are asynchronous events. There should not be any RST on 
the unsent/unacked lists. And I can't find code in the current sources that 
would do this.
 
> 3)#define LWIP_PCB_COMPLETED_BOOKKEEPING 1
> Adds a more robust solution to the application to TCP/IP thread netconn 
> interface. It adds a to_be_completed
> byte to the netconn data structure. For the sockets and netconn API, it the 
> keeps track of whether or not the 
> application thread is blocked on the TCP/IP task for PCBs that are purged by 
> tcp_slowtmr.

Isn't this what the 'current_msg' member is used for already at multilpe 
places? The fact that the code you added to err_tcp() makes things better (if 
it really does?) looks like hiding an lwIP or port bug to me...

> tcp_slowtmr calls
> the pcb->errf which will sys_sem_signal the application thread with a 
> ERR_ABRT when the pcb is purged.

Now this is really a possible bug in the intercommunication between tcp and the 
netconn API. However, I'd like to get a more detailed report on how it can 
happen that the netconn API waits on a TIME_WAIT pcb. Which netconn function is 
blocking on the pcb when waking it up in this state?


Simon