On 29/11/2024 11:21, Adolf Belka wrote:
Hi
Michael,
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.
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.
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 have the rapid_commit option in the dhcpcd config
file.
So I updated my production IPFire to Core-Update 190 Development
Build: master/1e2abd66
After rebooting the connection was lost as the rapid_commit option
is on by default.
I then ran the setup program and unchecked the rapid commit box on
the red interface and then rebooted and the connection was
running.
Another reboot still had the connection running.
So I can confirm that the patch is working .
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 their connection.
So either
* we need to have the update check if the rapid_commit option has
been commented out or has been removed and then disable the rapid
commit option for the red interface.
or
* 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 upgrade (maybe before the reboot) to disable the
option for the red interface.
We can discuss this at our next conf call meeting on 3rd or 4th
Dec.
Regards,
Adolf.
Can you not try to automate the upgrade so that it initially tries
DHCP with 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.