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 11:25:41 +0200 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2352922712081882649==" List-Id: --===============2352922712081882649== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, So I have now tested out with setting high and low MTU values in the red setu= p stage. In all cases with both the dhcpcd-10.0.10 + dhcpcd.exe patch or with a standa= rd CU187, there is no MTU value in dhcpcd-red0.info and also the mtu value sh= own for red0 with ip address show is always 1500 irrespective of reboot or no= t. The force MTU value is being stored somewhere because if I rerun the setup, b= efore or after a reboot, the value I entered for the force MTU is still there. Maybe I am not looking in the right place to see where the mtu has been force= d. What I can say, is that for a standard dhcp connection the version 10.0.10 wi= th the dhcpcd.exe patch mod works fine for making a red connection. Regards, Adolf. On 04/09/2024 09:54, Adolf Belka wrote: > 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 r= oute 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 b= asically a way to signal to the other party to not send packets larger than t= he 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-= to-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 th= e routes. This is because stupid hardware vendors cannot figure out their shi= t 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 M= TU to the interface MTU which will then fragment packets as soon as the kerne= l selects that route. >>>> We didn=E2=80=99t adopt that change in our scripts although we could eas= ily 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 ou= t 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 othe= r systems 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/= networking/dhcpcd.exe;h=3Dc8a79999dced000925f35bb4d244ce420077c13c;hb=3DHEAD). >>>> That would be an acceptable workaround since we have not seen too many o= f 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/net= working/dhcpcd.exe >>>> index c8a79999d..870aef6a6 100644 >>>> --- a/src/initscripts/networking/dhcpcd.exe >>>> +++ b/src/initscripts/networking/dhcpcd.exe >>>> @@ -46,6 +46,14 @@ dhcpcd_up() >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 update=3D1; >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 fi >>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # Assume an MTU of 1500 unless som= ething else is configured >>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if [ -z "${interface_mtu}" ]; then >>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 interface_mtu=3D"1500" >>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 fi >>>> + >>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # Set the MTU >>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ip link set "${interface}" mtu "${= interface_mtu}" >>>> + >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # Get DNS from dhcp >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /etc/rc.d/helper/getdns= fromdhcpc.pl 1 > /var/run/dns1 >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /etc/rc.d/helper/getdns= fromdhcpc.pl 2 > /var/run/dns2 >>>> -Michael > > I built dhcpcd-10.0.10 with the above modifications made to dhcpcd.exe and = installed the resultant build on a vm system. > > It started up fine and made a successful dhcp connection via red. There was= no mtu entry in dhcpcd-red0.info > > I then ran setup from the console and added an entry into the mtu line (148= 3) and then exited. It restarted networking successfully but there was no mtu= entry in dhcpcd-red0.info > > I then did a fresh install of the the change again and during the installat= ion phase I set the mtu to 1483. Successfully connected via red but again no = mtu entry in dhcpcd-red0.info > > Is the above the checks that were required, or have I missed something to d= o/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 i= n the mtu definition section that means that the patch we have had to allow f= ree 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 t= hey have done will give us the equivalent of the patched result we used to ha= ve or if a totally new patch needs to be created to deal with the changed cod= ing. >>>>> >>>>> The commit with the change is >>>>> >>>>> https://github.com/NetworkConfiguration/dhcpcd/commit/5ac1235b99d33085d= 0574ef81b95ceafcf79db34 >>>>> >>>>> 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 m= ight be in line with what we want to have but I have no idea of how to test t= his and I don't understand the changes well enough to know if give us the res= ult of users having free selection of the mtu. >>>>> >>>>> Can someone more experienced look through the changes to see if they ar= e okay, before I look at doing a package update build for the updated version. >>>>> >>>>> Regards, >>>>> >>>>> Adolf. >>>>> --===============2352922712081882649==--