Date: Mon, 18 Jun 2001 19:11:02 +0300 From: Ruslan Ermilov <ru@FreeBSD.org> To: Matthew Braithwaite <matt@braithwaite.net> Cc: freebsd-bugs@FreeBSD.org Subject: Re: misc/26833: `route change default' broken when gateway is over down interface Message-ID: <20010618191102.C25910@sunbay.com> In-Reply-To: <86iti64ul8.fsf@limekiller.braithwaite.net>; from matt@braithwaite.net on Fri, Jun 08, 2001 at 12:53:07PM -0700 References: <200106081324.f58DOPm77871@freefall.freebsd.org> <86iti64ul8.fsf@limekiller.braithwaite.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jun 08, 2001 at 12:53:07PM -0700, Matthew Braithwaite wrote: > On Fri, 8 Jun 2001 06:24:25 -0700 (PDT), ru@FreeBSD.org said: > > > > This is the normal behavior of the route(8) command. Kernel just > > tells you that the gateway route could not be allocated for a route > > due to a misconfigured routing table. I've put some explanations > > here: > > > > sbin/route/route.c,v 1.47 > > sbin/route/route.8,v 1.25 > > I ought to have made two things clearer: first, I didn't encounter > this problem with the route(8) command. I encountered it while > feeding routing messages directly to the kernel. Second, while I > agree that route(8)'s diagnostic in this case was lousy, that's not > the problem I was reporting -- the problem is that the kernel's > behavior is wrong, because it violates the rule of least surprise. > > It is unreasonable on its face for the kernel to give an error for an > RTM_CHANGE that it a no-op, as in my example, where the RTM_CHANGE > attempts to change an existing route to what it already is. Similarly > it is unreasonable for the kernel to permit the addition of a route, > but to prevent it from being subsequently changed. > But it doesn't prevent! It does what you asked for, but warns you that the routing table is screwed ATM, and it was unable to allocate a "gateway" route. This is almost harmless, if followed by an additional RTM_ADD which will add a route with destination including the gateway from the previous RTM_CHANGE. > Although I only skimmed through the kernel code, my take on the > problem was that the EDQUOT is generated because the route's gateway > is considered in the context of the current routing table. Thus, the > kernel thinks you are attempting to change the default route to use a > gateway that is reachable over the default route, which is to say, > over itself, which is an error. But the correct behavior would be to > consider the route's gateway in the context of the routing table as it > would be without the route that is being changed. If the kernel did > this, it would see the RTM_CHANGE in the same light as the initial > RTM_ADD. > You ask for RTM_CHANGE and get RTM_DELETE in response?! The correct behavior is to RTM_DELETE this route IMHO. :-) -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010618191102.C25910>