I found serveral threads regarding the problem, that on “parallel” reboot of ipfire and the cable modem, ipfire’s dhcpd might be too fast and asking the cable modem for an IP, even the modem is not ready.
But I did not find any solution. I always have to make a manual reboot of ipfire, after the cable modem is online.
Can anybody help me? I think this problem could be easily solved in having the dhcpd on ipfire delayed for some minutes (betten than waiting forever) or have dhcpd in any case force to “retry” eg 5 min after reboot.
For further Investigation, here are my logs from yesterday.
The original default timeout on dhcpcd was 30 seconds. The links provided that had a similar problem were from the time when the default was 30 seconds.
In July 2021 the default timeout for IPFire was increased to 60 seconds, the current value.
Your post is the first I am aware of, about this timeout problem when turning on the modem and IPFire at the same time, since that timeout increase was made. I suspect that you must have a modem that takes a very long time to boot up and capture the cable signal.
CPE got richer in features. Bigger firmwares (increased load time, not so much compensated by faster flash memory), longer boot times (more features and more rules), maybe with fiber less negotiation time (ATM, ADSL and VDSL can took up to 3 minutes for a cold boot), then the usual TR-069 back and forth, to make assured you’re not being a crook over another connection.
I suggest to people to power on the device and… take a coffee. Or a tea. Whatever.
At this issue, mostly there are 2 cases.
Case1: IPFire has private IP on the RED, CPE acts like a router, so timeout must consider only a full boot-up to have connection working. Which is not internet working, but whatever… when internet connection will work, IPfire will work.
Case 2: IPFire need to establish a PPPoE connection. So the whole gear must turn, from the boot of the CPE, to the obtaning of the dhcp lease, to try and apply the PPPoE connection with success. Any step failing is a issue for IPFire.
FWIW, i’d love (maybe under an “advanced” or “troubleshooting” specific menu have access to the timeout setting.
Without having to remember to edit the config file
Without remembering to fireup an SSH client to check it.
I see. So maybe there should be an option for this (private IP ok/not ok) AND/OR have ipfire test, if it can connect to the internet (eg DNS-request / ping positive, etc). ipfire should be able to detect, that’s offline and try to resolve this issue.
In my case ipfire also gets an private IP a few seconds before time-out as you can see in my logs:
: timed out
: red0: probing address 192.168.100.20/24
: red0: offered 192.168.100.20 from 192.168.100.1
So I wonder, if a longer timeout setting will solve my problem …?
Is there any parameter for DELAY of bringing RED up? Or at least of starting the boot-procedure? A simple “WAIT 120” in the script could help to have ipfire wait till the modem is online …
Most of Italian ISPs deliver a router, which could or could not have the option for allow PPPoE public address, rather than some sort of NAT managed from the ISP.
I’m sorry if that’s not the intended goal for IpFire, but most people cannot bash on the table to make the ISP do what company (person, CEO, whatever) want.
ISP provides what they want, and people must cope with that. Even people with IPFire. Then… .NAT.
Question, is my interpretation of the chain of events correct?
At the end of the boot process, rc.local will be executed as the last script to run. Then, the inner parentheses will create a sub-shell, where there will be an instruction to wait for 10 min and then a restart of the network interfaces. The ampersand & puts this subshell in the background and forks again, further distancing from the initial process. This “double-forking” ensures that the process will continue to run even when the terminal or shell that launched it is closed because the process, if orphaned, will be adopted by PID 1 (init process).
I’m far, far away of being an expert of IPFire. I installed IPFire about 3 hours ago for the first time (in some virtual machine) to take a closer look at it. Nor I’m an expert of the Linux OS - I have just gained some experience with it while using it for… a longer period of time
…as far as I know:
yes - normal boot (to a command line interface) enters runlevel 3. All scripts in /etc/rc.d/rc3.d will be processed in alphabetical order and the last entry in this directory “S98rc.local” is a link to this rc.local script
…and yes - this was the idea behind but it does not work the way it was supposed to It still works but if the parent process gets a kill signal, the child process completes the sleep command but gets killed right after the sleep finishes and the rest is skipped But since there is no watchdog mechanism to kill the parent process it still works. The rc.d scripts are called with the sh interpreter and not with bash - maybe that’s the problem…