[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20071207132336.a503ec4e.mitch@linux.vnet.ibm.com>
Date: Fri, 7 Dec 2007 13:23:36 +0900
From: Mitsuru Chinen <mitch@...ux.vnet.ibm.com>
To: Jarek Poplawski <jarkao2@...il.com>
Cc: Jarek Poplawski <jarkao2@...pl>, netdev@...r.kernel.org,
David Miller <davem@...emloft.net>,
Rami Rosen <roszenrami@...il.com>
Subject: Re: [PATCH] [IPv4] Reply net unreachable ICMP message
On Thu, 6 Dec 2007 09:47:33 +0100
Jarek Poplawski <jarkao2@...pl> wrote:
> On 06-12-2007 09:14, Mitsuru Chinen wrote:
> > On Thu, 6 Dec 2007 08:49:47 +0100
> > Jarek Poplawski <jarkao2@...pl> wrote:
> >
> >> On 06-12-2007 07:31, Mitsuru Chinen wrote:
> >>> IPv4 stack doesn't reply any ICMP destination unreachable message
> >>> with net unreachable code when IP detagrams are being discarded
> >>> because of no route could be found in the forwarding path.
> >>> Incidentally, IPv6 stack replies such ICMPv6 message in the similar
> >>> situation.
> ...
> >> This patch seems to be wrong. It overrides err codes from
> >> fib_lookup, where such decisions should be made.
> >
> > fib_lookup() replies -ESRCH in this situation.
> > It is necessary to override the variable by the suitable error
> > number like the code under e_hostunreach label.
>
> Probably I miss something, but I can't see how can you be sure it's
> only -ESRCH possible here? Isn't opt->action() in fib_rules_lookup()
> supposed to return this -ENETUNREACH when needed?
Oh, excuse me. I did mistake.
fib_rules_lookup() replies -ESRCH when no route is found. The case
it replies -ENETUNREACH is that user adds unreachable route.
However, if the err value is override with no check, a blackhole
or prohibit route is treated as a unreachable route.
As the patch is already applied, I will send another patch to add
a check for it.
Thank you very much for pointing out the issue!
Best Regards,
----
Mitsuru Chinen <mitch@...ux.vnet.ibm.com>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists