When changing an interface MTU direct through ip command, netifd will get be
out of sync. The netifd internally tracked MTU (discoverable through ubus call
network.device status '{"name":"xxx"}' call will always show 1500 (or whatever
the value was when netifd discovered/created the interface).
I am not aware of any actual issues caused by this, but it is worth considering.
Finding some method to update through ubus is preferable in my opinion.
For the project I have been working on, we added a ubus network.device set_attr
method to netifd to solve this problem – see attached patch. Then you can use
this in the protocol handler:
[ -n "$mtu" ] && {
echo "Setting MTU to $mtu"
/sbin/ubus call network.device set_attr
"{\"device\":\"$ifname\", \"mtu\":\"$mtu\"}"
}
________________________________
[cid:4RFLogo(Custom)(2)_0f31a7de-6dd6-43cf-bc6a-a097a2b80b69.jpg]
Reuben Dowle
Software Architect
Phone:
Fax:
E-Mail:
Website:
+64 4 499 6000
+64 4 473 4447
[email protected]<mailto:[email protected]>
Https://www.4rf.com<https://www.4rf.com>
________________________________
[cid:Family_53c410b1-7227-4a5f-9acb-f09bd7617a39.png]
<http://www.4rf.com/news/events>
From: openwrt-devel <[email protected]> On Behalf Of
Michael Jones
Sent: Tuesday, 26 May 2020 5:21 am
To: Aleksander Morgado <[email protected]>
Cc: openwrt-devel <[email protected]>
Subject: Re: [OpenWrt-Devel] netifd: per-interface MTU settings vs per-route
MTU settings?
On Mon, May 25, 2020 at 8:00 AM Aleksander Morgado
<[email protected]<mailto:[email protected]>> wrote:
Other protocol handlers, like uqmi, are also able to setup the MTU,
and instead of doing it via proto_send_update, they just do it like
this:
[ -n "$mtu" ] && {
echo "Setting MTU to $mtu"
/sbin/ip link set dev $ifname mtu $mtu
}
I guess we can do the same in the ModemManager protocol handler.
That does seem like it would work, but I'm wary of race conditions with the
message sent to netifd via ubus, and further feel like it would be better to
have netifd learn how to set the mtu directly, if it doesn't already know how.
Are any of the netifd project's contributors able to comment on this?
________________________________
The information in this email communication (inclusive of attachments) is
confidential to 4RF Limited and the intended recipient(s). If you are not the
intended recipient(s), please note that any use, disclosure, distribution or
copying of this information or any part thereof is strictly prohibited and that
the author accepts no liability for the consequences of any action taken on the
basis of the information provided. If you have received this email in error,
please notify the sender immediately by return email and then delete all
instances of this email from your system. 4RF Limited will not accept
responsibility for any consequences associated with the use of this email
(including, but not limited to, damages sustained as a result of any viruses
and/or any action or lack of action taken in reliance on it).
add_device_attribute_set_ubus.patch
Description: add_device_attribute_set_ubus.patch
_______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
