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.
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.
Hello,
On 29 Nov 2024, at 11:50, Nick Howitt nick@howitts.co.uk wrote:
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.
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 people actually run into this problem at this time, we might not need to over engineer this.
On 29/11/2024 14:11, Michael Tremer wrote:
Hello,
On 29 Nov 2024, at 11:50, Nick Howittnick@howitts.co.uk wrote:
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.
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 people actually run into this problem at this time, we might not need to over engineer this.
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).
And yes, it could be over-engineering.
I would also like to explore whether this isn’t best implemented in dhcpcd 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 nick@howitts.co.uk wrote:
On 29/11/2024 14:11, Michael Tremer wrote:
Hello,
On 29 Nov 2024, at 11:50, Nick Howitt nick@howitts.co.uk wrote:
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.
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 people actually run into this problem at this time, we might not need to over engineer this.
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).
And yes, it could be over-engineering.
Hello,
Thanks for testing this in production. Good to know this all works.
On 29 Nov 2024, at 11:21, Adolf Belka adolf.belka@ipfire.org 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.
If we wanted to be really fancy we could check if someone has modified the configuration file and if so we can automatically set the setting in /var/ipfire/ethernet/settings. I am not sure how reliable this would be, but it is an option.
We can discuss this at our next conf call meeting on 3rd or 4th Dec.
We need to bring more things back to the list because there are currently only so few people joining the call. I would also prefer to sort things out sooner on the list if possible and keep the call as free as possible for more general discussion.
-Michael
Regards,
Adolf.
Hi Michael,
On 29/11/2024 15:10, Michael Tremer wrote:
Hello,
Thanks for testing this in production. Good to know this all works.
On 29 Nov 2024, at 11:21, Adolf Belka adolf.belka@ipfire.org 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.
If we wanted to be really fancy we could check if someone has modified the configuration file and if so we can automatically set the setting in /var/ipfire/ethernet/settings. I am not sure how reliable this would be, but it is an option.
I could have a look at putting something together for this and test it out on my vm system and then submit a patch for it, if that is fine with you.
Regards, Adolf.
We can discuss this at our next conf call meeting on 3rd or 4th Dec.
We need to bring more things back to the list because there are currently only so few people joining the call. I would also prefer to sort things out sooner on the list if possible and keep the call as free as possible for more general discussion.
-Michael
Regards,
Adolf.
On 29 Nov 2024, at 19:04, Adolf Belka adolf.belka@ipfire.org wrote:
Hi Michael,
On 29/11/2024 15:10, Michael Tremer wrote:
Hello, Thanks for testing this in production. Good to know this all works.
On 29 Nov 2024, at 11:21, Adolf Belka adolf.belka@ipfire.org 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.
If we wanted to be really fancy we could check if someone has modified the configuration file and if so we can automatically set the setting in /var/ipfire/ethernet/settings. I am not sure how reliable this would be, but it is an option.
I could have a look at putting something together for this and test it out on my vm system and then submit a patch for it, if that is fine with you.
I would like to keep the solution that we have right now and see what happens once it is out there… I wouldn’t want to over-engineer this all just yet.
Regards, Adolf.
We can discuss this at our next conf call meeting on 3rd or 4th Dec.
We need to bring more things back to the list because there are currently only so few people joining the call. I would also prefer to sort things out sooner on the list if possible and keep the call as free as possible for more general discussion. -Michael
Regards,
Adolf.
-- Sent from my laptop
On 03/12/2024 18:41, Michael Tremer wrote:
On 29 Nov 2024, at 19:04, Adolf Belka adolf.belka@ipfire.org wrote:
Hi Michael,
On 29/11/2024 15:10, Michael Tremer wrote:
Hello, Thanks for testing this in production. Good to know this all works.
On 29 Nov 2024, at 11:21, Adolf Belka adolf.belka@ipfire.org 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.
If we wanted to be really fancy we could check if someone has modified the configuration file and if so we can automatically set the setting in /var/ipfire/ethernet/settings. I am not sure how reliable this would be, but it is an option.
I could have a look at putting something together for this and test it out on my vm system and then submit a patch for it, if that is fine with you.
I would like to keep the solution that we have right now and see what happens once it is out there… I wouldn’t want to over-engineer this all just yet.
I am fine with that.
Regards, Adolf.
Regards, Adolf.
We can discuss this at our next conf call meeting on 3rd or 4th Dec.
We need to bring more things back to the list because there are currently only so few people joining the call. I would also prefer to sort things out sooner on the list if possible and keep the call as free as possible for more general discussion. -Michael
Regards,
Adolf.
-- Sent from my laptop
-
Adolf Belka -
Michael Tremer -
Nick Howitt