Date: Mon, 05 Jun 2023 12:19:35 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 128954] ifconfig(8) deletes valid routes Message-ID: <bug-128954-7501-LxzhKo3QRH@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-128954-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-128954-7501@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=3D128954 --- Comment #8 from Alexander V. Chernikov <melifaro@FreeBSD.org> --- (In reply to Alexander V. Chernikov from comment #4) I'd like to state that I'm not particularly happy about this design decisio= n, but (as of now) I don't see an easy way to fix this. To avoid deleting the routes one needs to provide an alternative for the so= urce address, which is impossible for the system with a single ifa (given that 127.0.0.1 cannot be the source of such routes). To have an alternative, one needs to propagate the "change" event for the ifa instead of a pair of delete/add event. Specifically, 1) When scanning the routes on ifa deletion/change the logic for SaS select= ion, along with the logic for the nexthop creation has to be added. 2) Ifa change has to be propagated from the protocol control player (no such thing exists ATM) 3) Ifa change has to start from the userland (e.g. ifconfig has to be taugh= t to do replace instead of delete/update) 4) The current approach results in "silent" deletion not propagated to the routing socket. The new approach will result in the route changes. Making it compatible for rtsock-based routing daemons may be tricky. While 2) (partially) and 3) is going to be address by the upcoming Netlink enhancements for the address manipulation, the considerable amount of effort still remains, with the biggest part being backward compatibility. --=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-128954-7501-LxzhKo3QRH>