Bug 253166 - net/dhcpcd: no interfaces have a carrier (during boot)
Summary: net/dhcpcd: no interfaces have a carrier (during boot)
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-02-01 16:23 UTC by Dries Michiels
Modified: 2021-02-02 13:38 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dries Michiels 2021-02-01 16:23:02 UTC
Jan 31 20:06:31 vados kernel: Starting dhcpcd.
Jan 31 20:06:31 vados kernel: dhcpcd-9.4.0 starting
Jan 31 20:06:31 vados kernel: dhcp6_openudp: Can't assign requested address
Jan 31 20:06:31 vados kernel: ps_inet_startcb: dhcp6_open: Can't assign requested address
Jan 31 20:06:31 vados kernel: DUID 00:04:00:00:00:00:00:00:00:00:00:00:4c:cc:6a:28:3e:a3
Jan 31 20:06:31 vados kernel: no interfaces have a carrier
Jan 31 20:06:31 vados kernel: forked to background, child pid 15254
Jan 31 20:06:31 vados kernel: Additional TCP/IP options: IPv6 CPE WANIF=em0.
Jan 31 20:06:31 vados kernel: Setting up harvesting: PURE_RDRAND,[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED
Comment 1 Dries Michiels 2021-02-01 16:23:48 UTC
Pretty weird, as dhclient starts right after dhcpcd and that doesn't seem to fail.
Comment 2 Dries Michiels 2021-02-01 16:25:03 UTC
To fix this, I just have to manually restart dhcpcd after the system has booted up. Its annoying though as I sometimes forget and my network doesn't have IPv6 in the mean time :-)
Comment 3 Dries Michiels 2021-02-01 16:26:35 UTC
I'm running 14 CURRENT. Here the rcorder.

[/home/dries]$ rcorder /etc/rc.d/* /usr/local/etc/rc.d/*
rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision `kerberos'
rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision `named'
/etc/rc.d/natd
/etc/rc.d/rctl
/usr/local/etc/rc.d/dhcpcd
/etc/rc.d/dhclient
Comment 4 roy 2021-02-01 20:45:45 UTC
(In reply to Dries Michiels from comment #0)
Jan 31 20:06:31 vados kernel: dhcp6_openudp: Can't assign requested address

So you have something else hogging the DHCPv6 port wildcard address.

(In reply to Dries Michiels from comment #2)
> To fix this, I just have to manually restart dhcpcd after the system has booted

Sounds like during boot the routing socket overflowed and dhcpcd missed the carrier coming up event.
FreeBSD currently does not report route overflow so dhcpcd as you can see needs a manual restart.

See https://reviews.freebsd.org/D26652 for a kernel patch to fix this which has sadly stalled in review.
Comment 5 Dries Michiels 2021-02-02 13:15:17 UTC
Why is this now a problem? On some older versions of FreeBSD / dhcpcd I did not have this issue. (not sure if its FreeBSD that changed something, or dhcpcd :))
Comment 6 roy 2021-02-02 13:38:55 UTC
The route socket overflow has always been a problem, just fairly invisible unless you actually know what you're looking for.

The carrier issue has changed fairly recently since dhcpcd-9.3

In a nutshell, carrier is now *only* determined by ifnet->if_data->ifi_link_state.
It used to use media valid state, but this is problematic for some interface types who have a separation between valid media vs carrier.

One good example of this is wireless monitor mode.
The interface media is valid, but there is no carrier.

In FreeBSD<13 the only way of accessing ifi_link_state is via routing messages (which can be lost) or getifaddrs(2) which is an expensive libc call. FreeBSD-13 has added SIOCGIFDATA which is much more light weight.
https://reviews.freebsd.org/D26538

I *could* poll this ioctl every second at the expense of CPU to detect carrier state changes or FreeBSD *could* actually commit something to detect overflow.
Currently it's the only major BSD that doesn't report this for the routing socket.
dhcpcd used to poll for carrier up only (via media state), but I got complaints that it used too much CPU or was too slow or just didn't work reliably so I removed it. I'm in a no-win situation right now :(