Initialise snd_wnd on the server side always before processing the ack

[tuexen]

Summary

The current code only initialises tp->snd_wnd before the ack processing when handling the ACK segment in the SYN-RCVD state only when the window scaling option is enabled. This patch ensures that the initialisation is done always to improve consistency.

This fixes the issue that the issue reported in PR235256 only shows up when having window scaling enabled.

Test Plan

Both tests should fail indicating the the CWND is too large:

tcp-server-iw-3-ipv4.pkt2 KBDownload

tcp-server-iw-3-ws-ipv4.pkt2 KBDownload

[rscheff]

So, what you are saying is that this issue here bascially masked the problem reported in PR235256 from happening when window scale was not negotiated.
At least that's what I'm observing, and what the code appears to be saying.

Because snd_wnd may be smaller than cwnd (as set by tcp_compute_initcwnd), which in turn leads to CCF_CWND_LIMITED not to be set in cc_ack_received wrapper, bypassing the cwnd update in the CC_ALGO(ack_received).

And the attached test cases should both succeed (as they are checking for IW=3 after the 3WHS) if both D19033 and D19000 are applied.

Now, I wonder - was this perhaps intentional, delaying setting snd_wnd (until "step6") after CC_ALGO(ack_received) in order to prevent that inital update from inflating the initial window?

Conversely: Was TCP_FAST_OPEN actually working without window scale then? (is there an existing packetdrill test for that scenario)?

[rscheff]

Maybe a break in line 2433 is actually missing for the original issue (just another thought; browsing the history doesn't show that though). In any case, this change looks sensible enough.

[rscheff]

RACK seems to have a similar code in rack_do_syn_recv.

[tuexen]

Also fix the issue in the RACK stack.

[tuexen]

In D19033#407072, @rscheff_gmx.at wrote:

RACK seems to have a similar code in rack_do_syn_recv.

Fixed. Thanks for reminding me...

[tuexen]

Simplification of the fix within the RACK code.