DietPi doesn't reconnect after router reboot

Troubleshooting
22

I don’t think DHCP Watchdog is a good idea
It looks like there is a broken NetworkManager.service or some other service that is occupying the eth0 stack during boot, because it is not available dchcliet can’t properly access the interface, and only after some time.

first determine who exactly in the system is the DHCP client
ps aux | grep -Ei 'dhcp|udhcpc|dhclient|networkd|connman|NetworkManager'

then - systemctl --type=service | grep -Ei 'dhcp|network|connman|manager'

And separately:

I would start by investigating the services:

systemctl status systemd-networkd --no-pager
systemctl status NetworkManager --no-pager
systemctl status networking --no-pager

or what is dhcpclient you have.

I will show you further using an example from systemd-networkd

Immediately after reboot (having previously disabled all watchdogs and other “crutches”)

Send me screenshots (just don’t forget to blur your public IPs and other things, because it is not known who is reading here)

networkctl status eth0
journalctl -u systemd-networkd -b --no-pager
journalctl -u systemd-networkd -b --no-pager | grep -Ei 'dhcp|eth0|lease|carrier|link'

Then restart the dhcp client, and when the eth0 link is UP and send exactly the same commands and let me compare.

23

I had such problems when several services were simultaneously assigned to my DCHP client XD

Therefore, you need to determine what exactly is slowing down. Because it may be that in your system 2 or more services occupy the interface, this may come out sideways in the future, with or without a watchdog.

25

be careful with this. DietPi is using ifupdown and not NetworkManager

26

sometimes users use some AI help, that`s why network.manager came from with some double DHCP clients or else features
That is why I used it as an example.
But generally speaking, the user needs to investigate the problem rather than using the watchdog mechanism as a permanent, one-size-fits-all solution.