Jeff Kletsky
2018-04-30 15:59:12 UTC
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
--- 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
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
--- 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