From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: The MTU definition part of dhcpcd has been rewritten in version 10.0.10 Date: Tue, 03 Sep 2024 09:45:48 +0200 Message-ID: <009F334C-C3B8-4CC9-B10C-D516945332B7@ipfire.org> In-Reply-To: <452a98a2-d939-4180-be81-e84244409d41@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5141820077749280957==" List-Id: --===============5141820077749280957== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 rou= tes. 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 trigg= er dhcpcd to fetch another lease and reset the MTU again, and then fetch anot= her 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 sel= ects that route. We didn=E2=80=99t adopt that change in our scripts although we could easily d= o this for the default route. However, the problems begin when there are stat= ic routes pointing at the RED interface. We would then have to figure out wha= t the MTU is and set it for all static routes, too. This is not entirely triv= ial 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 , but some other sys= tems that I checked have it. So we could move setting the MTU to dhcpcd.exe (= https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dblob;f=3Dsrc/initscripts/netwo= rking/dhcpcd.exe;h=3Dc8a79999dced000925f35bb4d244ce420077c13c;hb=3DHEAD). That would be an acceptable workaround since we have not seen too many of tho= se resets with our users and we would emulate the same behaviour. Could you t= est this, please? root(a)michael:/build/ipfire-2.x# git diff diff --git a/src/initscripts/networking/dhcpcd.exe b/src/initscripts/networki= ng/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=3D1; fi + # Assume an MTU of 1500 unless something else is configured + if [ -z "${interface_mtu}" ]; then + interface_mtu=3D"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 wrote: >=20 > Dear All, >=20 > dhcpcd-10.0.10 is available but I noticed that a change has been made in th= e mtu definition section that means that the patch we have had to allow free = selection of the MTU by the user will not apply. >=20 > 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 o= r if a totally new patch needs to be created to deal with the changed coding. >=20 > The commit with the change is >=20 > https://github.com/NetworkConfiguration/dhcpcd/commit/5ac1235b99d33085d0574= ef81b95ceafcf79db34 >=20 > The issue that triggered the change >=20 > https://github.com/NetworkConfiguration/dhcpcd/pull/346 >=20 > 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. >=20 > Can someone more experienced look through the changes to see if they are ok= ay, before I look at doing a package update build for the updated version. >=20 > Regards, >=20 > Adolf. >=20 --===============5141820077749280957==--