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.
Many thanks!
Michael
For further Investigation, here are my logs from yesterday.
I’m new to IPFire and don’t know the system but I’m quite familiar with Linux…
If the “at” command line utility is available in IPFire, you should be able to run a delayed command at startup by adding a line to /etc/sysconfig/rc.local like: dhclient | at now +5 minutes
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.
My cable modem needs 10min to boot and sync with the cable net. Until this has finished the internal dhcp server of the modem leases a non working 192.168.100.x IP.
So i have to start the modem 10min before the IPFire or run “connscheduler reconnect” to ontain a valid IP from the ISP after the modem has synced.
Increase the timeout will not help because the modem always generate a dhcp answer within the timeout but a useless one.
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.
This is a bad idea if the IPFire is connected to a router. In this case you get a private IP. Also some ISP’s does not lease public ip’s. (Mobile networks, Dualstack Lite)
Also such function is not implemented in dhcpcd which is the used dhcp client.
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:
13:20:47
dhcpcd[1868]
: timed out
13:20:42
dhcpcd[1868]
: red0: probing address 192.168.100.20/24
13:20:42
dhcpcd[1868]
: 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 …
So what?
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.
It would be better to check the connection and reload when connection changes as @guebert suggested. But meanwhile (and because the at command is not aveilable in IPFire) this:
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…
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…