Break out of the loop early on matching an address.
Thu, Oct 8
Mon, Oct 5
Move SO_RERROR so it sits within the correct place.
Sun, Oct 4
@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.
Sat, Oct 3
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.
Fri, Oct 2
Thu, Sep 24
Looks ok to me, thanks. This seems like it would be useful for programs that run under Capsicum.
Wed, Sep 23
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.