Date: Tue, 02 Feb 2021 13:38:55 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 253166] net/dhcpcd: no interfaces have a carrier (during boot) Message-ID: <bug-253166-7788-TeaxvR6V9L@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-253166-7788@https.bugs.freebsd.org/bugzilla/> References: <bug-253166-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253166 --- Comment #6 from roy@marples.name --- 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 messa= ges (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 carr= ier state changes or FreeBSD *could* actually commit something to detect overfl= ow. 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 compla= ints 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 :( --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-253166-7788-TeaxvR6V9L>