On 2024/12/06 07:40, Zack Newman wrote: > > I am using 10.1.0 on 7.6-release with Comcast (Xfinity), and haven't > > encountered > > the reported problem. > > Lucky you then. I am the one that reported the problem because it > exists. https://github.com/NetworkConfiguration/dhcpcd/pull/376 explains > the issue, and a fix was pushed to master that works. master has a > separate issue that requires reverting > https://github.com/NetworkConfiguration/dhcpcd/commit/e3c5de14f01227f53b3fb87b76e1dd0e69722981 > > I have been running it for the past 3 weeks without issue. I also have > Xfinity/Comcast as my ISP. Do you actually run dhcpcd _before_ network > daemons like unbound(8) in rc(8)? I treat dhcpcd no differently than > base daemons like dhcpleased(8) since I run daemons that require a
Those daemons started very early are special, they don't start working until the interface is configured to use them. I'm not sure it's an appropriate place to run dhcpcd (and hacking /etc/rc to do it is definitely less than ideal). Is it any better if you do e.g. <whatever other setup> up !rcctl start dhcpcd in the relevant hostname.if file? > working IPv6 and IPv4 address. If you start dhcpcd where daemons like > dhcpleased(8) start, I wager you'll hit the issue. Presumably most don't > run dhcpcd like I do; thus the timeout bug will likely not affect many. Sounds like 10.0.10 in 7.6 release was no better for you either then and updating it to 10.1.0 helped Courtney. > I would personally prefer if -stable were updated with master with the > stated commit reverted; but if not, then I'll keep running my own version. Happy to backport if there's an upstream commit re this. But I'd rather not do that until then.
