Re: The MTU definition part of dhcpcd has been rewritten in version 10.0.10

[Michael Tremer <michael.tremer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 3506 bytes --]

Good morning,

This is a good catch as this changes the behaviour of dhcpcd quite a lot.

They no longer will set the interface MTU, but instead will set it to the routes. This is because stupid hardware vendors cannot figure out their shit and might reset the Ethernet link when the MTU is being changed. That will trigger dhcpcd to fetch another lease and reset the MTU again, and then fetch another lease, and so on.

Instead they will configure routes in the kernel that have a different MTU to the interface MTU which will then fragment packets as soon as the kernel selects that route.

We didn’t adopt that change in our scripts although we could easily do this for the default route. However, the problems begin when there are static routes pointing at the RED interface. We would then have to figure out what the MTU is and set it for all static routes, too. This is not entirely trivial although not the biggest problem ever.

Looking at what I am getting from a cable model here, there is no MTU in /var/ipfire/dhcpc/dhcpcd-red0.info <http://dhcpcd-red0.info/>, but some other systems that I checked have it. So we could move setting the MTU to dhcpcd.exe (https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=src/initscripts/networking/dhcpcd.exe;h=c8a79999dced000925f35bb4d244ce420077c13c;hb=HEAD).

That would be an acceptable workaround since we have not seen too many of those resets with our users and we would emulate the same behaviour. Could you test this, please?

root(a)michael:/build/ipfire-2.x# git diff
diff --git a/src/initscripts/networking/dhcpcd.exe b/src/initscripts/networking/dhcpcd.exe
index c8a79999d..870aef6a6 100644
--- a/src/initscripts/networking/dhcpcd.exe
+++ b/src/initscripts/networking/dhcpcd.exe
@@ -46,6 +46,14 @@ dhcpcd_up()
                update=1;
        fi

+       # Assume an MTU of 1500 unless something else is configured
+       if [ -z "${interface_mtu}" ]; then
+               interface_mtu="1500"
+       fi
+
+       # Set the MTU
+       ip link set "${interface}" mtu "${interface_mtu}"
+
        # Get DNS from dhcp
        /etc/rc.d/helper/getdnsfromdhcpc.pl 1 > /var/run/dns1
        /etc/rc.d/helper/getdnsfromdhcpc.pl 2 > /var/run/dns2

-Michael

> On 2 Sep 2024, at 18:29, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
> 
> Dear All,
> 
> dhcpcd-10.0.10 is available but I noticed that a change has been made in the mtu definition section that means that the patch we have had to allow free selection of the MTU by the user will not apply.
> 
> I have had a look through the changes but I can not determine if what they have done will give us the equivalent of the patched result we used to have or if a totally new patch needs to be created to deal with the changed coding.
> 
> The commit with the change is
> 
> https://github.com/NetworkConfiguration/dhcpcd/commit/5ac1235b99d33085d0574ef81b95ceafcf79db34
> 
> The issue that triggered the change
> 
> https://github.com/NetworkConfiguration/dhcpcd/pull/346
> 
> is labelled "No longer set interface mtu" which would suggest that it might be in line with what we want to have but I have no idea of how to test this and I don't understand the changes well enough to know if give us the result of users having free selection of the mtu.
> 
> Can someone more experienced look through the changes to see if they are okay, before I look at doing a package update build for the updated version.
> 
> Regards,
> 
> Adolf.
>