[OpenWrt-Devel] Setting *wireless* MTU, "UCI-compliant" way?

Message ID d1961f91-500e-acf8-baf5-bb44555b1305@wagsky.com
State Not Applicable
Delegated to: John Crispin
Headers show
Series
  • [OpenWrt-Devel] Setting *wireless* MTU, "UCI-compliant" way?
Related show

Commit Message

Jeff Kletsky April 30, 2018, 3:59 p.m.
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 '<redacted>'
     option mesh_fwding '1'
     option encryption 'psk2+ccmp'
     option key '<redacted>'
     option sae_password '<redacted>'

(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

Comments

Daniel Golle April 30, 2018, 4:55 p.m. | #1
Hi Jeff,

On Mon, Apr 30, 2018 at 08:59:12AM -0700, Jeff Kletsky wrote:
> 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.

The wireless config section is kinda only up to layer 1.5, so
everything on netdev level has to be done in the network UCI config.
Example:

config interface 'wireless0'
	option proto 'none'
	option mtu '1536'

(in order to avoid batman-adv fragmenting)


Cheers


Daniel

Patch

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