netdev - Re: [PATCHv3 net-next 3/4] ipv4: shrink current mss for tcp PMTU blackhole detection

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABrhC0nXCtWCgNm6Gz8UCXg=7Vt1pN0Q+aqO1TYZ74JK45Tq-g@mail.gmail.com>
Date:	Mon, 2 Mar 2015 15:32:22 -0500
From:	John Heffner <johnwheffner@...il.com>
To:	Fan Du <fengyuleidian0615@...il.com>
Cc:	Fan Du <fan.du@...el.com>, Eric Dumazet <edumazet@...gle.com>,
	David Miller <davem@...emloft.net>,
	Netdev <netdev@...r.kernel.org>
Subject: Re: [PATCHv3 net-next 3/4] ipv4: shrink current mss for tcp PMTU
 blackhole detection

On Mon, Mar 2, 2015 at 4:29 AM, Fan Du <fengyuleidian0615@...il.com> wrote:
> Timeout indicates search_high should be set to the new mtu corresponding to
> current_mss no
> matter how we change search_low. So the best shot here IMO would be updating
> search_high
> with current_mss, which in return makes the search window *slide* from right
> to left, and
> the probing will converge in good speed eventually.
>
> So my thoughts is:
> @@ -113,6 +113,7 @@ static void tcp_mtu_probing(struct inet_connection_sock
> *icsk, struct sock *sk)
>                         struct tcp_sock *tp = tcp_sk(sk);
>                         int mss;
>
> +                       icsk_mtup.search_high = tcp_mss_to_mtu(sk,
> tcp_current_mss(sk));
>                         mss = tcp_mtu_to_mss(sk, icsk->icsk_mtup.search_low)
>>> 1;
>                         mss = min(net->ipv4.sysctl_tcp_base_mss, mss);
>                         mss = max(mss, 68 - tp->tcp_header_len);

Search_high should be adjusted downward only when you're quite certain
that you've gotten a negative signal.  There are many possible reasons
for successive timeouts including intermittent disconnection, and they
should not have a persistent (or very long-term) effect on MTU.  Leave
search_high where it is until a working MTU can be established, then
probe upward until probing can give you confidence you've found a new
ceiling, or gotten back to the old one.

If you think the current approach is broken, it would help to see a
concrete demonstration of how it's deficient (a real packet trace is
good!), and how a different approach work better.

Thanks,
  -John
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html