2

I have a Pi (with Raspberry Pi OS) connected to the router via ethernet, and whenever it loses connection, dhcpcd doesn't automatically try to reconnect. Now, that is especially a problem since I'm running it headless and at the moment I don't even have a cable to connect it to a monitor. Then, the only possibility I have when the Pi loses connection is forced shutdown, since I can't SSH in.

It seems that the only instance where dhcpcd tries to connect is startup. If it doesn't manage then, it never tries it again anymore. For example, if the router and the Pi both get power at the same time, the Pi's startup is obviously faster, and the Pi is not able to establish connection, since the router is down during its startup.

How can I configure dhcpcd so that it automatically tries to establish connection when it's not up?

Improve this question
4
  • Unless you have done something unusual it should work (as it does for the rest of us). It is actually unlikely to be loss of connectivity - you have provided no evidence to support this. PS I don't understand the concept of turning a router off!
    – Milliways
    Commented Aug 21, 2020 at 10:39
  • I didn't turn the router off, I had a blackout, and the scenario I described happened. Router obviously wasn't functional for a couple minutes, and when it finally went online, I noticed the Pi wasn't connected, It wasn't between the connected devices in the router's control panel, it wasn't found by an nmap scan. Noticing this, I decided to test this behaviour and I could reproduce it no problem: unless the router is already up at the time of boot and the Pi is plugged, dhcpcd won't bother to try and reconnect at a later time for some reason. I didn't touch dhcpcd's default configuration.
    – NANI SORE
    Commented Aug 21, 2020 at 16:58
  • What do the router's logs show? Is your RPi showing up in a table of DHCP leases? Is it an active lease? It seems you have made an assumption that it is an issue with dhcpcd, but most typically, dhcpcd "just works". We need more information to help you with this.
    – Seamus
    Commented Aug 23, 2020 at 17:13
  • It doesn't even get to try and obtain an IP. It goes against a brick wall and says main: control open: Connection refused. I honestly don't know what the problem might be. Now it doesn't even work after reboots anymore, I'm completely offline. The only thing I did was trying and setup static IP, then quickly reverting the config at the original values.
    – NANI SORE
    Commented Aug 27, 2020 at 20:25

1 Answer 1

Reset to default
1

There is an abundance of documentation on dhcpcd. It's available online for the cost of an Internet search, and available on your system in man dhcpcd. It appears you've not done much research.

We can certainly understand that being unable to access your RPi will limit your troubleshooting options, but there are several methods available if your network is down. If you have occasional outages, you should look into these alternatives. Perhaps the easiest is to obtain a cable to connect a monitor to your RPi.

Also please understand that there are literally innumerable possible causes for the situation you've described in your question. We have some extremely knowledgeable people here, but unfortunately no mind readers or diviners. In other words, if you can't articulate your problem, your prospects for getting a useful answer decrease, and the prospects for having your question closed increase.

All of that said, here's a couple of thoughts that may help:

  1. dhcpcd works well in most situations for most people. Its wide distribution is a testament to the fact that it's very robust. When it fails, it's often due to changes in /etc/dhcpcd.conf made by a user. If you've not modified /etc/dhcpcd.conf, consider restoring it to its default. A manual intervention is possible, but this is a bit of a kludge, and you can't access your Pi anyway:

    sudo service dhcpcd restart

  2. The internet search referenced earlier contains this old thread where the problem you describe is discussed, and solutions are proposed. If I understand the discussion, the issue may be caused by how the OS starts dhcpcd. In RPi OS buster the file /etc/systemd/system/dhcpcd.service.d/wait.conf contains the startup code for dhcpcd. I believe the default is the following line: ExecStart=/usr/lib/dhcpcd5/dhcpcd -q -w. Perhaps someone more familiar with this can chime in? If not - try the solutions proposed, and let us know how that works.

Improve this answer
6
  • I have ordered a cable to use it on a screen, yes, so I will have more possibilities to investigate when I'll receive it. Thing is, if while troubleshooting I lose connection, I am forced to unplug the device, and I'm pretty sure the microSD won't be happy. And, sadly, for some reason journalctl seemed to discard logs when rebooting after a forced shutdown. Thing is, I've often used dhcpcd in the past it and worked for me without any modifications, so I'm as confused as you about this and I was asking "where do I start looking" more than "what's the problem and how do I solve it".
    – NANI SORE
    Commented Aug 21, 2020 at 22:16
  • But you're right, I should've waited until I had a bit more elements. I'll wait for the cable, that should help me a great deal.
    – NANI SORE
    Commented Aug 21, 2020 at 22:18
  • @NANISORE: I understand. I've done further reading. Pls verify your file /etc/systemd/system/dhcpcd.service.d/wait.conf contains the following line: ExecStart=/usr/lib/dhcpcd5/dhcpcd -q -w
    – Seamus
    Commented Aug 22, 2020 at 19:53
  • @NANISORE: Also conducted an experiment wherein I removed the Ethernet cable from my RPi before applying power/booting. I then waited approx 2 minutes, then plugged the Ethernet cable into eth0. I was able to connect immediately, then looked in /var/log/syslog for "signs". I found a string of messages beginning with this: dhcpcd[499]: eth0: carrier acquired, which was followed by messages confirming the DHCP lease was "activated". What do you see?
    – Seamus
    Commented Aug 22, 2020 at 20:55
  • So, I have the cable, and apparently it's not that it doesn't retry, it just can't do it! dhcpcd ouputs: main: control open: Connection refused, eth0: waiting for carrier and then, of course, it doesn't acquire the carrier and goes on until it times out. I'll do some further investigating.
    – NANI SORE
    Commented Aug 27, 2020 at 20:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.