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: Wed, 04 Sep 2024 21:39:45 +0200 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6805843540697314521==" List-Id: --===============6805843540697314521== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable That is a very good question. We would not need any changes if we let dhcpcd handle this using its route me= chanism. So, well=E2=80=A6 let=E2=80=99s try. I just don=E2=80=99t know what will happen to things like the QoS when it ass= umes a different MTU. I have so many questions. -Michael > On 4 Sep 2024, at 11:46, Adolf Belka wrote: >=20 > Hi, >=20 > On 04/09/2024 11:33, Michael Tremer wrote: >> Hello, >> Hmm, I think you might be right, there does not seem to be any code where = interface_mtu is being set, but it is read from the command line: >> https://git.ipfire.org/?p=3Dthirdparty%2Fdhcpcd.git&a=3Dsearch&h=3DHEAD&= st=3Dgrep&s=3Dinterface_mtu >> It is then only being used when inserting any routes into the routing tabl= e: >> https://git.ipfire.org/?p=3Dthirdparty/dhcpcd.git;a=3Dblob;f=3Dsrc/ipv4.= c;hb=3Dab5ec18e755c1bb450c74d3a4657ea48d0f7f314#l355 >> This is a little bit of a bummer for us unless we want to continue the rou= te option. I don=E2=80=99t know what disadvantages that would bring. Probably= nothing serious, but we might misconfigure static routes. >=20 > So when I submit the update patch for 10.0.10 should I also add your patch = mod for dhcpcd.exe? >=20 > Regards, > Adolf. >=20 >> -Michael >>> On 4 Sep 2024, at 11:25, Adolf Belka wrote: >>>=20 >>> Hi Michael, >>>=20 >>> So I have now tested out with setting high and low MTU values in the red = setup stage. >>>=20 >>> In all cases with both the dhcpcd-10.0.10 + dhcpcd.exe patch or with a st= andard CU187, there is no MTU value in dhcpcd-red0.info and also the mtu valu= e shown for red0 with ip address show is always 1500 irrespective of reboot o= r not. >>>=20 >>> The force MTU value is being stored somewhere because if I rerun the setu= p, before or after a reboot, the value I entered for the force MTU is still t= here. >>>=20 >>> Maybe I am not looking in the right place to see where the mtu has been f= orced. >>>=20 >>> What I can say, is that for a standard dhcp connection the version 10.0.1= 0 with the dhcpcd.exe patch mod works fine for making a red connection. >>>=20 >>> Regards, >>>=20 >>> Adolf. >>>=20 >>> On 04/09/2024 09:54, Adolf Belka wrote: >>>> Hi Michael, >>>>=20 >>>> On 03/09/2024 10:24, Michael Tremer wrote: >>>>> Hello Nick, >>>>>=20 >>>>> Good thinking. This might actually not work any more if we are using th= e route option. I hope it does, but we might have to test. >>>>>=20 >>>>> It would not solve the entire problem as this only applies to TCP and i= s basically a way to signal to the other party to not send packets larger tha= n the MTU as it assumes that it will be symmetric. >>>>>=20 >>>>> -Michael >>>>>=20 >>>>>> On 3 Sep 2024, at 10:22, Nick Howitt wrote: >>>>>>=20 >>>>>> I really don't know if this is a red herring, but if you use --clamp-m= ss-to-pmtu in the firewall, does it get round the need to set an MTU at all? >>>>>>=20 >>>>>> Nick >>>>>>=20 >>>>>> 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 wi= ll trigger dhcpcd to fetch another lease and reset the MTU again, and then fe= tch another lease, and so on. >>>>>>> Instead they will configure routes in the kernel that have a differen= t MTU to the interface MTU which will then fragment packets as soon as the ke= rnel selects that route. >>>>>>> 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 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 entir= ely 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 o= ther systems that I checked have it. So we could move setting the MTU to dhcp= cd.exe (https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dblob;f=3Dsrc/initscrip= ts/networking/dhcpcd.exe;h=3Dc8a79999dced000925f35bb4d244ce420077c13c;hb=3DHE= AD). >>>>>>> That would be an acceptable workaround since we have not seen too man= y of those resets with our users and we would emulate the same behaviour. Cou= ld you test this, please? >>>>>>> root(a)michael:/build/ipfire-2.x# git diff >>>>>>> diff --git a/src/initscripts/networking/dhcpcd.exe b/src/initscripts/= networking/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 >>>>=20 >>>> I built dhcpcd-10.0.10 with the above modifications made to dhcpcd.exe a= nd installed the resultant build on a vm system. >>>>=20 >>>> It started up fine and made a successful dhcp connection via red. There = was no mtu entry in dhcpcd-red0.info >>>>=20 >>>> 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 entry in dhcpcd-red0.info >>>>=20 >>>> I then did a fresh install of the the change again and during the instal= lation phase I set the mtu to 1483. Successfully connected via red but again = no mtu entry in dhcpcd-red0.info >>>>=20 >>>> Is the above the checks that were required, or have I missed something t= o do/check. >>>>=20 >>>> Regards, >>>>=20 >>>> Adolf. >>>>=20 >>>>>>>> On 2 Sep 2024, at 18:29, Adolf Belka wrot= e: >>>>>>>>=20 >>>>>>>> Dear All, >>>>>>>>=20 >>>>>>>> dhcpcd-10.0.10 is available but I noticed that a change has been mad= e in the mtu definition section that means that the patch we have had to allo= w 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 wha= t 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. >>>>>>>>=20 >>>>>>>> The commit with the change is >>>>>>>>=20 >>>>>>>> https://github.com/NetworkConfiguration/dhcpcd/commit/5ac1235b99d330= 85d0574ef81b95ceafcf79db34 >>>>>>>>=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 i= t might be in line with what we want to have but I have no idea of how to tes= t 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 okay, before I look at doing a package update build for the updated vers= ion. >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>>=20 >>>>>>>> Adolf. >>>>>>>>=20 --===============6805843540697314521==--