From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1F8E7C35666 for ; Sun, 23 Feb 2020 13:41:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D3FD3206E0 for ; Sun, 23 Feb 2020 13:41:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=mork.no header.i=@mork.no header.b="M8Z2LYIT" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726650AbgBWNlE (ORCPT ); Sun, 23 Feb 2020 08:41:04 -0500 Received: from canardo.mork.no ([148.122.252.1]:51357 "EHLO canardo.mork.no" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726208AbgBWNlD (ORCPT ); Sun, 23 Feb 2020 08:41:03 -0500 Received: from miraculix.mork.no (ti0136a430-4331.bb.online.no [80.213.107.248]) (authenticated bits=0) by canardo.mork.no (8.15.2/8.15.2) with ESMTPSA id 01NDeudj024858 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 23 Feb 2020 14:40:56 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mork.no; s=b; t=1582465256; bh=B1r3vsmiyMC3FCbqyArVqXmIUybokSxxlEfgZ5SJV2A=; h=From:To:Cc:Subject:References:Date:Message-ID:From; b=M8Z2LYITKJ8JLHYmQEDQT5rgkQgAVKkjXkg5ol3KPbdGNVDV2NAKrVhZ7Yny1CQd7 ssbCDK3Kp1G8Mz6ltJAPSXCCCf4Dz2Q+P6RGSZXhWIo5IhfLVxWSdJtvc79YFTXg5c vX9nlINbO/5swgCy8Xhv4amXjaj31U6L008jFjeQ= Received: from bjorn by miraculix.mork.no with local (Exim 4.92) (envelope-from ) id 1j5rV5-00075G-Be; Sun, 23 Feb 2020 14:40:51 +0100 From: =?utf-8?Q?Bj=C3=B8rn_Mork?= To: Daniele Palmas Cc: netdev@vger.kernel.org, "David S . Miller" Subject: Re: [PATCH 1/1] net: usb: qmi_wwan: restore mtu min/max values after raw_ip switch Organization: m References: <20200221131705.26053-1-dnlplm@gmail.com> Date: Sun, 23 Feb 2020 14:40:51 +0100 In-Reply-To: <20200221131705.26053-1-dnlplm@gmail.com> (Daniele Palmas's message of "Fri, 21 Feb 2020 14:17:05 +0100") Message-ID: <87eeul5sm4.fsf@miraculix.mork.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.102.1 at canardo X-Virus-Status: Clean Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Daniele Palmas writes: > usbnet creates network interfaces with min_mtu =3D 0 and > max_mtu =3D ETH_MAX_MTU. > > These values are not modified by qmi_wwan when the network interface > is created initially, allowing, for example, to set mtu greater than 1500. > > When a raw_ip switch is done (raw_ip set to 'Y', then set to 'N') the mtu > values for the network interface are set through ether_setup, with > min_mtu =3D ETH_MIN_MTU and max_mtu =3D ETH_DATA_LEN, not allowing anymor= e to > set mtu greater than 1500 (error: mtu greater than device maximum). > > The patch restores the original min/max mtu values set by usbnet after a > raw_ip switch. > > Signed-off-by: Daniele Palmas Great! I tried to look up the origin of this bug, and it seems to be a hard-to-spot fallout from the 'centralized MTU checking'. Not easy to see the hidden connection in usbnet.c and eth.c. Thanks for finding and fixing it! This should probably go to stable as well? Acked-by: Bj=C3=B8rn Mork