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 11:33:32 +0200 Message-ID: <0E57C39A-890A-4CB4-8319-68A9716CB6F1@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2145618835614728625==" List-Id: --===============2145618835614728625== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, Hmm, I think you might be right, there does not seem to be any code where int= erface_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 table: https://git.ipfire.org/?p=3Dthirdparty/dhcpcd.git;a=3Dblob;f=3Dsrc/ipv4.c;h= b=3Dab5ec18e755c1bb450c74d3a4657ea48d0f7f314#l355 This is a little bit of a bummer for us unless we want to continue the route = option. I don=E2=80=99t know what disadvantages that would bring. Probably no= thing serious, but we might misconfigure static routes. -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 se= tup stage. >=20 > In all cases with both the dhcpcd-10.0.10 + dhcpcd.exe patch or with a stan= dard 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. >=20 > 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 the= re. >=20 > Maybe I am not looking in the right place to see where the mtu has been for= ced. >=20 > 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. >=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 the = 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 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. >>>=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-mss= -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 lo= t. >>>>> They no longer will set the interface MTU, but instead will set it to t= he routes. This is because stupid hardware vendors cannot figure out their sh= it 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 fetc= h 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 kern= el selects that route. >>>>> We didn=E2=80=99t adopt that change in our scripts although we could ea= sily do this for the default route. However, the problems begin when there ar= e static routes pointing at the RED interface. We would then have to figure o= ut what the MTU is and set it for all static routes, too. This is not entirel= y trivial although not the biggest problem ever. >>>>> Looking at what I am getting from a cable model here, there is no MTU i= n /var/ipfire/dhcpc/dhcpcd-red0.info , but some oth= er 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 = of 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/ne= tworking/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 and= installed the resultant build on a vm system. >>=20 >> It started up fine and made a successful dhcp connection via red. There wa= s no mtu entry in dhcpcd-red0.info >>=20 >> I then ran setup from the console and added an entry into the mtu line (14= 83) and then exited. It restarted networking successfully but there was no mt= u entry in dhcpcd-red0.info >>=20 >> I then did a fresh install of the the change again and during the installa= tion 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 to = do/check. >>=20 >> Regards, >>=20 >> Adolf. >>=20 >>>>>> On 2 Sep 2024, at 18:29, Adolf Belka wrote: >>>>>>=20 >>>>>> Dear All, >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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 h= ave or if a totally new patch needs to be created to deal with the changed co= ding. >>>>>>=20 >>>>>> The commit with the change is >>>>>>=20 >>>>>> https://github.com/NetworkConfiguration/dhcpcd/commit/5ac1235b99d33085= d0574ef81b95ceafcf79db34 >>>>>>=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 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 re= sult of users having free selection of the mtu. >>>>>>=20 >>>>>> Can someone more experienced look through the changes to see if they a= re okay, before I look at doing a package update build for the updated versio= n. >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Adolf. >>>>>>=20 --===============2145618835614728625==--