Messages in this thread | | | From | Eric Dumazet <> | Date | Mon, 9 Nov 2020 12:02:27 +0100 | Subject | Re: [PATCH net v2] net: Update window_clamp if SOCK_RCVBUF is set |
| |
On Mon, Nov 9, 2020 at 11:12 AM Mao Wenan <wenan.mao@linux.alibaba.com> wrote: > > > > 在 2020/11/9 下午5:56, Eric Dumazet 写道: > > On Mon, Nov 9, 2020 at 10:33 AM Mao Wenan <wenan.mao@linux.alibaba.com> wrote: > >> > >> When net.ipv4.tcp_syncookies=1 and syn flood is happened, > >> cookie_v4_check or cookie_v6_check tries to redo what > >> tcp_v4_send_synack or tcp_v6_send_synack did, > >> rsk_window_clamp will be changed if SOCK_RCVBUF is set, > >> which will make rcv_wscale is different, the client > >> still operates with initial window scale and can overshot > >> granted window, the client use the initial scale but local > >> server use new scale to advertise window value, and session > >> work abnormally. > > > > What is not working exactly ? > > > > Sending a 'big wscale' should not really matter, unless perhaps there > > is a buggy stack at the remote end ? > 1)in tcp_v4_send_synack, if SO_RCVBUF is set and > tcp_full_space(sk)=65535, pass req->rsk_window_clamp=65535 to > tcp_select_initial_window, rcv_wscale will be zero, and send to client, > the client consider wscale is 0; > 2)when ack is back from client, if there is no this patch, > req->rsk_window_clamp is 0, and pass to tcp_select_initial_window, > wscale will be 7, this new rcv_wscale is no way to advertise to client. > 3)if server send rcv_wind to client with window=63, it consider the real > window is 63*2^7=8064, but client consider the server window is only > 63*2^0=63, it can't send big packet to server, and the send-q of client > is full. >
I see, please change your patches so that tcp_full_space() is used _once_
listener sk_rcvbuf can change under us.
I really have no idea how window can be set to 63, so please send us the packetdrill test once you have it.
| |