issue: 1182981 Fix TCP zero-window probe message sequence number

tcp: advance next seq nr for zero window probes

It is possible that the byte sent as a zero window probe is accepted
and acknowledged by the receiver side without the window being opened.
In that case, the stream has effectively advanced by one byte, and
since lwIP did not take this into account on the sender side, the
result was a desynchronization between the sender and the receiver.
That situation could occur even on a lwIP loopback device, after
filling up the receiver side's receive buffer, and resulted in an ACK
storm. This patch corrects the problem by advancing the sender's next
sequence number by one as needed when sending a zero window probe.

This was cherry-picked from lwip 9ba9dee.

Signed-off-by: Daniel Libenson <[email protected]>

src/vma/lwip/tcp_out.c

@@ -1552,6 +1552,7 @@ tcp_zero_window_probe(struct tcp_pcb *pcb)
   struct tcp_seg *seg;
   u16_t len;
   u8_t is_fin;
+  u32_t snd_nxt;
 
   LWIP_DEBUGF(TCP_DEBUG,
               ("tcp_zero_window_probe: sending ZERO WINDOW probe to %"
@@ -1590,6 +1591,12 @@ tcp_zero_window_probe(struct tcp_pcb *pcb)
     *((char *)p->payload + TCP_HLEN) = *(char *)seg->dataptr;
   }
 
+   /* The byte may be acknowledged without the window being opened. */
+   snd_nxt = lwip_ntohl(seg->tcphdr->seqno) + 1;
+   if (TCP_SEQ_LT(pcb->snd_nxt, snd_nxt)) {
+     pcb->snd_nxt = snd_nxt;
+   }
+
 #if CHECKSUM_GEN_TCP
   tcphdr->chksum = inet_chksum_pseudo(p, &pcb->local_ip, &pcb->remote_ip,
                                       IP_PROTO_TCP, (u16_t)p->tot_len);