From owner-freebsd-bugs Mon Jun 18 9:12: 9 2001 Delivered-To: freebsd-bugs@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 5277C37B403 for ; Mon, 18 Jun 2001 09:11:49 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f5IGB2T28965; Mon, 18 Jun 2001 19:11:02 +0300 (EEST) (envelope-from ru) Date: Mon, 18 Jun 2001 19:11:02 +0300 From: Ruslan Ermilov To: Matthew Braithwaite 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> Mail-Followup-To: Matthew Braithwaite , freebsd-bugs@FreeBSD.org References: <200106081324.f58DOPm77871@freefall.freebsd.org> <86iti64ul8.fsf@limekiller.braithwaite.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <86iti64ul8.fsf@limekiller.braithwaite.net>; from matt@braithwaite.net on Fri, Jun 08, 2001 at 12:53:07PM -0700 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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