dhcpcd-10.0.3 just released which also fixes some important stuff.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jun 5 2024
Oct 6 2023
Jul 19 2023
I just pushed out dhcpcd-10.0.2 which fixes some privsep issues.
Apr 23 2023
In D22012#894877, @woodsb02 wrote:dhcpcd-10 will be released in the next few week or so. Following that, I intend to update this diff to target importing dhcpcd into base ahead of the FreeBSD-14 code slush.
Jan 6 2023
In D22012#862327, @melifaro wrote:Thank you for the clarification! Just to check: the relevant change Is commit @ 30 Aug, right? This looks like a regression, but the commit description looks a bit vague. I wasn't able to find any bug report or message in the ML. Did you / @roy_marples.name reported it? If that's a regression, maybe something can be change on the kernel side, so dhcp 10 is not exactly a blocker.
Aug 31 2022
I've addressed the IFF_UP and REBOOT comments with hopefully suitable answers but not marked them as done as I think the asker needs to be satisified and close themselves?
Aug 30 2022
In D22012#826669, @emaste wrote:I'd suggest updating this review to be a diff against the copy of dhcpcd now in vendor/ merged into contrib/, so that changes if any to existing dhcpcd files are clear
Aug 23 2022
You've addressed my concerns, thanks.
If it lands, this revision no longer fixes anything as such but interestingly should still apply if anyone wants to go down the route of seperating this in the future.
Looks good to me now, thanks.
The linklocal address is not derived from RA and should be marked as manual.
- Fix a minor issue with prior.
- Fix a minor issue managing the prefix with prior.
In D22012#822714, @meka_tilda.center wrote:I did a little research and it turns out that SIOCSPFXFLUSH_IN6 is only supported on FreeBSD and derivatives like DragonflyBSD so the check if it's defined is practically check if it's running on FreeBSD. As NetBSD removed it and OpenBSD doesn't have it, what will happen if we remove the SIOCSPFXFLUSH_IN6 call from dhcpcd?
Aug 9 2022
In D22012#819198, @bz wrote:Can you quickly explain how this works along with RS/RA handling for DHCPv6? What does dhcpc do in this case and what does it not do?
This is mainly triggered by the fact that network.subr for dhcpif has an unconditional call for IPv6 duplicating the IPv4 logic but that's not how it works in IPv6 land so I am confused...
Aug 8 2022
Oct 23 2021
Oct 22 2021
In D22012#735892, @driesm.michiels_gmail.com wrote:@roy_marples.name what I would suggest is that you try to work to 9.4.1 release which fixes a few bugs in the database.
In D22012#693232, @emaste wrote:In D22012#693142, @koobs wrote:ISC DHCP client/relay end of maintenance:
Note that we use OpenBSD's dhclient version, not ISC's. There's common ancestry, but OpenBSD's has been developed independently for some time. Using dhcpcd may well be the right thing to do for the FreeBSD base system, but ISC's announcement has no real weight on that.
Oct 20 2021
In D32563#735349, @emaste wrote:I'll take care of this
--author=Roy Marples <roy@marples.name> yes?
In D32563#735249, @bz wrote:So why do we think this is broken now? To me this initially (without looking at that code again after years) seems to be there to save us a lot of work if we cannot find the address later. So maybe this need a better explanation than just "it's broken because someone left a comment that says so"?
In D32563#735219, @bz wrote:Has anyone checked what this was before the epoch work came in?
Oct 19 2021
In D22012#734301, @philip wrote:Oh wow ... time flies. I've now been "testing" this patch for over two years. We should just do this.
Jul 29 2021
In D26652#705993, @kbowling wrote:In D26652#638569, @roy_marples.name wrote:Adjust to latest git head.
@roy_marples.name, I can't tell why this was so circuitous. It's a straight forward change and LGTM. There are people running full routes on FreeBSD like Netflix and FRR users like Netgate so this is a really desirable improvement. I appreciate your work and would be happy to funnel in other improvements if you add me to the reviewers or PRs in the future!
Feb 9 2021
Attribution via git commit --author= would be nice next time please.
Feb 8 2021
Adjust to latest git head.
Feb 7 2021
wpa_supplicant now supports SO_RERROR upstream:
https://w1.fi/cgit/hostap/commit/?id=a579642bc3c92c98daabadb5bb36c2da26ab893f
Feb 1 2021
Now dealing with FreeBSD bugzilla routing socket overflow reports
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253166
Jan 30 2021
Jan 7 2021
In D22012#480886, @imp wrote:I didn't see you address Brooks' objection in the posted thread. given the extreme level of exposure here, it needs to be answered satisfactorily
Jan 1 2021
SO_RERROR for ntpd, which FreeBSD also uses.
https://bugs.ntp.org/show_bug.cgi?id=3714
All changes requested to the SO_RERROR approach have been made.
I have done as asked and queried this approach on the freebsd-arch mailing list. No replies which I read as no-one has anything bad to say about the approach, but sadly nothing positive either.
I would really like to see some traction here in 2021 :)
Oct 8 2020
Break out of the loop early on matching an address.
Oct 5 2020
Move SO_RERROR so it sits within the correct place.
Oct 4 2020
@melifaro any update on this?
In D26652#593989, @pi wrote:I had cases where quagga missed routing updates, which caused inconsistent routing between different bgp speakers. This is probably still possible with frr7, and therefore I would welcome a way to at least get some indication that data was lost.
Use SO_RERROR in route(8).
Warn on any errors returned by read(2) rather than assuming we always get a route message.
Adjusted man page as requested.
In D26652#593976, @melifaro wrote:So, it looks like even the feature has been present in Linux for 8+ years, it hasn't been adopted by the relevant software.
In D26652#593926, @gnn wrote:While I applaud this idea for route(4)ing sockets I think that applying it broadly to other socket types has issues that need to be considered.
In D26652#593910, @tuexen wrote:Why would you want to limit the scope?
Because an application writer might get the impression that he/she will be notified if an incoming packet was dropped. This is not true since this patch only covers one of many reasons. If any application wants to detect this, it should add some sequence numbers to the data and it will know.
In D26652#593846, @emaste wrote:what other OSes share this API now?
Oct 3 2020
In D26652#593850, @tuexen wrote:In D26652#593848, @roy_marples.name wrote:In D26652#593846, @emaste wrote:what other OSes share this API now?
I originally implemented on NetBSD and ported it to DragonFly BSD.
OpenBSD has an API which dhcpcd also uses which is specific to the route(4) API where it sends a RTM_DESYNC message.
The irony being it has to send a message on a socket which has already overflowed.Maybe one can force that such a message (only one) is appended to the socket buffer even if it is full.
In D26652#593846, @emaste wrote:what other OSes share this API now?
Oct 2 2020
Use NET_EPOCH_{ENTER,EXIT}
Sep 24 2020
In D26538#590877, @markj wrote:Looks ok to me, thanks. This seems like it would be useful for programs that run under Capsicum.
Sep 23 2020
In D26538#590924, @emaste wrote:Hrm, @markj pointed out on IRC https://people.freebsd.org/~emaste/patches/SIOCGIFDATA.diff
One downside of this approach (vs NetBSD) is that we'll have trouble if we want to grow if_data in the future, although we could deal with that if/when it happens.
In D26538#590881, @emaste wrote:it looks like OpenBSD and NetBSD implemented this differently:
Ensure no uninitialised padding is leaked.
Hopefully this is now enough context.
May 11 2020
In D5469#545864, @melifaro wrote:
Jul 12 2016
Let me clarify.
In D5469#149446, @hrs wrote:Looks reasonable to add notification when ia6_flags is changed, but why is RTM_ADD used instead of RTM_CHANGE? rt_addrmsg() is for addition/removal of an address and RTM_ADD is translated to RTM_NEWADDR there.