On Mon, Nov 9, 2020 at 11:12 AM Mao Wenan <wenan.mao@xxxxxxxxxxxxxxxxx> wrote: > > > > 在 2020/11/9 下午5:56, Eric Dumazet 写道: > > On Mon, Nov 9, 2020 at 10:33 AM Mao Wenan <wenan.mao@xxxxxxxxxxxxxxxxx> 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.
