[lwip-devel] [bug #20511] No persist timer

[Tamas Somogyi]

Follow-up Comment #13, bug #20511 (project lwip):

Kieran, the problem I described in bug #24212 caused by your last
modification in tcp_out.c: Rev 1.71 works well, but I get the error using
1.72. The difference is that Zero Window Probe is sent not when snd_wnd is
zero, but also when the window is not enough to send the data.

RFC793 "Managing the Window" says: 
"The sending TCP must be prepared to accept from the user and send at least
one octet of new data even if the send window is zero." and
"When the receiving TCP has a zero window and a segment arrives it must still
send an acknowledgment showing its next expected sequence number and current
window (zero)."
In my understanding it means that the receiver is not liable for sending ACK
to this probe, if its window is nonzero.

This happens in my attached scenario:
https://savannah.nongnu.org/bugs/download.php?file_id=16890
Note that receiver window is 1280 always (and thus non-zero).
Frame#21: Sender sends a segment as usual.
#21-22: segment#1847 lost
#22-26: sender sends 5*142=710 bytes. Including the lost segment, the sent
data is 710+142=852 bytes.
#27: receiver ACKs frame#21 and expects the lost segment#1989 and advertises
receiver window 1280.
#28: sender sends 426 (=3*142) bytes, so totally 852+426=1278 bytes. Close,
right? With the next 142 bytes, 1278+142 > 1280, therefore lwip starts the
persist timer in a next timeslice.
#29-34: dark and weird things happen: sender (lwip) and receiver tries to get
back to normal way, finally lwip resends the lost segment
#35: receiver ACKs seg#1989
#36: are you still with me? Finally, persist timer event occurs, and lwip
sends 1-byte Zero Window Probe.
#37: there's almost 3.4s gap between #36 and 37, which is very big comparing
to the normal 0.2s cycle time. It means that receiver doesn't ACK the 1-byte
message, perhaps because its window is non-zero.
#38...: lwip tries the Zero Window Probe again, but no success, finally the
receiver gets bored and closes the socket.

Remarks:
A) A possible solution could be that instead of sending 1-byte in
tcp_zero_window_probe, check if snd_wnd is greater or equal than the segment
(seg->tcphdr->seqno) size, then (re-)send the whole segment.

B) Wireshark identifies Zero Window Probe segments as "Broken TCP" - maybe it
is wrong, but wouldn't be better to set ACK (and PSH) flag?

So I suggest to re-open this bug. It takes some time to me to investigate in
A) and B) as I have to carefully test the solution and this problem occurs
randomly (5min...3hours). Welcome for any comment.

- Tamas

PS: In tcp_receive, the condition (pcb->snd_wl2 == ackno && tcphdr->wnd >
pcb->snd_wnd) shouldn't be (pcb->snd_wl1 == seqno && pcb->snd_wl2 == ackno &&
tcphdr->wnd > pcb->snd_wnd)?

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?20511>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/