After trying to reproduce your bug report, I'm not so sure any more that
there is a problem: when the last ACK is lost (for whatever reason),
tcp_slowtmr will eventually retransmit the outstanding (unacked) segment
(the FIN,ACK). The retransmission will take place when (pcb->rtime >=
pcb->rto).
I don't know for which reason the lask ACK 'disappears' (shouldn't the
remote side try again?) but I think the patch is reasonable to keep the
system stable... I'll submit a bug report (which is the normal thing to
do when discovering bugs, they easily get lost when only posting to the
mailing-
Hi
I added check for CLOSING state in tcp.c, with this patch the pcb is freed
/* Check if this PCB has stayed too long in LAST-ACK */
if (pcb->state == LAST_ACK) {
if ((u32_t)(tcp_ticks - pcb->tmr) > 2 * TCP_MSL / TCP_SLOW_INTERVAL) {
++pcb_remove;
LWIP_DEBUGF(TCP_DE
> Do you mean that if I set the size of messeges for lwip mailbox big
enough,
> the mbox will neverbe full?
Hopefully, yes. And until you don't post too much received packets to
tcpip_input (e.g. from an interrupt - that can produce heavy load) it
will work.
Simon
_
Do you mean that if I set the size of messeges for lwip mailbox big enough,
the mbox will neverbe full?
There is a limitation in the current lwIP sys-arch layer: sys_mbox_post must
never fail! The result when not posting a message to the mbox is unpredictable
(although most of the time, the
