[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Netconn API, e.g. lwip_close, netconn_close, or netconn

From: address@hidden
Subject: Re: [lwip-users] Netconn API, e.g. lwip_close, netconn_close, or netconn_delete, sometimes does not return, with suggested fixes.
Date: Wed, 03 Dec 2014 20:52:04 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0


any update on this? I'd love to fix these things if they are bugs actually. In that case, we should add a bug tracker entry.


Simon Goldschmidt wrote:

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

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.
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.
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 
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?


lwip-users mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]