ipFire behind LIWEST cable modem in bridging mode - getting no RED ip


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.

DHCP client on red0 won’t reassign IP upon reconnection - Networking - IPFire Community

Red0 unable to re-establish connections, long-term dhcpcd problem - Networking - IPFire Community

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!


For further Investigation, here are my logs from yesterday.

power on of ipfire and cable modem at 13:19:

13:20:47 dhcpcd[1868] : dhcpcd exited
13:20:47 dhcpcd[1868] : main: control_stop: No such file or directory
13:20:47 dhcpcd[1868] : timed out
13:20:42 dhcpcd[1868] : red0: probing address
13:20:42 dhcpcd[1868] : red0: offered from
13:20:14 dhcpcd[1868] : red0: soliciting a DHCP lease
13:20:14 dhcpcd[1868] : red0: IAID b9:5a:bf:80
13:20:14 dhcpcd[1868] : red0: carrier acquired
13:20:11 dhcpcd[1868] : red0: carrier lost
13:19:51 dhcpcd[1868] : red0: soliciting a DHCP lease
13:19:50 dhcpcd[1868] : red0: IAID b9:5a:bf:80
13:19:49 dhcpcd[1868] : red0: carrier acquired
13:19:47 dhcpcd[1868] : red0: waiting for carrier
13:19:47 dhcpcd[1868] : DUID 00:01:00:01:2a:42:67:45:00:0d:b9:5a:bf:80
13:19:47 dhcpcd[1865] : dhcpcd-10.0.1 starting

manual reboot of ipfire only at 13:51:

13:51:53 dhcpcd[1870] : red0: adding default route via
13:51:53 dhcpcd[1870] : red0: adding route to
13:51:53 dhcpcd[1870] : red0: leased for 604800 seconds
13:51:48 dhcpcd[1870] : red0: probing address
13:51:48 dhcpcd[1870] : red0: offered from
13:51:45 dhcpcd[1870] : red0: soliciting a DHCP lease
13:51:43 dhcpcd[1870] : red0: IAID b9:5a:bf:80
13:51:43 dhcpcd[1870] : red0: carrier acquired
13:51:40 dhcpcd[1870] : red0: waiting for carrier
13:51:40 dhcpcd[1870] : DUID 00:01:00:01:2a:42:67:45:00:0d:b9:5a:bf:80
13:51:40 dhcpcd[1867] : dhcpcd-10.0.1 starting

Hello, i use the console and make a

/etc/init.d/network restart

works also

1 Like

Hi @guebert ,

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

No, the at command is not available in IPFire.

The IPFire default delay time is set to 60 seconds.

You can adjust that to a larger time based on how long your modem takes to fully turn on and stabilise.

The file is

and the line is
timeout 60

Just change this to 120 seconds or whatever is appropriate for your modem.

The dhcpcd.conf file is included in the IPFire backup file and therefore any change you make there will be maintained over Core Updates.


@bonnietwin: Thanks, I’ll try.

@Development team: How about adding a GUI for this parameter, as serveral users are affected?


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.


I am affected too, i will change the timeout in dhcpcd.conf, if it is already so simple.

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.

1 Like

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.

So a feature of recurring tries on RED (after reboot only?), till it get’s a non-private-ip would be useful.

Maybe a watchdog with a ping to an external adress (ipfire.org …) will be a nice to have.

(BTW: Reboot … power on the device and… take a coffee is not a solution for unplanned an unattended reboot events.)


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
13:20:42 dhcpcd[1868] : red0: offered from

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 …

I wonder if something like this might work with fcrontab:

@reboot sleep [time in seconds] && [path to job]


@reboot sleep 300 && /etc/init.d/network restart

NOTE: the above has not been tested!

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:

(( sleep 600 ; /etc/init.d/networking restart ) & )

in /etc/sysconfig/rc.local could be a workaround.

(Hint: brackets and ampersand are for double-forking to disconnect from the shell)

1 Like

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).

Hi @cfusco

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 :wink:

…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 :wink: 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 :man_shrugging: 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…

I have not mentioned PPPoE. Some ISP’s use Dual-Stack lite or Carrier Grade Nat.

In this case you get a private IP address from your ISP. This may also assigned via DHCP.


Try “connscheduler reconnect” instead of networking restart to restart only red.

1 Like