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
next prev parent 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: linkBe 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.