(usagi-users 02732) Re: Multicast IPv6 over (proto-41/sit) tunnels

["Jeroen Massar" <jeroen@xxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----

Pekka Savola [mailto:pekkas@xxxxxxxxxx] wrote:

> On Sun, 4 Jan 2004, Jeroen Massar wrote:
> > Is this because of the POINTTOPOINT flag? Or is there other code
> > preventing multicast packets and thus to be silently dropped?
> > ip6tables is empty btw.
> 
> For what it's worth, I've both received and sent v6 multicast over 
> tunnels.  It works, at least, with Red Hat's 2.4.20-20.7 -kernel.  I 
> haven't tested it with vanilla kernels or USAGI patch.. so something 
> might, of course, have changed in the meantime..

Yes, got it working and I am now listening to multicasted mp3's coming
from a machine in Amsterdam, low-cpu usage, low-traffic ;)
The setup: http://purgatory.unfix.org/network.gif
tunnelserver.ipng.nl runs my mp3cast application bound to the tunnel
interface and thus is sending the mp3's directly over the tunnel.
On purgatory.unfix.org I run ecmh which then distributes the multicast
stream to the interfaces that have sent a group join for that address,
except the interface where the packets come from ofcourse. If I set it to
broadcast it even sends it over the wireless link, but there is nothing
connected there though. The otherway around works too and I'll refine
the tool the coming week and do some major load testing on it.

Btw, using two machines to send different mp3's to the same multicast-ip+port
gives some very nice noise (ahem ;).

I have to do some more tests but I think that a socket created with
socket(PF_PACKET,SOCK_RAW,htons(ETH_P_ALL)); doesn't work with sit devices
when sending raw packets, one doesn't have to create a ll header, tcpdump
sees it, which uses libpcap + socket(PF_PACKET,SOCK_RAW) and which is in
front of the tcp chain. Fortunatly replacing SOCK_RAW with SOCK_DGRAM for
a second socket allows me to send the data, using the first for receives
and the second for sending and it all works. The good thing about this
is that it will scale much better than a PIM-SM which need to bind to
every single device to accomplish the same thing, like is happening on
BSD. I might be inclined to add PIM-SM capabilities to this so that it
can be used as a node in a PIM-SM network. But first get it up and running
in the currently envisioned setup :)

> (The tricky part with tunnels is that multicast apps like vic and sdr 
> don't use them by default, but rather pick the lowest-numbered 
> non-loopback device -- and you have to specify the device explicitly 
> with '-x <interface-index>' -parameter.  But as you are sending the 
> traffic based on tcpdump, this should not be a problem in this case.)

Uhuh and don't even think of mentioning endianness, which bit me again.
But long live ethereal and tcpdump ;)

Greets,
 Jeroen

-----BEGIN PGP SIGNATURE-----
Version: Unfix PGP for Outlook Alpha 13 Int.
Comment: Jeroen Massar / http://unfix.org/~jeroen

iQA/AwUBP/iaNymqKFIzPnwjEQIvFQCfRRgXuW2jzQAe4veEFUFQSKnHWEwAn2Rw
NBymJ34FN/5GVMkxMtL4M1q3
=/oDA
-----END PGP SIGNATURE-----