Re: [PATCH net v2] net: Update window_clamp if SOCK_RCVBUF is set

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





在 2020/11/9 下午6:12, Mao Wenan 写道:


在 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.




Signed-off-by: Mao Wenan <wenan.mao@xxxxxxxxxxxxxxxxx>
---
  v2: fix for ipv6.
  net/ipv4/syncookies.c | 4 ++++
  net/ipv6/syncookies.c | 5 +++++
  2 files changed, 9 insertions(+)

diff --git a/net/ipv4/syncookies.c b/net/ipv4/syncookies.c
index 6ac473b..57ce317 100644
--- a/net/ipv4/syncookies.c
+++ b/net/ipv4/syncookies.c
@@ -427,6 +427,10 @@ struct sock *cookie_v4_check(struct sock *sk, struct sk_buff *skb)

         /* Try to redo what tcp_v4_send_synack did. */
         req->rsk_window_clamp = tp->window_clamp ? :dst_metric(&rt->dst, RTAX_WINDOW); +       /* limit the window selection if the user enforce a smaller rx buffer */
+       if (sk->sk_userlocks & SOCK_RCVBUF_LOCK &&
+           (req->rsk_window_clamp > tcp_full_space(sk) || req->rsk_window_clamp == 0))
+               req->rsk_window_clamp = tcp_full_space(sk);

This seems not needed to me.

We call tcp_select_initial_window() with tcp_full_space(sk) passed as
the 2nd parameter.

tcp_full_space(sk) will then apply :

space = min(*window_clamp, space);

if cookie_v4_check pass window_clamp=0 to tcp_select_initial_window, it will set window_clamp to max value.
(*window_clamp) = (U16_MAX << TCP_MAX_WSCALE);

window_clamp=0 is from
req->rsk_window_clamp = tp->window_clamp ? :dst_metric(dst, RTAX_WINDOW);

and if SO_RCVBUF is set and equal to 65535,req->rsk_window_clamp will be 65535.
req->rsk_window_clamp = tcp_full_space(sk);


but space will fetch from sysctl_rmem_max and sysctl_tcp_rmem[2] which is also big value.
space = max_t(u32, space, sock_net(sk)->ipv4.sysctl_tcp_rmem[2]);
space = max_t(u32, space, sysctl_rmem_max);

Then,space = min(*window_clamp, space) is a big value, lead wscale to 7,
is different from tcp_v4_send_synack.



Please cook a packetdrill test to demonstrate what you are seeing ?

I have real environment and reproduce this case, this patch can fix that, i will try to use packetdrill with syn cookies and syn flood happen.



[Index of Archives]     [Kernel Development]     [Kernel Announce]     [Kernel Newbies]     [Linux Networking Development]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Device Mapper]

  Powered by Linux