[OpenWrt-Devel] netifd: per-interface MTU settings vs per-route MTU settings?

[Reuben Dowle]

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
reuben.dowle at 4rf.com<mailto:reuben.dowle at 4rf.com>
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 <openwrt-devel-bounces at lists.openwrt.org> On Behalf Of Michael Jones
Sent: Tuesday, 26 May 2020 5:21 am
To: Aleksander Morgado <aleksander at aleksander.es>
Cc: openwrt-devel <openwrt-devel at lists.openwrt.org>
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 <aleksander at aleksander.es<mailto:aleksander at aleksander.es>> 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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20200602/5faa03d9/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4RFLogo(Custom)(2)_0f31a7de-6dd6-43cf-bc6a-a097a2b80b69.jpg
Type: image/jpeg
Size: 3500 bytes
Desc: 4RFLogo(Custom)(2)_0f31a7de-6dd6-43cf-bc6a-a097a2b80b69.jpg
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20200602/5faa03d9/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Family_53c410b1-7227-4a5f-9acb-f09bd7617a39.png
Type: image/png
Size: 69144 bytes
Desc: Family_53c410b1-7227-4a5f-9acb-f09bd7617a39.png
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20200602/5faa03d9/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: add_device_attribute_set_ubus.patch
Type: application/octet-stream
Size: 2061 bytes
Desc: add_device_attribute_set_ubus.patch
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20200602/5faa03d9/attachment.obj>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel