Hi,
Jan's earlier message reminded me of a problem I've seen in tcp_in.c:
When we receive a FIN, we do a +1 and send an ack as we should, and go
into CLOSE_WAIT state. If we receive a duplicate FIN, however, we do
another +1, and send another ack with the new ackno. This can lead to
sticky situations - From memory, I think the effect I saw was a storm of
network traffic, where both ends are acking each other constantly, with
the LWIP end erroneously upping the ackno every time.
The attached patch prevents the additional +1 if we receive duplicate FINs.
Cheers,
Kelvin.
Index: tcp_in.c
===================================================================
--- tcp_in.c (revision 29)
+++ tcp_in.c (working copy)
@@ -1023,7 +1023,13 @@
tcplen = TCP_TCPLEN(&inseg);
- pcb->rcv_nxt += tcplen;
+ /* FINs from the other end will be acked +1, but be careful
+ not to do this if we receive any duplicate FINs. For
+ duplicate FINs we will already be in CLOSE_WAIT state
+ and will already have performed the +1. */
+ if (pcb->state != CLOSE_WAIT) {
+ pcb->rcv_nxt += tcplen;
+ }
/* Update the receiver's (our) window. */
if (pcb->rcv_wnd < tcplen) {
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
