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 14:11:57 +0000 Message-ID: <3DCA1B39-9862-4854-97E9-C7CB0E79B542@ipfire.org> In-Reply-To: <92cb066c-6678-49ca-bbd2-44e4c75c672d@howitts.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7616748093696509248==" List-Id: --===============7616748093696509248== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 29 Nov 2024, at 11:50, Nick Howitt wrote: >=20 >=20 >=20 >=20 > On 29/11/2024 11:21, Adolf Belka wrote: >> Hi Michael,=20 >>=20 >> I had previously tested your rapid_commit patch on my vm network system. H= owever as that network does not have a problem with the rapid_commit option i= t 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 to = have, is one of the ones that has a DHCP server that just times out if you ha= ve the rapid_commit option in the dhcpcd config file.=20 >>=20 >> So I updated my production IPFire to Core-Update 190 Development Build: ma= ster/1e2abd66=20 >>=20 >> After rebooting the connection was lost as the rapid_commit option is on b= y default.=20 >>=20 >> I then ran the setup program and unchecked the rapid commit box on the red= 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 have = removed or commented out the rapid_commit option in dhcpcd.conf will lose the= ir connection.=20 >>=20 >> So either=20 >>=20 >> * we need to have the update check if the rapid_commit option has been co= mmented 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 d= isabled the rapid_commit option needs to run the setup program after the upgr= ade (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 > Can you not try to automate the upgrade so that it initially tries DHCP wit= h 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 rapid= _commit then fail? It could also be done for new installations choosing DHCP = and for installations switching from Static/PPPoE to DHCP. This would be a great method - if we have to accept that ISPs are now running= this completely broken DHCP services. However, the code does not easily allow this. We should not generally disable= the setting if someone failed to plug a cable in and looking at how few peop= le actually run into this problem at this time, we might not need to over eng= ineer this. --===============7616748093696509248==--