Date: Fri, 04 Jun 2021 17:40:31 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 256393] Issue with recreation of ppp/tun interfaces Message-ID: <bug-256393-7501-17aEFr8stg@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-256393-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-256393-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=3D256393 --- Comment #17 from Eugene Grosbein <eugen@freebsd.org> --- (In reply to Alexander V. Chernikov from comment #14) I'm talking not about kernel behaviour only but abouth the whole complex of generally used scenarios. Considering also the comment of rgrimes@, let's t= hink about following cases: 1) Some routing daemon installs to FIB some /32 route learned dynamically. = It may have its reasons and it should not fail unless there is already such PI= NNED route in the FIB. Later some PPP daemon tries to assign that address to its interface as address of local or remote side and it should not fail with EE= XIST but override non-PINNED route. It should fail with EEXIST if PINNED route exists already. 2) Same in case of a routing daemon doing same things but route(8) instead = of another daemon trying to create a route or ifconfig(8) trying to assign same address, they both should fail only due to existing PINNED route. They shou= ld not fail otherwise and silently override possibly pre-existing non-PINNED r= oute including one installed by still running routing daemon. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-256393-7501-17aEFr8stg>