4

I have a pi that is defined wi static IP in /etc/dhcpcd.conf:

interface eth0
inform 4.3.2.77
static routers=4.3.2.1

everything worked great until lately once a day I had to restart it because it was freeze. when I've tried to understand the cause I've found out a huge amount of those lines in /var/log/syslog :

Aug 12 21:47:36 raspberrypi dhcpcd[520]: veth44f813b: adding default route
Aug 12 21:47:36 raspberrypi dhcpcd[520]: eth0: deleting route to 4.0.0.0/8
Aug 12 21:47:36 raspberrypi dhcpcd[520]: eth0: deleting default route via 4.3.2.1
Aug 12 21:47:36 raspberrypi dhcpcd[520]: veth44f813b: pid 520 deleted default route
Aug 12 21:47:36 raspberrypi dhcpcd[520]: veth44f813b: adding default route
Aug 12 21:47:36 raspberrypi dhcpcd[520]: eth0: received approval for 4.3.2.77
Aug 12 21:47:36 raspberrypi dhcpcd[520]: eth0: adding route to 4.0.0.0/8
Aug 12 21:47:36 raspberrypi dhcpcd[520]: eth0: adding default route via 4.3.2.1
Aug 12 21:47:36 raspberrypi dhcpcd[520]: veth44f813b: deleting default route

the daemon log is filled with this stuff too - hundreds of MB of this...

when digging a bit more I understand what veth44f813b is, its an interface:

pi@raspberrypi:~ $ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         4.3.2.1         0.0.0.0         UG    202    0        0 eth0
4.0.0.0         0.0.0.0         255.0.0.0       U     202    0        0 eth0
link-local      0.0.0.0         255.255.0.0     U     210    0        0 veth44f813b
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0

that is related to OpenVPN docker image I have because when I stopped it the garbage in syslog was changed to:

Aug 12 21:54:51 raspberrypi dhcpcd[520]: eth0: received approval for 4.3.2.77
Aug 12 21:54:51 raspberrypi dhcpcd[520]: eth0: received approval for 4.3.2.77
Aug 12 21:54:52 raspberrypi dhcpcd[520]: eth0: received approval for 4.3.2.77
Aug 12 21:54:52 raspberrypi dhcpcd[520]: eth0: received approval for 4.3.2.77
Aug 12 21:54:52 raspberrypi dhcpcd[520]: eth0: received approval for 4.3.2.77
Aug 12 21:54:52 raspberrypi dhcpcd[520]: eth0: received approval for 4.3.2.77

My questions are: Does this huge log is related to the system freeze?

Is this a normal behavior?

How can I prevent dhcpcd from filling the log many times each second with this stuff?

yossico
  • 179
  • 7

3 Answers3

4

This logging mis-behavior was indeed due to a bug in the dhcpcd code.

I initially dismissed this question as irrelevant, and wrote it off as an issue unrelated to use of the inform option in dhcpcd.conf. Mea culpa; I eventually realized my initial assessment was completely wrong. My realization came only after the bug bit me! :(

As explained in this answer, the bug has been found and fixed, and perhaps will eventually reach distribution via apt. Until then, there are available instructions for patching dhcpcd yourself.

Ironically, my dismissal of the issue raised here in this question drove some to use the static <value> option - which I consider the ultimate in brain-dead network configuration. In attempting to curtail a brain-dead network configuration, I behaved brain-dead myself.

In closing, I offer my apologies for dismissing the question before looking into it further.

Seamus
  • 21,900
  • 3
  • 33
  • 70
3

Ok... After searching a bit more - I've found more info here: https://www.raspberrypi.org/forums/viewtopic.php?t=265516

The reason it was filled with those messages is related to the settings in /etc/dhcpcd.conf: the inform=xxx.xxx.xxx.xxx is causing this. so I've changed it to: static ip_address=xxx.xxx.xxx.xxx instead of inform and it's solving that. I've also added noipv6 because the log was filled with those messages too.

EDIT

although the above fixed solved my issue, a more proper solution is suggested here: https://raspberrypi.stackexchange.com/a/137147/122332 I couldn't test it because the setup that had the issue is no longer relevant.

yossico
  • 179
  • 7
  • 1
    I wish I could upvote your answer, but using the static <value> option in /etc/dhcpcd.conf is not the correct way to do this. Your initial use of the inform option was absolutely correct, but unfortunately a bug in dhcpcd caused log-arrhea :) That bug has now been found & a fix is available. I do hope you'll consider changing your answer so that others will not fall into the same trap you did. – Seamus Apr 19 '22 at 20:00
  • It was quite a long time ago, Can you put a good answer and I will refer to your answer? I don't have the relevant environment anymore so I can't test the fixed answer... – yossico Apr 19 '22 at 20:41
  • Yes, it's been a while! :) I did add an answer below. Oh, BTW, we're only notified of comments to someone else's posts when the @username is added to the comment. – Seamus Apr 19 '22 at 20:58
  • @Seamus Oops, forgot to add the @ part... – yossico Apr 19 '22 at 23:39
3

The "received approval for" log spam is due to a bug in dhcpcd. The use of "inform" in the dhcpcd.conf log triggers the bug and results in an infinite loop between dhcpcd and the DHCP server on your network.

Dhcpcd sends an INFORM message, your DHCP server replies with an ACK. Dhcpcd's processing of that ACK results in another INFORM, which results in another ACK, and so on. Side effect is your logs fill up with messages and your network gets spammed with a constant stream of INFORMS and ACKs. The bug has existed since at least Feb 2020 as demonstrated in the previously linked raspberry pi forum thread and is not yet, as of Sep 2021, fixed.

There does not seem to be a simpler solution than switching from the use of inform to static_ip in your dhcpcd.conf at this time.

https://github.com/NetworkConfiguration/dhcpcd/issues/47

EDIT: Users of current versions of Raspberry Pi OS who use the UI to set a static IP address for their network interfaces will find that dhcpcd will be using 1/4 to 1/2 of a core and that their network is being spammed with bogus packets. They will investigate and then end up searching online for the message "received approval for" and eventually they will end up here. One of the questions posited is how to stop these messages. The user solved it for themselves. My answer/reply simply expands on the underlying issue and confirms that the recommended solution is the current best solution.

Compared to "Your fundamental problem seems to be that you don't understand what the inform does." my response shows an understanding of the original user's question, helps new users who come across this question more fully understand what is going on, and fails to be condescending. Which is a good thing.

wang_li
  • 31
  • 2