According to what I have read, setting the IP_MULTICAST_TTL option to 0 on a multicast sending socket should prevent it sending to the network, and be destined only for listeners on the local computer. This only seems to work if there is a local listener on that particular group. If such a listener app is stopped other computers on the LAN get the messages, and tcpdump -v shows they have TTL 0 I am not sure if this is intended behaviour but it is unexpected.
Reply-To: akpm@linux-foundation.org (switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Thu, 27 Nov 2008 02:32:27 -0800 (PST) bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=12109 > > Summary: Multicast packets with TTL 0 sent out if not local > listener > Product: Networking > Version: 2.5 > KernelVersion: 2.6.27 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: IPV4 > AssignedTo: shemminger@linux-foundation.org > ReportedBy: jani@ubuntu.com > > > According to what I have read, setting the IP_MULTICAST_TTL option to 0 on a > multicast sending socket should prevent it sending to the network, and be > destined only for listeners on the local computer. > > This only seems to work if there is a local listener on that particular > group. > If such a listener app is stopped other computers on the LAN get the > messages, > and tcpdump -v shows they have TTL 0 > > I am not sure if this is intended behaviour but it is unexpected. > >
According to RFC 791 (Internet Protocol spec), page 20 any packet with a TTL = 0 must be destroyed. I encounter the same problem on Red Hat Enterprise Linux WS release 4 (Nahant Update 5) using kernel : Linux [hostname] 2.6.9-55.ELsmp #1 SMP Fri Apr 20 17:03:35 EDT 2007 i686 i686 i386 GNU/Linux
is there any fix scheduled ?
If this is still seen on modern kernels then please re-open/update and report to netdev@vger.kernel.org