[LEDE-DEV] "Native" way to set a wireless link's MTU?

[Jeff Kletsky]

I've been struggling with an OpenWRT configuration to get a specific
wireless link to come with with an MTU of higher than 1500. I have
administrative control over all endpoints so interop is not a concern.

At least as I understand it, 802.11 itself has a 2304 MTU and I'd like
to explicitly take advantage of a few dozen bytes of that on a
dedicated link that is tunneling encapsulated 1500-MTU packets at
Layer 2. PMTU discovery over the restricted link fails, likely because
the packets are not _routed_ and are dropped silently by the Linux
bridge.

clients   "External" clients, unaware that there is a sub-1500 PMTU
  or that PMTU discovery will fail
 | | |

 br-XXX   MTU 1500 ok; adopts MTU as minimum of bridged interfaces

   |

gre4t-gt  Can set to MTU 1500 with UCI
  adds 24 bytes GRE over IPv4 + 22(?) bytes of L2 encap
   |

br-mesh   Need "1548+" MTU; adopts MTU as that of bridged interface, mesh0
  Assigned the tunnel endpoint IP address
   |  "Required" for UCI config as apparently can't directly modify 
mesh0


 mesh0   Auto-generated wireless interface; comes up with 1500 MTU

   Ψ

(the reverse on the other side of the link)


The "obvious" approach of explicitly naming the wireless interface
("mesh0") in /etc/config/wireless and setting the mtu in
/etc/config/network doesn't seem to work.

config interface 'mesh0'
    option mtu 2304

(either with or without "option proto none")

I can change the MTU of the wireless link "manually" with ip with some
kind of an "interface-up" script, but would prefer to handle this
"natively" with netifd, wpa_supplicant, or the like.

"In a perfect world" I would also be able to set the IP address directly
on the wireless device, getting rid of br-mesh entirely, but I haven't
found a way to accomplish that through UCI configuration.

I'm not adverse to patching code and compiling a custom image.

TIA,

Jeff



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Setting *wireless* MTU, "UCI-compliant" way?

[Jeff Kletsky]

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

--- 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 ..
 }


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




___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev