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:46:36 +0200 Message-ID: In-Reply-To: <0E57C39A-890A-4CB4-8319-68A9716CB6F1@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3603433746614283690==" List-Id: --===============3603433746614283690== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, On 04/09/2024 11:33, Michael Tremer wrote: > Hello, >=20 > Hmm, I think you might be right, there does not seem to be any code where i= nterface_mtu is being set, but it is read from the command line: >=20 > https://git.ipfire.org/?p=3Dthirdparty%2Fdhcpcd.git&a=3Dsearch&h=3DHEAD&= st=3Dgrep&s=3Dinterface_mtu >=20 > It is then only being used when inserting any routes into the routing table: >=20 > https://git.ipfire.org/?p=3Dthirdparty/dhcpcd.git;a=3Dblob;f=3Dsrc/ipv4.= c;hb=3Dab5ec18e755c1bb450c74d3a4657ea48d0f7f314#l355 >=20 > This is a little bit of a bummer for us unless we want to continue the rout= e option. I don=E2=80=99t know what disadvantages that would bring. Probably = nothing serious, but we might misconfigure static routes. So when I submit the update patch for 10.0.10 should I also add your patch mo= d for dhcpcd.exe? Regards, Adolf. >=20 > -Michael >=20 >> On 4 Sep 2024, at 11:25, Adolf Belka wrote: >> >> Hi Michael, >> >> So I have now tested out with setting high and low MTU values in the red s= etup stage. >> >> In all cases with both the dhcpcd-10.0.10 + dhcpcd.exe patch or with a sta= ndard CU187, there is no MTU value in dhcpcd-red0.info and also the mtu value= shown for red0 with ip address show is always 1500 irrespective of reboot or= not. >> >> The force MTU value is being stored somewhere because if I rerun the setup= , before or after a reboot, the value I entered for the force MTU is still th= ere. >> >> Maybe I am not looking in the right place to see where the mtu has been fo= rced. >> >> What I can say, is that for a standard dhcp connection the version 10.0.10= with 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= route 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= basically a way to signal to the other party to not send packets larger than= the 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-ms= s-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 l= ot. >>>>>> 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 s= hit and might reset the Ethernet link when the MTU is being changed. That wil= l trigger dhcpcd to fetch another lease and reset the MTU again, and then fet= ch 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 ker= nel selects that route. >>>>>> We didn=E2=80=99t adopt that change in our scripts although we could e= asily do this for the default route. However, the problems begin when there a= re 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 entire= ly 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 ot= her systems that I checked have it. So we could move setting the MTU to dhcpc= d.exe (https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dblob;f=3Dsrc/initscript= s/networking/dhcpcd.exe;h=3Dc8a79999dced000925f35bb4d244ce420077c13c;hb=3DHEA= D). >>>>>> 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. Coul= d you test this, please? >>>>>> root(a)michael:/build/ipfire-2.x# git diff >>>>>> diff --git a/src/initscripts/networking/dhcpcd.exe b/src/initscripts/n= etworking/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 an= d installed the resultant build on a vm system. >>> >>> It started up fine and made a successful dhcp connection via red. There w= as no mtu entry in dhcpcd-red0.info >>> >>> I then ran setup from the console and added an entry into the mtu line (1= 483) and then exited. It restarted networking successfully but there was no m= tu entry in dhcpcd-red0.info >>> >>> I then did a fresh install of the the change again and during the install= ation phase I set the mtu to 1483. Successfully connected via red but again n= o mtu 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= 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 c= oding. >>>>>>> >>>>>>> The commit with the change is >>>>>>> >>>>>>> https://github.com/NetworkConfiguration/dhcpcd/commit/5ac1235b99d3308= 5d0574ef81b95ceafcf79db34 >>>>>>> >>>>>>> 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 r= esult 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 versi= on. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Adolf. >>>>>>> >=20 --===============3603433746614283690==--