From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: The MTU definition part of dhcpcd has been rewritten in version 10.0.10 Date: Wed, 04 Sep 2024 09:54:41 +0200 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0275456635001334106==" List-Id: --===============0275456635001334106== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, On 03/09/2024 10:24, Michael Tremer wrote: > Hello Nick, > > Good thinking. This might actually not work any more if we are using the ro= ute option. I hope it does, but we might have to test. > > It would not solve the entire problem as this only applies to TCP and is ba= sically a way to signal to the other party to not send packets larger than th= e MTU as it assumes that it will be symmetric. > > -Michael > >> On 3 Sep 2024, at 10:22, Nick Howitt wrote: >> >> I really don't know if this is a red herring, but if you use --clamp-mss-t= o-pmtu in the firewall, does it get round the need to set an MTU at all? >> >> Nick >> >> On 03/09/2024 08:45, Michael Tremer wrote: >>> 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 t= rigger 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 MT= U to the interface MTU which will then fragment packets as soon as the kernel= selects that route. >>> We didn=E2=80=99t adopt that change in our scripts although we could easi= ly 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 , but some other= systems that I checked have it. So we could move setting the MTU to dhcpcd.e= xe (https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dblob;f=3Dsrc/initscripts/n= etworking/dhcpcd.exe;h=3Dc8a79999dced000925f35bb4d244ce420077c13c;hb=3DHEAD). >>> 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 y= ou test this, please? >>> root(a)michael:/build/ipfire-2.x# git diff >>> diff --git a/src/initscripts/networking/dhcpcd.exe b/src/initscripts/netw= orking/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 I built dhcpcd-10.0.10 with the above modifications made to dhcpcd.exe and in= stalled the resultant build on a vm system. It started up fine and made a successful dhcp connection via red. There was n= o mtu entry in dhcpcd-red0.info I then ran setup from the console and added an entry into the mtu line (1483)= and then exited. It restarted networking successfully but there was no mtu e= ntry in dhcpcd-red0.info I then did a fresh install of the the change again and during the installatio= n phase I set the mtu to 1483. Successfully connected via red but again no mt= u entry in dhcpcd-red0.info Is the above the checks that were required, or have I missed something to do/= check. Regards, Adolf. >>>> 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= the mtu definition section that means that the patch we have had to allow fr= ee 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 th= ey have done will give us the equivalent of the patched result we used to hav= e or if a totally new patch needs to be created to deal with the changed codi= ng. >>>> >>>> The commit with the change is >>>> >>>> https://github.com/NetworkConfiguration/dhcpcd/commit/5ac1235b99d33085d0= 574ef81b95ceafcf79db34 >>>> >>>> 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 mi= ght be in line with what we want to have but I have no idea of how to test th= is and I don't understand the changes well enough to know if give us the resu= lt 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. >>>> --===============0275456635001334106==--