don't put multicasts with mc_ttl=0 on the wire
Subsystems (3)
PATCH 1/1 don't put multicasts with mc_ttl=0 on the wire
A colleague of mine found that multicasts with a ttl of 0 can be sent on the wire. This happens if the sender doesn't belong to the destination multicast group.
With the following the multicast ttl is respected whether or not the sender belongs to the destination multicast group.
---
net/ipv4/route.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-)
net/ipv4/route.c +1 -2
@@ -2249,8 +2249,7 @@ static inline int __mkroute_output(struct rtable **result, }if (flags & (RTCF_BROADCAST |RTCF_MULTICAST )) { rth->rt_spec_dst = fl->fl4_src; -if (flags &RTCF_LOCAL && - !(dev_out->flags &IFF_LOOPBACK )) { +if (!(dev_out->flags &IFF_LOOPBACK )) { rth->u.dst.output = ip_mc_output;RT_CACHE_STAT_INC (out_slow_mc); }
Signature · 1 line
Arthur
David Miller
maintainerFrom: [email protected]
Date: Tue, 15 May 2007 12:56:02 -0700
Quoted 8 lines
A colleague of mine found that multicasts with a ttl of 0 can be sent on the wire. This happens if the sender doesn't belong to the destination multicast group.
With the following the multicast ttl is respected whether or not the sender belongs to the destination multicast group.
Signed-off-by Arthur Kepner <[email protected]>
This is actually used by some things if I remember correctly. See this command and code in net/ipv4/route.c:
/* 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;
Arthur,
I assume you're making use of the hack mentioned in route.c:
"... 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."
I don't know the details of the intent for this hack, but did you
test that it won't break them?
A multicast application that relies on the (unicast) routing table
at all is broken IMHO, as is an app that sets the TTL to 0, but shouldn't all ttl 0 packets about to be sent to the wire be dropped? Wouldn't that be a better way to handle this case?
+-DLS
[email protected] wrote on 05/15/2007 12:56:02 PM:
net/ipv4/route.c static inline int __mkroute_output(struct rtable
Quoted 19 lines
A colleague of mine found that multicasts with a ttl of 0 can be sent on the wire. This happens if the sender doesn't belong to the destination multicast group.
With the following the multicast ttl is respected whether or not the sender belongs to the destination multicast group.
Signed-off-by Arthur Kepner <[email protected]>---
net/ipv4/route.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-)net/ipv4/route.c +0
-0@@ -2249,8 +2249,7 @@ static inline int __mkroute_output(struct rtable
**result,
Quoted 17 lines
net/ipv4/route.c +1
-2}if (flags & (RTCF_BROADCAST |RTCF_MULTICAST )) { rth->rt_spec_dst = fl->fl4_src; -if (flags &RTCF_LOCAL && - !(dev_out->flags &IFF_LOOPBACK )) { +if (!(dev_out->flags &IFF_LOOPBACK )) { rth->u.dst.output = ip_mc_output;RT_CACHE_STAT_INC (out_slow_mc); }Signature · 7 lines
-- Arthur - 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