Date: Mon, 4 May 2020 10:32:56 +0100 From: Roy Marples <roy@marples.name> To: "Alexander V. Chernikov" <melifaro@freebsd.org>, Guy Yur <guyyur@gmail.com>, Steffen Christgau <mail@s14u.de>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: Notification about tentative IPv6 address from route socket Message-ID: <6e34907c-c24c-5d0f-6871-763d3147d5ff@marples.name> In-Reply-To: <799631588579004@mail.yandex.ru> References: <4f3a314a-f938-476b-f75e-e495756a5488@s14u.de> <718441588495188@mail.yandex.ru> <em01baf849-5432-4658-8b15-adb878efd40e@gandalf> <799631588579004@mail.yandex.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Alexander On 04/05/2020 08:58, Alexander V. Chernikov wrote: > 04.05.2020, 07:23, "Guy Yur" <guyyur@gmail.com>: >> Hi, >> >> ------ Original Message ------ >> From: "Alexander V. Chernikov" <melifaro@freebsd.org> >> To: "Steffen Christgau" <mail@s14u.de>; "freebsd-net@freebsd.org" >> <freebsd-net@freebsd.org> >> Sent: 2020-05-03 11:42:07 >> Subject: Re: Notification about tentative IPv6 address from route socket >> >>> 30.04.2020, 17:40, "Steffen Christgau" <mail@s14u.de>: >>>> Hi everybody, >>> Hi Steffen, >>>> ... >>>> >>>> 1) Is there a way to get notified about the address being available for >>>> usage (i.e. not tentative anymore, not duplicated) without _polling_ via >>> Not that I'm aware of :-( >>>> ... >>>> >>>> 2) I know FreeBSD is not Linux, but on Linux with netlink sockets I get >>>> notified about a) the address appearing (including flags) and b) some >>>> time later the address being not tentative anymore (detectable via >>>> flags). I wonder why the route socket on FreeBSD reports an address that >>>> is currently hardly to use. On the other hand, I understand that >>>> RTM_NEWADDR does exactly what is documented, i.e. to notify about an >>>> "address being added to iface". Nevertheless, wouldn't it make sense to >>>> tell an application that a change for an address takes place? I couldn't >>>> observe such a behavior for IPv6 on FreeBSD. If there is currently no >>>> really such notification, the kernel could emit a new message like >>>> RTM_ADDRCHANGE or it may repeats the emission of RTM_NEWADDR (which >>> It makes total sense. I have plans to update some rtsock internals and will take a look at this one. >>> Thank you for your suggestion! >> >> There is a phabricator differential written by Roy Marples that does >> this: >> https://reviews.freebsd.org/D5469 > Wow! Thank you for the pointing me to this review. Will look&test in a day or two. Since submitting that change over 4 years ago I have since fixed numerous other issues with how route(4) works on NetBSD and DragonFlyBSD. OpenBSD has some of these as well and to be fair one of my changes is based on theirs. socket: introduce SO_RERROR to detect receive buffer overflow https://gitweb.dragonflybsd.org/dragonfly.git/commit/7eaeff3d5b7170299f570487da1da8a4e87ab072 route: Add support for route(4) message filtering. https://gitweb.dragonflybsd.org/dragonfly.git/commit/8aeffa9f3b32ec4061b6573b6fca75507812a5f1 The same change as prior for NetBSD with an alternative API which can collect all future route message types: http://anonhg.netbsd.org/src/rev/8a3c6cf76b82 Without these changes, route(4) message delivery will always be unreliable. Other related changes to IPv6 DaD: net/if: introduce if_bylla to find an interface by hardware address https://gitweb.dragonflybsd.org/dragonfly.git/commit/c42bebbdd1ab596db6ade9bd27589b0045d0a4d1 inet6: discard NA messages with a lladdress we own https://gitweb.dragonflybsd.org/dragonfly.git/commit/e4c5aabdf0b701bbc3f9926061e79704a64cbce4 There are a lot more things that need fixing though, but this is the bulk of the effort. If FreeBSD can implement that then the deliberate compile time warnings dhcpcd spits out (it's in ports if you want to test) can be removed. Roy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6e34907c-c24c-5d0f-6871-763d3147d5ff>