dhcpcd-10.0.3 just released which also fixes some important stuff.

I just pushed out dhcpcd-10.0.2 which fixes some privsep issues.

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.

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.

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?

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

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?

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...

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.

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?

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.

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!

Attribution via git commit --author= would be nice next time please.

Adjust to latest git head.

wpa_supplicant now supports SO_RERROR upstream:
https://w1.fi/cgit/hostap/commit/?id=a579642bc3c92c98daabadb5bb36c2da26ab893f

Now dealing with FreeBSD bugzilla routing socket overflow reports
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253166

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

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 :)

Break out of the loop early on matching an address.

Move SO_RERROR so it sits within the correct place.

@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?

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?

Use NET_EPOCH_{ENTER,EXIT}

In D26538#590877, @markj wrote:

Looks ok to me, thanks. This seems like it would be useful for programs that run under Capsicum.

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:

_IOW is fine.

Ensure no uninitialised padding is leaked.

Hopefully this is now enough context.

In D5469#545864, @melifaro wrote:

Generally looking good, though my primary concern is interaction with the existing applications.

Both bird and frr ignore value of ifam_flags.

Will update the patch and look at the behaviour for both of them.

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.