From patchwork Fri Jul 11 07:09:53 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christoph Schulz X-Patchwork-Id: 369012 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 6BCE01400B9 for ; Fri, 11 Jul 2014 17:15:28 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751515AbaGKHPY (ORCPT ); Fri, 11 Jul 2014 03:15:24 -0400 Received: from server721-han.de-nserver.de ([85.158.180.102]:43520 "EHLO server721-han.de-nserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751420AbaGKHPX (ORCPT ); Fri, 11 Jul 2014 03:15:23 -0400 X-Greylist: delayed 323 seconds by postgrey-1.27 at vger.kernel.org; Fri, 11 Jul 2014 03:15:23 EDT Received: (qmail 16531 invoked from network); 11 Jul 2014 09:09:58 +0200 X-Fcrdns: Yes Received: from a89-182-250-227.net-htp.de (HELO onion.schulz.ip-v6.eu) (89.182.250.227) (smtp-auth username mail@kristov.de, mechanism plain) by server721-han.de-nserver.de (qpsmtpd/0.92) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA; Fri, 11 Jul 2014 09:09:58 +0200 Received: from [2001:6f8:13da:1:592:42ec:4313:de65] (helo=peacock.schulz.ip-v6.eu) by onion.schulz.ip-v6.eu with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1X5Uxv-0005Wa-09; Fri, 11 Jul 2014 09:09:55 +0200 Received: from peacock.schulz.ip-v6.eu ([2001:6f8:13da:1:225:22ff:fe6c:68f4]) by peacock.schulz.ip-v6.eu with esmtps (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1X5Uxu-0006u8-A4; Fri, 11 Jul 2014 09:09:54 +0200 Message-ID: <53BF8DC1.1040905@kristov.de> Date: Fri, 11 Jul 2014 09:09:53 +0200 From: Christoph Schulz User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: netdev@vger.kernel.org CC: linux-ppp@vger.kernel.org, mostrows@gmail.com Subject: [PATCH net-next] net: pppoe: use correct MTU when using Multilink PPP with PPPoE X-User-Auth: Auth by mail@kristov.de through 89.182.250.227 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Christoph Schulz The PPP channel MTU is used with Multilink PPP when ppp_mp_explode() (see ppp_generic module) tries to determine how big a fragment might be. If we don't subtract 2 bytes (which corresponds to the PPP protocol number), the payload becomes 1-2 bytes too big (1 byte if PPP protocol compression is used, 2 otherwise), which causes the generated Ethernet packets to be dropped. This is due to code in ppp_mp_explode() which says: /* * hdrlen includes the 2-byte PPP protocol field, but the * MTU counts only the payload excluding the protocol field. * (RFC1661 Section 2) */ mtu = pch->chan->mtu - (hdrlen - 2); This is correct, but the pppoe module does not account for it and includes the 2-byte PPP protocol field into the computed MTU, which is wrong. This error only manifests itself when using Multilink PPP, as otherwise the channel MTU is not used anywhere. The bug was introduced in commit c9aa6895371b2a257401f59d3393c9f7ac5a8698 ("[PPPOE]: Advertise PPPoE MTU") from the very beginning. This patch applies to 3.10 upwards but the fix can be applied (with minor modifications) to kernels as old as 2.6.32. Signed-off-by: Christoph Schulz --- -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/net/ppp/pppoe.c b/drivers/net/ppp/pppoe.c index 2ea7efd..6c9c16d 100644 --- a/drivers/net/ppp/pppoe.c +++ b/drivers/net/ppp/pppoe.c @@ -675,7 +675,7 @@ static int pppoe_connect(struct socket *sock, struct sockaddr *uservaddr, po->chan.hdrlen = (sizeof(struct pppoe_hdr) + dev->hard_header_len); - po->chan.mtu = dev->mtu - sizeof(struct pppoe_hdr); + po->chan.mtu = dev->mtu - sizeof(struct pppoe_hdr) - 2; po->chan.private = sk; po->chan.ops = &pppoe_chan_ops;