Hi,
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=thirdparty%2Fdhcpcd.git&a=search&h=HEAD&am...
It is then only being used when inserting any routes into the routing table:
https://git.ipfire.org/?p=thirdparty/dhcpcd.git;a=blob;f=src/ipv4.c;hb=ab5ec...
This is a little bit of a bummer for us unless we want to continue the route option. I don’t 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 mod for dhcpcd.exe?
Regards, Adolf.
-Michael
On 4 Sep 2024, at 11:25, Adolf Belka adolf.belka@ipfire.org wrote:
Hi Michael,
So I have now tested out with setting high and low MTU values in the red setup stage.
In all cases with both the dhcpcd-10.0.10 + dhcpcd.exe patch or with a standard 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 there.
Maybe I am not looking in the right place to see where the mtu has been forced.
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 nick@howitts.co.uk 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 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 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 MTU to the interface MTU which will then fragment packets as soon as the kernel selects that route. We didn’t 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 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 http://dhcpcd-red0.info/, but some other systems that I checked have it. So we could move setting the MTU to dhcpcd.exe (https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=src/initscripts/networking...). 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@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=1; fi
# Assume an MTU of 1500 unless something else is configuredif [ -z "${interface_mtu}" ]; theninterface_mtu="1500"fi# Set the MTUip 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 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 (1483) 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 installation 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 do/check.
Regards,
Adolf.
> On 2 Sep 2024, at 18:29, Adolf Belka adolf.belka@ipfire.org 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 coding. > > The commit with the change is > > https://github.com/NetworkConfiguration/dhcpcd/commit/5ac1235b99d33085d0574e... > > 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 result 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. >