From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Howitt 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:22:22 +0100 Message-ID: <40cc9dc2-fe89-4d8c-8558-69b27d63912e@howitts.co.uk> In-Reply-To: <009F334C-C3B8-4CC9-B10C-D516945332B7@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7086730636761576536==" List-Id: --===============7086730636761576536== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I really don't know if this is a red herring, but if you use=20 --clamp-mss-to-pmtu in the firewall, does it get round the need to set=20 an MTU at all? Nick On 03/09/2024 08:45, Michael Tremer wrote: >=20 > Good morning, >=20 > This is a good catch as this changes the behaviour of dhcpcd quite a lot. >=20 > They no longer will set the interface MTU, but instead will set it to the r= outes. This is because stupid hardware vendors cannot figure out their shit a= nd might reset the Ethernet link when the MTU is being changed. That will tri= gger dhcpcd to fetch another lease and reset the MTU again, and then fetch an= other lease, and so on. >=20 > 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 s= elects that route. >=20 > We didn=E2=80=99t adopt that change in our scripts although we could easily= do this for the default route. However, the problems begin when there are st= atic routes pointing at the RED interface. We would then have to figure out w= hat the MTU is and set it for all static routes, too. This is not entirely tr= ivial although not the biggest problem ever. >=20 > Looking at what I am getting from a cable model here, there is no MTU in /v= ar/ipfire/dhcpc/dhcpcd-red0.info , but some other s= ystems 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/net= working/dhcpcd.exe;h=3Dc8a79999dced000925f35bb4d244ce420077c13c;hb=3DHEAD). >=20 > That would be an acceptable workaround since we have not seen too many of t= hose resets with our users and we would emulate the same behaviour. Could you= test this, please? >=20 > root(a)michael:/build/ipfire-2.x# git diff > diff --git a/src/initscripts/networking/dhcpcd.exe b/src/initscripts/networ= king/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 >=20 > + # 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 >=20 > -Michael >=20 >> On 2 Sep 2024, at 18:29, Adolf Belka wrote: >> >> Dear All, >> >> dhcpcd-10.0.10 is available but I noticed that a change has been made in t= he 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/5ac1235b99d33085d057= 4ef81b95ceafcf79db34 >> >> 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 migh= t 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 o= kay, before I look at doing a package update build for the updated version. >> >> Regards, >> >> Adolf. >> >=20 --===============7086730636761576536==--