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
_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users