From owner-freebsd-bugs Fri Jun 15 15:28:22 2001 Delivered-To: freebsd-bugs@freebsd.org Received: from limekiller.braithwaite.net (foo82.dsl.alink.net [207.135.112.82]) by hub.freebsd.org (Postfix) with ESMTP id DE3BD37B401; Fri, 15 Jun 2001 15:28:19 -0700 (PDT) (envelope-from matt@braithwaite.net) Received: by limekiller.braithwaite.net (Postfix, from userid 1001) id 786D95A7D; Fri, 15 Jun 2001 15:28:19 -0700 (PDT) To: ru@FreeBSD.org Cc: freebsd-bugs@FreeBSD.org Subject: Re: misc/26833: `route change default' broken when gateway is over down interface References: <200106081324.f58DOPm77871@freefall.freebsd.org> From: Matthew Braithwaite X-Attribution: mab X-Face: @fge8WW'#w^hZghU$,3gfTP2@56+jGR+wSn|.Ddh,5d6qi")q;sCrYh[W;z-]Q0avfG):{3&hq61!)x&&PUrp%upUD9v9bB2_bw-"0v(87+A`?=1+P`# Date: 08 Jun 2001 12:53:07 -0700 In-Reply-To: ru@FreeBSD.org's message of "Fri, 8 Jun 2001 06:24:25 -0700 (PDT)" Message-ID: <86iti64ul8.fsf@limekiller.braithwaite.net> Lines: 34 User-Agent: Gnus/5.0803 (Gnus v5.8.3) XEmacs/21.1 (Bryce Canyon) Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 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, 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. 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. Such a change may be very difficult to accomplish; I don't know. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message