All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Yair@arx.com, linux-kernel@vger.kernel.org,
	netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com
Subject: Re: Re-routing packets via netfilter (ip_rt_bug)
Date: Mon, 25 Apr 2005 17:28:57 +0200	[thread overview]
Message-ID: <426D0CB9.4060500@trash.net> (raw)
In-Reply-To: <E1DQ1Ct-00055s-00@gondolin.me.apana.org.au>

Herbert Xu wrote:
> You'll still BUG if the destination is multicast/broadcast.  I'm also
> unsure whether ipt_REJECT isn't susceptible to the same problem.
> Luckily ipt_MIRROR is no more :)

ipt_REJECT is fine, ip_route_input() is only used in NF_IP_FORWARD.
But you're right about multicast/broadcast still causing problems,
I'll have another look.

> What are the issues with getting rid of the ip_route_input path
> altogether?
> 
> The only thing we gain over calling ip_route_output is the ability
> to set the input device.  But even that is just a fake derived from
> the source address in a deterministic way.  Therefore any effects
> achievable through using ip_route_input can also be done by simply
> reconfiguring the policy routing table to look at the local source
> addresses instead of (or in conjunction with) the input device.

No, ip_route_me_harder() can be called for packets with non-local
source. ip_route_output_slow() rejects non-local source addresses,
so the only way to use them for policy routing is by using
ip_route_input().

Regards
Patrick

WARNING: multiple messages have this Message-ID (diff)
From: Patrick McHardy <kaber@trash.net>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org,
	Yair@arx.com, linux-kernel@vger.kernel.org
Subject: Re: Re-routing packets via netfilter (ip_rt_bug)
Date: Mon, 25 Apr 2005 17:28:57 +0200	[thread overview]
Message-ID: <426D0CB9.4060500@trash.net> (raw)
In-Reply-To: <E1DQ1Ct-00055s-00@gondolin.me.apana.org.au>

Herbert Xu wrote:
> You'll still BUG if the destination is multicast/broadcast.  I'm also
> unsure whether ipt_REJECT isn't susceptible to the same problem.
> Luckily ipt_MIRROR is no more :)

ipt_REJECT is fine, ip_route_input() is only used in NF_IP_FORWARD.
But you're right about multicast/broadcast still causing problems,
I'll have another look.

> What are the issues with getting rid of the ip_route_input path
> altogether?
> 
> The only thing we gain over calling ip_route_output is the ability
> to set the input device.  But even that is just a fake derived from
> the source address in a deterministic way.  Therefore any effects
> achievable through using ip_route_input can also be done by simply
> reconfiguring the policy routing table to look at the local source
> addresses instead of (or in conjunction with) the input device.

No, ip_route_me_harder() can be called for packets with non-local
source. ip_route_output_slow() rejects non-local source addresses,
so the only way to use them for policy routing is by using
ip_route_input().

Regards
Patrick

  reply	other threads:[~2005-04-25 15:43 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-25  9:49 Re-routing packets via netfilter (ip_rt_bug) Yair Itzhaki
2005-04-25  9:07 ` Patrick McHardy
2005-04-25  9:07   ` Patrick McHardy
2005-04-25 10:52   ` Herbert Xu
2005-04-25 10:52     ` Herbert Xu
2005-04-25 15:28     ` Patrick McHardy [this message]
2005-04-25 15:28       ` Patrick McHardy
2005-04-25 21:34       ` Herbert Xu
2005-04-25 21:34         ` Herbert Xu
2005-04-26  0:08         ` Patrick McHardy
2005-04-26  0:08           ` Patrick McHardy
2005-04-26  0:39           ` Herbert Xu
2005-04-26  0:39             ` Herbert Xu
2005-04-26 13:17             ` Patrick McHardy
2005-04-26 13:17               ` Patrick McHardy
2005-04-26 23:28               ` Herbert Xu
2005-04-26 23:28                 ` Herbert Xu
2005-04-27  0:56                 ` Patrick McHardy
2005-04-27  0:56                   ` Patrick McHardy
2005-04-27  1:07                   ` Herbert Xu
2005-04-27  1:07                     ` Herbert Xu
2005-04-27 10:26                     ` Patrick McHardy
2005-04-27 10:26                       ` Patrick McHardy
2005-04-27 10:30                       ` Herbert Xu
2005-04-27 10:30                         ` Herbert Xu
2005-04-27 10:41                         ` Jozsef Kadlecsik
2005-04-27 10:41                           ` Jozsef Kadlecsik
2005-04-27 11:35                           ` Herbert Xu
2005-04-27 11:35                             ` Herbert Xu
2005-04-27 11:54                             ` Herbert Xu
2005-04-27 11:54                               ` Herbert Xu
2005-04-27 12:05                               ` Patrick McHardy
2005-04-27 12:05                                 ` Patrick McHardy
2017-07-10  9:20 ` Helbing63
2020-07-23  7:25 ` technical support jollyzula
2020-07-23  7:25 ` Canon.com/ijsetup jollyzula
2005-04-25 16:51 Re-routing packets via netfilter (ip_rt_bug) Yair Itzhaki
2005-04-25 16:51 ` Yair Itzhaki
2005-04-26 15:39 Yair Itzhaki
2005-05-02 17:17 Yair Itzhaki
2005-07-14 12:27 ` Ric Wheeler
2005-07-14 12:27 ` Ric Wheeler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=426D0CB9.4060500@trash.net \
    --to=kaber@trash.net \
    --cc=Yair@arx.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@oss.sgi.com \
    --cc=netfilter-devel@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.