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