Hello,
On Fri, Aug 06, 2021 at 12:26:10AM +0200, Alexander Bluhm wrote:
> Hi,
>
> I have seen some stalling TCP connections while doing unidirectional
> throughput tests. The sending machine is doing zero window probes,
> but is not sending more data although the other machine announced
> that it has space again.
>
> I guess this commit in tcp_input.c triggered it:
> ----------------------------
> revision 1.362
> date: 2019/11/11 21:17:21; author: bluhm; state: Exp; lines: +9 -3;
> commitid: wXndkYTLO9jvCPdW;
> Prevent underflows in tp->snd_wnd if the remote side ACKs more than
> tp->snd_wnd. This can happen, for example, when the remote side
> responds to a window probe by ACKing the one byte it contains.
> from FreeBSD; via markus@; OK sashan@ tobhe@
> ----------------------------
>
> There we fixed an integer underflow. So we no longer have uint32
> max in the send window, but 0. I see this in my test case. Now
> we need the machanism that writes the correct send window size.
>
> There is a commit in FreeBSD from 2002:
> https://urldefense.com/v3/__https://github.com/freebsd/freebsd-src/commit/1645d0903ef7162f5c4516373f0c9df0501ac893__;!!ACWV5N9M2RV99hQ!bS5vG8TH_FAv1Bx-q4iPl5brhCeUQ-GvVeLnfT4b6mk4tY-ktVPZoOAX0zD5ySiQj4R416lx$
>
>
> The header prediction code did not update snd_wl2. If there is a
> sequence number wrap, the send window update is not reached.
>
> Although I did not obverve it, there seems to be the same problem
> for snd_wl1 and rcv_up. For rcv_up I copied the comparison with
> rcv_nxt from urgent processing to keep future urgent data.
>
> ok?
>
Looks good to me, OK sashan
can you also share some details about testing you have done?
(tool + command line options)
thanks a lot
regards
sashan
