Actually, I believe the dhcpcd service is the wrong one here: Looking at the dhcpcd.service's Unit section (in F39 at least) I see:
[Unit] Description=A minimalistic network configuration daemon with DHCPv4, rdisc and DHCPv6 support Wants=network.target Before=network.target So it orders itself *before* network.target but only this is not enough. It must also order itself After=network-pre.target >From the docs: network-pre.target This passive target unit may be pulled in by services that want to run before any network is set up, for example for the purpose of setting up a firewall. All network management software orders itself after this target, but does not pull it in. And dhcpcd is a network management software On Thu, Sep 28, 2023 at 4:46 PM Mantas Mikulėnas <graw...@gmail.com> wrote: > > On Wed, Sep 27, 2023 at 12:31 PM Mark Rogers <m...@more-solutions.co.uk> > wrote: >> >> On Wed, 27 Sept 2023 at 10:18, Mantas Mikulėnas <graw...@gmail.com> wrote: >>> >>> So now I'm curious: if the first command you run is to bring the interface >>> *down*, then what exactly brought it up? >> >> >> Good question. The reason for down/up was that this was working as a way to >> reset the connection after boot, so I just transferred that to the >> ExecStartPre. >> >> Looking at the "journalctl -u dhcpcd" output, this is what I see from my >> last boot: >> Feb 14 10:12:05 pi systemd[1]: Starting dhcpcd on all interfaces... >> Feb 14 10:12:05 pi ip[372]: 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc >> noop state DOWN group default qlen 1000 >> Feb 14 10:12:05 pi ip[372]: link/ether b8:27:eb:0d:ee:bb brd >> ff:ff:ff:ff:ff:ff >> Feb 14 10:12:05 pi ip[383]: 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu >> 1500 qdisc pfifo_fast state DOWN group default qlen 1000 >> Feb 14 10:12:05 pi ip[383]: link/ether b8:27:eb:0d:ee:bb brd >> ff:ff:ff:ff:ff:ff >> Feb 14 10:12:06 pi dhcpcd[385]: wlan0: starting wpa_supplicant >> Feb 14 10:12:36 pi dhcpcd[385]: timed out >> Feb 14 10:12:36 pi systemd[1]: Started dhcpcd on all interfaces. >> Feb 14 10:12:37 pi systemd[1]: Stopping dhcpcd on all interfaces... >> Feb 14 10:12:37 pi dhcpcd[519]: sending signal TERM to pid 466 >> Feb 14 10:12:37 pi dhcpcd[519]: waiting for pid 466 to exit >> Feb 14 10:12:38 pi systemd[1]: dhcpcd.service: Succeeded. >> Feb 14 10:12:38 pi systemd[1]: Stopped dhcpcd on all interfaces. >> Feb 14 10:12:38 pi systemd[1]: Starting dhcpcd on all interfaces... >> Feb 14 10:12:38 pi ip[524]: 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu >> 1500 qdisc pfifo_fast state DOWN group default qlen 1000 >> Feb 14 10:12:38 pi ip[524]: link/ether b8:27:eb:0d:ee:bb brd >> ff:ff:ff:ff:ff:ff >> Feb 14 10:12:38 pi ip[529]: 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu >> 1500 qdisc pfifo_fast state UP group default qlen 1000 >> Feb 14 10:12:38 pi ip[529]: link/ether b8:27:eb:0d:ee:bb brd >> ff:ff:ff:ff:ff:ff >> Feb 14 10:12:38 pi dhcpcd[530]: wlan0: starting wpa_supplicant >> Feb 14 10:12:49 pi dhcpcd[530]: Too few arguments. >> Feb 14 10:12:49 pi dhcpcd[530]: Too few arguments. >> Feb 14 10:12:49 pi systemd[1]: Started dhcpcd on all interfaces. >> >> (I deleted the "ip addr" output from the interfaces other than eth0 for >> brevity.) >> >> The interesting thing is surely that dhcpcd is being started twice. Assuming >> that was always happening then that suggests dhcpcd was bringing the network >> up early (and failing but leaving it in a "stuck" state) and then again >> later (where it was unable to recover from the first failure, but now can)? > > > That's possible... but again, I don't see how it would get into this "stuck" > state in any other way but driver and/or hardware issues, as the kernel > driver is where the power-up sequence is done... dhcpcd (like 'ip link set > eth0 up') pretty much just tells the OS to power the NIC on, then waits. > > (My previous laptop had a Realtek Ethernet NIC that often wouldn't recognize > Ethernet link after suspend/resume until I removed it from the PCI bus... > took several kernel releases until they fixed that.) > > -- > Mantas Mikulėnas
