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: <20200715124258.GP32005@breakpoint.cc>
Date:   Wed, 15 Jul 2020 14:42:58 +0200
From:   Florian Westphal <fw@...len.de>
To:     Stefano Brivio <sbrivio@...hat.com>
Cc:     Florian Westphal <fw@...len.de>, David Ahern <dsahern@...il.com>,
        netdev@...r.kernel.org, aconole@...hat.com
Subject: Re: [PATCH net-next 1/3] udp_tunnel: allow to turn off path mtu
 discovery on encap sockets

Stefano Brivio <sbrivio@...hat.com> wrote:
> I would still like the idea I proposed better (updating MTUs down the
> chain), it's simpler and we don't have to duplicate existing
> functionality (generating additional ICMP messages).

It doesn't make this work though.

With your skeleton patch, br0 updates MTU, but the sender still
won't know that unless input traffic to br0 is routed (or locally
generated).

Furthermore, such MTU reduction would require a mechanism to
auto-reconfig every device in the same linklevel broadcast domain,
and I am not aware of any such mechanism.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ