Excuse me if I am bothering you again, but is there something so wrong
with what I point out, or is multicasting so boring, that it doesn't
even deserve an answer? :)
Please consider.
----- Message d'origine ----
> Preferred source address selection in the routing table ("src" field)
> currently does not work properly with multicast destination adresses:
> it leads packets to be routed through the wrong network device (see
> http://bugzilla.kernel.org/show_bug.cgi?id=7398).
>
> It seems to me that the main reason for this is compatibility with
> old multicast applications, and I can see no fundamental reason
> preventing the use of this two features together.
>
> Why not finding a way to let them coexist?
>
> What about a sysctl option, letting users who really want to disable
> the compatibility hack, and restore normal behavior? I am thinking
> about something like the patch below. Or does another simple way to
> do it come to your mind?
>
> What do you think about it?
diff -urNp linux-2.6.18/Documentation/filesystems/proc.txt
linux-2.6.18/Documentation/filesystems/proc.txt
--- linux-2.6.18/Documentation/filesystems/proc.txt 2006-09-19
20:42:06.000000000 -0700
+++ linux-2.6.18/Documentation/filesystems/proc.txt 2006-10-26
05:13:15.000000000 -0700
@@ -1758,6 +1758,15 @@ max_delay, min_delay
Delays for flushing the routing cache.
+mc_src_strict
+-------------
+
+There is a hack in the kernel router which provides compatibility for old
+multicast applications such as vic, vat and friends. Unfortunately, this
+hack also breaks normal behavior of preferred source address selection
+(iproute2 "src" field) with multicast and limited broadcast. Enabling this
+option disables this hack and restores normal (strict) behavior.
+
redirect_load, redirect_number
------------------------------
diff -urNp linux-2.6.18/include/linux/sysctl.h
linux-2.6.18/include/linux/sysctl.h
--- linux-2.6.18/include/linux/sysctl.h 2006-09-19 20:42:06.000000000 -0700
+++ linux-2.6.18/include/linux/sysctl.h 2006-10-26 04:25:00.000000000 -0700
@@ -433,6 +433,7 @@ enum {
NET_IPV4_ROUTE_MIN_ADVMSS=17,
NET_IPV4_ROUTE_SECRET_INTERVAL=18,
NET_IPV4_ROUTE_GC_MIN_INTERVAL_MS=19,
+ NET_IPV4_ROUTE_MC_SRC_STRICT=20,
};
enum
diff -urNp linux-2.6.18/net/ipv4/route.c linux-2.6.18/net/ipv4/route.c
--- linux-2.6.18/net/ipv4/route.c 2006-09-19 20:42:06.000000000 -0700
+++ linux-2.6.18/net/ipv4/route.c 2006-10-26 05:11:00.000000000 -0700
@@ -132,6 +132,7 @@ static int ip_rt_mtu_expires = 10 * 60
static int ip_rt_min_pmtu = 512 + 20 + 20;
static int ip_rt_min_advmss = 256;
static int ip_rt_secret_interval = 10 * 60 * HZ;
+static int ip_rt_mc_src_strict = 0;
static unsigned long rt_deadline;
#define RTprint(a...) printk(KERN_DEBUG a)
@@ -2416,7 +2417,7 @@ static int ip_route_output_slow(struct r
of another iface. --ANK
*/
- if (oldflp->oif == 0
+ if (!ip_rt_mc_src_strict && oldflp->oif == 0
&& (MULTICAST(oldflp->fl4_dst) || oldflp->fl4_dst ==
0xFFFFFFFF)) {
/* Special hack: user can direct multicasts
and limited broadcast via necessary interface
@@ -2431,6 +2432,12 @@ static int ip_route_output_slow(struct r
cannot know, that ttl is zero, so that packet
will not leave this host and route is valid).
Luckily, this hack is good workaround.
+
+ Unfortunately, it also breaks normal behavior of
+ source address preference, so I added a sysctl option
+ to let the user disable this hack and restore normal
+ behavior. By default, the hack is still enabled (old
+ compatibility behavior). -- PY
*/
fl.oif = dev_out->ifindex;
@@ -3057,6 +3064,15 @@ ctl_table ipv4_route_table[] = {
.proc_handler = &proc_dointvec_jiffies,
.strategy = &sysctl_jiffies,
},
+ {
+ .ctl_name = NET_IPV4_ROUTE_MC_SRC_STRICT,
+ .procname = "mc_src_strict",
+ .data = &ip_rt_mc_src_strict,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &ipv4_doint_and_flush,
+ .strategy = &ipv4_doint_and_flush_strategy,
+ },
{ .ctl_name = 0 }
};
#endif
--
Pierre Ynard
___________________________________________________________________________
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions !
Profitez des connaissances, des opinions et des expériences des internautes sur
Yahoo! Questions/Réponses
http://fr.answers.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
