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!
Jul 29 2021
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:
Feb 1 2021
Now dealing with FreeBSD bugzilla routing socket overflow reports
Jan 30 2021
Jan 7 2021
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.
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?
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.
So, it looks like even the feature has been present in Linux for 8+ years, it hasn't been adopted by the relevant software.
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.
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.
Oct 3 2020
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.
Oct 2 2020
Sep 24 2020
Looks ok to me, thanks. This seems like it would be useful for programs that run under Capsicum.
Sep 23 2020
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.
Ensure no uninitialised padding is leaked.
Hopefully this is now enough context.
May 11 2020
Jul 12 2016
Let me clarify.
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.