From patchwork Mon Apr 30 15:59:12 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Jeff Kletsky X-Patchwork-Id: 906759 X-Patchwork-Delegate: blogic@openwrt.org Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (helo) smtp.helo=arrakis.dune.hu (client-ip=78.24.191.176; helo=arrakis.dune.hu; envelope-from=openwrt-devel-bounces@lists.openwrt.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=allycomm.com Received: from arrakis.dune.hu (arrakis.dune.hu [78.24.191.176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 40ZTkJ0j55z9s0n for ; Tue, 1 May 2018 01:59:16 +1000 (AEST) Received: from arrakis.dune.hu (localhost [127.0.0.1]) by arrakis.dune.hu (Postfix) with ESMTP id 93F53B806B7; Mon, 30 Apr 2018 17:59:06 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on arrakis.dune.hu X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.1 Received: from arrakis.dune.hu (localhost [127.0.0.1]) by arrakis.dune.hu (Postfix) with ESMTP; Mon, 30 Apr 2018 17:59:06 +0200 (CEST) Received: from arrakis.dune.hu (localhost [127.0.0.1]) by arrakis.dune.hu (Postfix) with ESMTP id F3B01B800CE for ; Mon, 30 Apr 2018 17:59:04 +0200 (CEST) X-policyd-weight: NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 CL_IP_EQ_FROM_MX=-3.1; rate: -6.1 Received: from mx.allycomm.com (mx.allycomm.com [138.68.30.55]) by arrakis.dune.hu (Postfix) with ESMTPS for ; Mon, 30 Apr 2018 17:59:02 +0200 (CEST) Received: from JKLETSKY1-MBP15.local (184-23-191-38.vpn.dynamic.sonic.net [184.23.191.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.allycomm.com (Postfix) with ESMTPSA id E978823635; Mon, 30 Apr 2018 08:58:58 -0700 (PDT) To: lede-dev@lists.infradead.org, openwrt-devel@lists.openwrt.org From: Jeff Kletsky Message-ID: Date: Mon, 30 Apr 2018 08:59:12 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Language: en-US Subject: [OpenWrt-Devel] Setting *wireless* MTU, "UCI-compliant" way? X-BeenThere: openwrt-devel@lists.openwrt.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: OpenWrt Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: openwrt-devel-bounces@lists.openwrt.org Sender: "openwrt-devel" TL;DR When wireless is used as transport for an encapsulated stream, it can be beneficial (or essential) to increase the MTU of the link closer to the 2304 802.11 MTU. I haven't found a way to set the MTU of the wireless device itself through UCI. If there's something I'm missing, I'd appreciate hearing about it. In Detail I'm using 802.11s for transport of GRE-encapsulated bridged streams. PMTUD doesn't work in a bridged situation (for non-local devices) as there no way of determining to whom the fragmentation-required ICMP packet needs to be sent to. This is not an OpenWRT-specific problem. OpenWRT "properly" reduces the MTU of the gretap link based on the underlying link, in this case below the 1500 MTU of an OpenWRT wireless link configured with config wifi-iface 'mesh0'     option device 'radio5'     option ifname 'mesh0'     option mode 'mesh'     option mesh_id ''     option mesh_fwding '1'     option encryption 'psk2+ccmp'     option key ''     option sae_password '' (Yes, both key and sae_password are there, as they have been bouncing around as to which works and which doesn't over the last month or so of master commits.) What is challenging is that even with a "named" wireless interface, there doesn't seem to be a way to directly use netifd and UCI configuration to override the default MTU. Changing the bridge over the interface doesn't help, as the bridge MTU is limited by the smallest MTU of its bridged interfaces. Right now, I "hook" things in a somewhat hack-ish way At least my read of things is that virtual wireless devices are "wiped" and re-created when changes are made. If this isn't the case, I'd appreciate knowing where else I might need to "hook" things if this is the "only" approach to managing MTU of the wireless link. All nodes are under my administrative control, so the "non-standard" MTU does not pose interoperability concerns for me. Is there a cleaner way to manage this? Jeff --- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh +++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh @@ -513,6 +513,8 @@ mac80211_prepare_vif() {                 ip link set dev "$ifname" address "$macaddr"         fi +       [ -x /etc/mac80211-post-add.sh ] && /etc/mac80211-post-add.sh "$ifname" +         json_select ..  }