public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Adolf Belka <adolf.belka@ipfire.org>
To: development@lists.ipfire.org
Subject: Testing of rapid_commit patch
Date: Fri, 29 Nov 2024 12:21:11 +0100	[thread overview]
Message-ID: <b894d226-9e9e-4027-bfc3-f6a9f7ee469c@ipfire.org> (raw)

[-- Attachment #1: Type: text/plain, Size: 1629 bytes --]

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.


             reply	other threads:[~2024-11-29 11:21 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-29 11:21 Adolf Belka [this message]
2024-11-29 14:10 ` Michael Tremer
2024-11-29 19:04   ` Adolf Belka
2024-12-03 17:41     ` Michael Tremer
2024-12-03 18:41       ` Adolf Belka
     [not found] <92cb066c-6678-49ca-bbd2-44e4c75c672d@howitts.co.uk>
2024-11-29 14:11 ` Michael Tremer
     [not found] <5f671b37-de3f-4057-839a-7a85f91ededc@howitts.co.uk>
2024-11-29 16:20 ` Michael Tremer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b894d226-9e9e-4027-bfc3-f6a9f7ee469c@ipfire.org \
    --to=adolf.belka@ipfire.org \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox