Dhcpcd configuration

Last night there was a problem with my DOCSIS internet connection.
dhcpcd tried a renew in this time and remained in a endless wait loop.
A red restart solved the problem.

Searching for the config I found /var/iipfire/dhcpcd.conf only, no /etc/dhcpcd.conf.
Is this correct, or got the link from /etc to /var/ipfire lost?

EDIT: A deeper investigation shows, the config file should be /var/ipfire/dhcpc/dhcpcd.conf ( compiled in ). This file sets the timeout to 60 seconds.
Is there problem known? After the timeout dhcpcd should retry, this didn’t happen.

It has always only been in /var/ipfire/dhcpc/dhcpcd.conf and as far as I can see never in /etc/

I went back to CU80 and there was no /etc/dhcpcd.conf in the rootfiles.

See my edit. We posted in parallell. :wink:

You edited while I was posting :grin:

dhcpcd looks to make a connection and eventually times out after 60 seconds.

I think this has happened before with cable modem systems as they can take a very long time to complete their setup when re-booted. So it has been recommended before to start your cable modem first and then when its green lights show that it has completed and has a stable connection, then start your IPFire.

There is no automatic re-try. This has been mentioned before in this forum.

It has often been said that getting it to automatically retry is very easy but no one has ever supplied a patch to do it.

With a 60 second timeout when it fails the rest of the start up initscripts complete and you end up with a system that you can debug.

If you just put it into a loop to try again and again etc then it would never stop and the InitV startup sequence would not get past the dhcpcd step and you would not get a console prompt from which you could log in and do any debug.

I think it is not as simple as people think and I suspect most of them when they went to try it found that out.

I believe there is a bug report for this is or something similar and it is still open.

Adolf, thank you for your quick response.

I know, there is a discussion since a long time.
I’ll try with some monitoring in the crontab. I had such a thing before, but it was deleted some time. I thought it wasn’t necessary.

The investigation of the issue is someway more complicated.

  • The FB ‘modem’ isn’t accessible easily. The repeater mode is associated to a separate LAN port, which doesn’t allow admin page access. This is only possible via AVM’s WAN access. :roll_eyes: .
  • Because the problem doesn’t occur very often, it is not easy to determine an approbiate condition.
  • The problem on the ISP connection is not known and can therefore not easily be produced and tested.

The main problem in everydays life is: the issue mostly occurs some time in the night and the admin (me) isn’t the first family member using internet access in the morning.

Isn’t that always the case. Those very occasional things are always the things that tend to hurt the most. Good luck.

Hi Adolf,
A clarification, if you can provide it: if a software (!) disconnect and reconnect (down-up in interface) will trigger a new dhcpd cycle past the moment where those initial 60 seconds passed?
Why I ask - in theory, a port-down followed by port-up might be a solution for this case. With a detection that red has no IP address, which should initiate the port down / port up sequence.
I usually disconnected the cable physically and never tried the software down-up sequence when I had my test IPFire machine getting red IP address via dhcpd from primary IPFire.

Bernhard, this is another great example why forum beats documentation.

I don’t know. I am not familiar enough with all the involved code there.

I think, it isn’t a problem of port down / port up or power switching.

The FB just lost connection to the ISP, no idea whether it was a complete cable down or only server problems at the ISP. At the time of the event ( 03:00 ) I was sleeping and no one other in the family was watching TV or surfing in the internet.

At about 10:00 I noticed a lack of internet connection. The interface was up, sometimes the FB ( my ISP provided ‘modem’ ) sent broadcasts to the 224.xx.xxx.xx address.
IPFire’s log showed a DHCP renewal, which did not end. For the same time I found connection losses in the modem logs.
dhcpcd did not retry the IP ackknowledge of the expired lease. After a restart of red the allocation of an IP was possible immediately.
Whether just a renew of lease via dhcpcd would have been successful also, can not be answered. My trial was with incomplete parameters, sorry.

:thinking:
Have you enabled the ‘Rapid commit’ option in the RED interface settings?

edit

Regards

Rapid commit is not enabled.

Furthermore, it is not a problem of different boot times of modem and IPFire. A few days before I had a power outage. After restoring the power line, both devices started at the nearly same time. Internet connection just came up as expected.