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.
Signed-off-by: Mitsuru Chinen <redacted>
---
net/ipv4/route.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
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.
Signed-off-by: Mitsuru Chinen <redacted>
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.
Signed-off-by: Mitsuru Chinen <redacted>
---
net/ipv4/route.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
Hello, Jarek,
I am sorry, but I think I am nor sure I underatand exactly what you mean when
you say:
"It overrides err codes from fib_lookup, where such decisions should be made."
What is incorrect here ?
There are two lines added in this patch;
IP_INC_STATS_BH(IPSTATS_MIB_INNOROUTES);
and err = -ENETUNREACH;
The first one is, regardless to say, not relevant to err codes.
The second, err = -ENETUNREACH, is from: ip_route_input_slow().
(net/ipv4/route.c).
Assigning values to err is done more than once in this method;
for example,
e_hostunreach:
err = -EHOSTUNREACH;
e_inval:
err = -EINVAL;
e_nobufs:
err = -ENOBUFS;
So I don't think anything is incorrect here.
Regards,
Rami Rosen
On Dec 6, 2007 9:49 AM, Jarek Poplawski [off-list ref] wrote:
On 06-12-2007 07:31, Mitsuru Chinen wrote:
quoted
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.
Signed-off-by: Mitsuru Chinen <redacted>
---
net/ipv4/route.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
This patch seems to be wrong. It overrides err codes from
fib_lookup, where such decisions should be made.
Regards,
Jarek P.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 6 Dec 2007 08:49:47 +0100
Jarek Poplawski [off-list ref] wrote:
On 06-12-2007 07:31, Mitsuru Chinen wrote:
quoted
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.
Signed-off-by: Mitsuru Chinen <redacted>
---
net/ipv4/route.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
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.
Best Regards,
----
Mitsuru Chinen [off-list ref]
On Thu, 6 Dec 2007 08:49:47 +0100
Jarek Poplawski [off-list ref] wrote:
quoted
On 06-12-2007 07:31, Mitsuru Chinen wrote:
quoted
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.
...
quoted
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?
Jarek P.
On Thu, 6 Dec 2007 09:47:33 +0100
Jarek Poplawski [off-list ref] wrote:
On 06-12-2007 09:14, Mitsuru Chinen wrote:
quoted
On Thu, 6 Dec 2007 08:49:47 +0100
Jarek Poplawski [off-list ref] wrote:
quoted
On 06-12-2007 07:31, Mitsuru Chinen wrote:
quoted
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.
...
quoted
quoted
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 [off-list ref]