From owner-freebsd-bugs Mon Jun 18 9:37: 5 2001 Delivered-To: freebsd-bugs@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id 8E43D37B401; Mon, 18 Jun 2001 09:37:00 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.4/8.11.4) with ESMTP id f5IGaoF13423; Mon, 18 Jun 2001 17:36:51 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.4/8.11.4) with ESMTP id f5IGaoh07157; Mon, 18 Jun 2001 17:36:50 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200106181636.f5IGaoh07157@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Ruslan Ermilov Cc: Matthew Braithwaite , freebsd-bugs@FreeBSD.ORG, brian@Awfulhak.org, Child Subject: Re: misc/26833: `route change default' broken when gateway is over down interface In-Reply-To: Message from Ruslan Ermilov of "Mon, 18 Jun 2001 19:11:02 +0300." <20010618191102.C25910@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Jun 2001 17:36:50 +0100 From: Brian Somers 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 ppp(8)s on-demand stuff works by removing IFF_UP from the interface and expecting all routes to survive. It should be possible to add and remove routes via addresses who's interfaces are down. I believe this must be what I'm having difficulty with on my current box at the moment :( > 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 -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message