From: KOVACS Krisztian <hidden@balabit.hu>
To: Julian Anastasov <ja@ssi.bg>
Cc: David Miller <davem@davemloft.net>,
kaber@trash.net, horms@verge.net.au, jkrzyszt@tis.icnet.pl,
netdev@vger.kernel.org
Subject: Re: [IPV4] LVS: Allow to send ICMP unreachable responses when real-servers are removed
Date: Thu, 31 May 2007 14:50:35 +0200 [thread overview]
Message-ID: <200705311450.36492@nienna> (raw)
In-Reply-To: <Pine.LNX.4.58.0705310239240.3745@u.domain.uli>
Hi,
On Thursday 31 May 2007 02:21, Julian Anastasov wrote:
> > I've posted a few patches making omitting this check possible
> > selectively back in March. Do those changes look acceptable?
> >
> > http://marc.info/?l=linux-netdev&m=117310979823297&w=3
> Also, i'm not sure if FLOWI_FLAG_TRANSPARENT should cause
> different values for flags to be cached many times. Users without this
> flag get EINVAL when fl4_src is not configured, other failures are not
> cached too. And as fl4_src is considered in both cases (both kinds of
> callers get same path on success) we don't need changes except in
> ip_route_output_slow()? By this way I hope we can avoid any possible
> forking of cache entries just by different flags.
Indeed, for output it probably does not matter, I've removed the flags
check from the flow index compare routine.
> Then we can use some more generic name, only for the flowi flag,
> eg. FLOWI_FLAG_ANYSRC or something better?
You're right, _TRANSPARENT was a bad idea. I'm not very good at
choosing names.
So what about this one?
Loosen source address check on IPv4 output
From: KOVACS Krisztian <hidden@balabit.hu>
ip_route_output() contains a check to make sure that no flows with
non-local source IP addresses are routed. This obviously makes using
such addresses impossible.
This patch introduces a flowi flag which makes omitting this check
possible. The new flag provides a way of handling transparent and
non-transparent connections differently.
Signed-off-by: KOVACS Krisztian <hidden@balabit.hu>
---
include/net/flow.h | 1 +
net/ipv4/route.c | 47 +++++++++++++++++++++++++----------------------
2 files changed, 26 insertions(+), 22 deletions(-)
diff --git a/include/net/flow.h b/include/net/flow.h
index f3cc1f8..1bfc0dc 100644
--- a/include/net/flow.h
+++ b/include/net/flow.h
@@ -49,6 +49,7 @@ struct flowi {
__u8 proto;
__u8 flags;
#define FLOWI_FLAG_MULTIPATHOLDROUTE 0x01
+#define FLOWI_FLAG_ANYSRC 0x02
union {
struct {
__be16 sport;
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 8603cfb..88d0a79 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -2396,7 +2396,7 @@ static int ip_route_output_slow(struct rtable **rp, const struct flowi *oldflp)
/* It is equivalent to inet_addr_type(saddr) == RTN_LOCAL */
dev_out = ip_dev_find(oldflp->fl4_src);
- if (dev_out == NULL)
+ if (dev_out == NULL && !(oldflp->flags & FLOWI_FLAG_ANYSRC))
goto out;
/* I removed check for oif == dev_out->oif here.
@@ -2407,29 +2407,32 @@ static int ip_route_output_slow(struct rtable **rp, const struct flowi *oldflp)
of another iface. --ANK
*/
- if (oldflp->oif == 0
- && (MULTICAST(oldflp->fl4_dst) || oldflp->fl4_dst == htonl(0xFFFFFFFF))) {
- /* Special hack: user can direct multicasts
- and limited broadcast via necessary interface
- without fiddling with IP_MULTICAST_IF or IP_PKTINFO.
- This hack is not just for fun, it allows
- vic,vat and friends to work.
- They bind socket to loopback, set ttl to zero
- and expect that it will work.
- From the viewpoint of routing cache they are broken,
- because we are not allowed to build multicast path
- with loopback source addr (look, routing cache
- cannot know, that ttl is zero, so that packet
- will not leave this host and route is valid).
- Luckily, this hack is good workaround.
- */
+ if (dev_out) {
+ if (oldflp->oif == 0
+ && (MULTICAST(oldflp->fl4_dst)
+ || oldflp->fl4_dst == htonl(0xFFFFFFFF))) {
+ /* Special hack: user can direct multicasts
+ and limited broadcast via necessary interface
+ without fiddling with IP_MULTICAST_IF or IP_PKTINFO.
+ This hack is not just for fun, it allows
+ vic,vat and friends to work.
+ They bind socket to loopback, set ttl to zero
+ and expect that it will work.
+ From the viewpoint of routing cache they are broken,
+ because we are not allowed to build multicast path
+ with loopback source addr (look, routing cache
+ cannot know, that ttl is zero, so that packet
+ will not leave this host and route is valid).
+ Luckily, this hack is good workaround.
+ */
+
+ fl.oif = dev_out->ifindex;
+ goto make_route;
+ }
- fl.oif = dev_out->ifindex;
- goto make_route;
- }
- if (dev_out)
dev_put(dev_out);
- dev_out = NULL;
+ dev_out = NULL;
+ }
}
next prev parent reply other threads:[~2007-05-31 12:50 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200704271705.l3RH5Brw026873@hera.kernel.org>
2007-05-14 10:21 ` [IPV4] LVS: Allow to send ICMP unreachable responses when real-servers are removed Patrick McHardy
2007-05-14 10:35 ` David Miller
2007-05-14 14:25 ` Janusz Krzysztofik
2007-05-14 14:32 ` Patrick McHardy
2007-05-14 15:49 ` Janusz Krzysztofik
2007-05-14 17:41 ` Patrick McHardy
2007-05-15 5:26 ` Simon Horman
2007-05-15 9:46 ` Janusz Krzysztofik
2007-05-15 16:11 ` Patrick McHardy
2007-05-15 23:41 ` Julian Anastasov
2007-05-17 11:25 ` Janusz Krzysztofik
2007-05-17 16:41 ` Patrick McHardy
2007-05-17 16:40 ` Patrick McHardy
2007-05-17 20:51 ` David Miller
2007-05-18 1:06 ` Simon Horman
2007-05-18 8:40 ` Julian Anastasov
2007-05-18 9:05 ` David Miller
2007-05-30 9:38 ` KOVACS Krisztian
2007-05-31 0:21 ` Julian Anastasov
2007-05-31 12:50 ` KOVACS Krisztian [this message]
2007-05-31 23:18 ` Julian Anastasov
2007-06-01 12:55 ` KOVACS Krisztian
2007-06-20 10:57 ` Balazs Scheidler
2007-06-21 7:56 ` Julian Anastasov
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=200705311450.36492@nienna \
--to=hidden@balabit.hu \
--cc=davem@davemloft.net \
--cc=horms@verge.net.au \
--cc=ja@ssi.bg \
--cc=jkrzyszt@tis.icnet.pl \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).