Date: 08 Jun 2001 12:53:07 -0700 From: Matthew Braithwaite <matt@braithwaite.net> To: ru@FreeBSD.org Cc: freebsd-bugs@FreeBSD.org Subject: Re: misc/26833: `route change default' broken when gateway is over down interface Message-ID: <86iti64ul8.fsf@limekiller.braithwaite.net> In-Reply-To: ru@FreeBSD.org's message of "Fri, 8 Jun 2001 06:24:25 -0700 (PDT)" References: <200106081324.f58DOPm77871@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86iti64ul8.fsf>