Date: Mon, 18 Jun 2001 17:36:50 +0100 From: Brian Somers <brian@Awfulhak.org> To: Ruslan Ermilov <ru@FreeBSD.ORG> Cc: Matthew Braithwaite <matt@braithwaite.net>, freebsd-bugs@FreeBSD.ORG, brian@Awfulhak.org, Child <child@child.net.au> Subject: Re: misc/26833: `route change default' broken when gateway is over down interface Message-ID: <200106181636.f5IGaoh07157@hak.lan.Awfulhak.org> In-Reply-To: Message from Ruslan Ermilov <ru@FreeBSD.ORG> of "Mon, 18 Jun 2001 19:11:02 %2B0300." <20010618191102.C25910@sunbay.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <brian@Awfulhak.org> <brian@[uk.]FreeBSD.org> <http://www.Awfulhak.org>; <brian@[uk.]OpenBSD.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106181636.f5IGaoh07157>