From mboxrd@z Thu Jan 1 00:00:00 1970 From: Guillaume Nault Subject: Re: [PATCH net-next] l2tp: remove ->recv_payload_hook Date: Wed, 25 Jul 2018 15:00:03 +0200 Message-ID: <20180725130003.GC1487@alphalink.fr> References: <6a20d71b1acf5a81fd80e06120cb40a06fed1c71.1532523126.git.g.nault@alphalink.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: James Chapman To: netdev@vger.kernel.org Return-path: Received: from zimbra.alphalink.fr ([217.15.80.77]:52262 "EHLO zimbra.alphalink.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728927AbeGYOLq (ORCPT ); Wed, 25 Jul 2018 10:11:46 -0400 Content-Disposition: inline In-Reply-To: <6a20d71b1acf5a81fd80e06120cb40a06fed1c71.1532523126.git.g.nault@alphalink.fr> Sender: netdev-owner@vger.kernel.org List-ID: On Wed, Jul 25, 2018 at 02:53:33PM +0200, Guillaume Nault wrote: > The tunnel reception hook is only used by l2tp_ppp for skipping PPP > framing bytes. This is a session specific operation, but once a PPP > session sets ->recv_payload_hook on its tunnel, all frames received by > the tunnel will enter pppol2tp_recv_payload_hook(), including those > targeted at Ethernet sessions (an L2TPv3 tunnel can multiplex PPP and > Ethernet sessions). > I forgot to mention that this patch is targeted at net-next because, in practice, the PPP payload hook is unlikely to corrupt valid Ethernet frames (the destination MAC address would have to beging with ff:03).