netdev - Re: [PATCH net-next v5 0/2] L2TP:Adjust intf MTU, add underlay L3, L2 hdrs.

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] [day] [month] [year] [list]

Date:   Thu, 06 Apr 2017 13:43:49 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     parameswaran.r7@...il.com
Cc:     netdev@...r.kernel.org, jchapman@...alix.com, kleptog@...na.org,
        nprachan@...cade.com, rshearma@...cade.com,
        stephen@...workplumber.org, sdietric@...cade.com,
        ciwillia@...cade.com, lboccass@...cade.com, dfawcus@...cade.com,
        bhong@...cade.com, jblunck@...cade.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v5 0/2] L2TP:Adjust intf MTU, add underlay L3,
 L2 hdrs.

From: "R. Parameswaran" <parameswaran.r7@...il.com>
Date: Wed, 5 Apr 2017 17:05:49 -0700 (PDT)

> 
> Existing L2TP kernel code does not derive the optimal MTU for Ethernet
> pseudowires and instead leaves this to a userspace L2TP daemon or
> operator. If an MTU is not specified, the existing kernel code chooses
> an MTU that does not take account of all tunnel header overheads, which
> can lead to unwanted IP fragmentation. When L2TP is used without a
> control plane (userspace daemon), we would prefer that the kernel does a
> better job of choosing a default pseudowire MTU, taking account of all
> tunnel header overheads, including IP header options, if any. This patch
> addresses this.
> 
> Change-set is organized as a two part patch series, with one patch
> introducing a new kernel function to compute the IP overhead on a
> socket, and the other patch using this new kernel function to compute
> the default L2TP MTU for an Ethernet pseudowire.
> 
> Existing code also seems to assume an Ethernet (non-jumbo) underlay. The
> change proposed here uses the PMTU mechanism and the dst entry in the
> L2TP tunnel socket to directly pull up the underlay MTU (as the baseline
> number on top of which the encapsulation headers are factored in).
> An default MTU value of 1500 bytes is assumed as a fallback only if
> this fails. 
> 
> Fixed the kbuild test robot error in the previous posting.

Series applied, thanks.