From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Testing of rapid_commit patch Date: Fri, 29 Nov 2024 16:20:50 +0000 Message-ID: <7D147195-B817-49A0-9900-03F756ECE743@ipfire.org> In-Reply-To: <5f671b37-de3f-4057-839a-7a85f91ededc@howitts.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3655439014660283138==" List-Id: --===============3655439014660283138== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I would also like to explore whether this isn=E2=80=99t best implemented in d= hcpcd instead of us playing try and error. Or people could just fix their broken DHCP servers. Rapid commit is from the = 90s and has worked well for a long time. And suddenly it breaks. > On 29 Nov 2024, at 15:03, Nick Howitt wrote: >=20 >=20 >=20 >=20 > On 29/11/2024 14:11, Michael Tremer wrote: >> Hello, >>=20 >>=20 >>> On 29 Nov 2024, at 11:50, Nick Howitt wrote: >>>=20 >>>=20 >>>=20 >>>=20 >>> On 29/11/2024 11:21, Adolf Belka wrote: >>>=20 >>>> Hi Michael,=20 >>>>=20 >>>> I had previously tested your rapid_commit patch on my vm network system.= However as that network does not have a problem with the rapid_commit option= it was not the best test.=20 >>>>=20 >>>> I said that i would test it out on my production system after the visit = to my family. I have now got around to that.=20 >>>>=20 >>>> My new ISP, that bought out the very good technically based ISP I used t= o have, is one of the ones that has a DHCP server that just times out if you = have the rapid_commit option in the dhcpcd config file.=20 >>>>=20 >>>> So I updated my production IPFire to Core-Update 190 Development Build: = master/1e2abd66=20 >>>>=20 >>>> After rebooting the connection was lost as the rapid_commit option is on= by default.=20 >>>>=20 >>>> I then ran the setup program and unchecked the rapid commit box on the r= ed interface and then rebooted and the connection was running.=20 >>>>=20 >>>> Another reboot still had the connection running.=20 >>>>=20 >>>> So I can confirm that the patch is working .=20 >>>>=20 >>>> The only thing that came to mind is when we do the update people who hav= e removed or commented out the rapid_commit option in dhcpcd.conf will lose t= heir connection.=20 >>>>=20 >>>> So either=20 >>>>=20 >>>> * we need to have the update check if the rapid_commit option has been c= ommented out or has been removed and then disable the rapid commit option for= the red interface.=20 >>>>=20 >>>> or=20 >>>>=20 >>>> * we need to make sure that it is well communicated that anyone who has = disabled the rapid_commit option needs to run the setup program after the upg= rade (maybe before the reboot) to disable the option for the red interface.=20 >>>>=20 >>>> We can discuss this at our next conf call meeting on 3rd or 4th Dec.=20 >>>>=20 >>>> Regards,=20 >>>>=20 >>>> Adolf.=20 >>>>=20 >>>>=20 >>> Can you not try to automate the upgrade so that it initially tries DHCP w= ith rapid_commit enabled. If it times out, retry with rapid_commit disabled. = If that succeeds, then keep rapid_commit disabled. If it fails, re-enable rap= id_commit then fail? It could also be done for new installations choosing DHC= P and for installations switching from Static/PPPoE to DHCP. >>>=20 >> This would be a great method - if we have to accept that ISPs are now runn= ing this completely broken DHCP services. >>=20 >> However, the code does not easily allow this. We should not generally disa= ble the setting if someone failed to plug a cable in and looking at how few p= eople actually run into this problem at this time, we might not need to over = engineer this. >>=20 >>=20 > If the user didn't plug the cable in then the second DHCP would fail and I = was saying, in that case, revert to rapid_commit enabled (unless the user had= manually disabled it). >=20 > And yes, it could be over-engineering. --===============3655439014660283138==--