Date: Sat, 03 Nov 2018 17:06:13 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 231526] [PATCH] fix for dhclient alias issue Message-ID: <bug-231526-227-9OHfcHLpd4@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-231526-227@https.bugs.freebsd.org/bugzilla/> References: <bug-231526-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D231526 Conrad Meyer <cem@freebsd.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed CC| |cem@freebsd.org Resolution|--- |DUPLICATE --- Comment #1 from Conrad Meyer <cem@freebsd.org> --- Hm. This patch provides a window where the ordering is wrong, right? We delete the old address and routes, then add the new address and routes (at = this point old alias is first), then with your patch remove the alias and re-add= it (now second). Also, it unnecessarily removes and adds the unchanged alias address, which I expect may break things like TCP connections. Isn't the problem that we're (ipnat, ddclient, etc?) relying on address ordering on an interface at all? Alias is a special keyword to the ifconfig command just to allow configuring >1 address, but aliases have no special meaning in the kernel -- all addresses are equal and just hang off a linked list from the interface ifp object. Hypothetically we could add some sort of tagging via the ifa_flags field on interface addresses in the kernel, but there's no room in the SIOCAIFADDR i= octl for ifconfig to pass that additional information. Duplicating this to the original bug and will follow up ipnat / ddclient is= sue there. *** This bug has been marked as a duplicate of bug 119801 *** --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-231526-227-9OHfcHLpd4>