I am not quite sure I follow your explanation of things in the answer you've provided. Your answer indicates you have resolved your problem for now, but your closing sentence suggests you are not quite sure what happened or why. I will try to address that here.
As a point of clarification for readers who may be unfamiliar, please note the following:
DHCP is the dynamic host configuration protocol. This protocol was designed to simplify IP address provisioning in networks by avoiding the error-prone task of manual provisioning.
dhcpcd stands for DHCP client daemon. Its job is to obtain - from a DHCP server - all the required information needed by the RPi to conduct network operations: an IP address, a default route, and a link to DNS services - as a minimum.
dhcpcd is currently the default networking software for RPi. It was chosen as the default DHCP client app for RPi OS by the powers that be in the Raspberry Pi organization, but you of course are free to change that.
dhcpd stands for DHCP daemon. It is the server-side app for DHCP. Unless you're using your RPi as a DHCP server itself, you will not need to install it. Being a DHCP server is ordinarily a full-time job. Networks may become uncooperative when their DHCP server goes on sabbatical!
"Routing" and "routers" refer the process and systems used to move network traffic between their sources and their destinations. It's often the case in smaller networks that routers and DHCP servers cohabit a single box or appliance. Accordingly references to routers sometimes include the DHCP server function as well. The only point here is that routing and DHCP are separate and distinct network functions, but they may be housed together.
I do not claim any particular expertise in DHCP. But I have at least read the system documentation for
man dhcpcd.conf &
man dhcpcd), and the Internet Standard for DHCP - RFC 2131. I had occasion to review the protocol some time ago in relation to this old Q&A - which may be relevant to your experience?
FWIW - My take on your experience:
- The router assigns a static IP address to the pi's mac address.
I am not sure why you say this because the router/DHCP server does not assign static IP addresses! Perhaps you meant that you - as the router/DHCP administrator - made a "static mapping" assignment manually through your router/DHCP server's configuration interface? I'll emphasize this point as it seems to confuse many: Creating a static IP for your RPi in
dhcpcd.conf does not induce your router or your DHCP server to do anything at all.
In fact, the static IP configuration in
dhcpcd.conf will prevent your RPi's
dhcpcd from communicating with the DHCP server.
dhcpcd is a client of the DHCP server; it sees a static ip declaration in
dhcpcd.conf as the system administrator (you in this case) saying, "I don't need you to act as a client; I'm providing the DHCP server's information for you here." Put another way,
dhcpcd will never communicate the static ip configuration you've made in
dhcpcd.conf to your router/DHCP server.
But there is a line in
man dhcpcd.conf that's very relevant to both DHCP client and server wrt a static IP:
For IPv4, you should use the inform ipaddress option instead of setting a static address.
The syntax for the
inform option is given by example below for the
wlan0 interface in IPv4:
inform 192.168.1.51/24 # '/24' is the CIDR unless you've created a subnet
What does that
inform option mean?
I'll call your attention to para 3.4 of RFC 2131. This passage explains the recommendation above for using the inform option: The inform option in
dhcpcd.conf provides the mechanism needed to let your router/DHCP server know that you have assigned a static IP address to your RPi. Hopefully it is clear that the router/DHCP server needs this information.
inform option "informs" the DHCP server to bind the client's MAC addr to the designated IP address, and prompts the server to complete the provisioning process by supplying the default route, DNS hosts and any other data the DHCP server ordinarily sends to clients (e.g. NTP server address for time services). Note however this passage from para 3.4:
The server SHOULD check the network address in a DHCPINFORM message for consistency, but MUST NOT check for an existing lease.
This passage emphasizes that it is the administrator's responsibility to avoid address collisions for static IP assignments. Put another way, the
inform option does not give the administrator carte blanche authority to assign addresses willy-nilly without consequence.
Hopefully, it is now clear that the correct approach to static ip usage includes configuration of the DHCP server so that it will never assign an IP address designated in the
inform option. How this is done will depend on the characteristics of the DHCP server in use. The exception to this of course is if your entire network is static addresses; in this case you have no need for a DHCP server (or
dhcpcd for that matter).
In summary, there are two points:
If you have a DHCP server on your network, placing a
static ip configuration in
dhcpcd.conf is unnecessary at best, and a source of chaos in your network at worst. This due to the fact that a
static ip configuration in
dhcpcd is never communicated to the DHCP server. Once again, this is why the author of
dhcpcd included the admonition against it in his documentation, and his recommendation to use the
I don't use docker services, and I'm not familiar with how they obtain their networking information. However, quickly skimming this article from the docker docs suggests that your docker services may be completely dependent on your RPi's network configuration! If that's the case, broken networking on your RPi implies broken networking in your docker apps.
I hope that understanding how DHCP clients & servers interact (or don't interact), provides you with some useful clues for your analysis. I also hope this "answer" will dissuade you (and others) from using the
static ip configuration shown in your answer, and to use the
request) option instead.