|
IPv6 Multicast Streaming
For the testing I have enabled a MP3 multicast stream. You will see this originating from purgatory.unfix.org. The IPv6 Multicast address to subscribe to is ff08::4 and the port on which the mp3 stream comes in is 1500, 1502 carries the title data. You can use eg FreeAmp IPv6 or other IPv6 Multicast RTP capable mp3 players to listen to this stream.
Logically this is currently only available on the IPng and Concepts POPs at the moment.
IPv6 Multicast Streaming basic question;)
![[de]](/s/countries/de.gif) Shadow Hawkins on Sunday, 29 August 2004 20:20:55
hello ip6people,
i am new to ipv6 and i have a question.
i am working on an "streaming application "for
OSX (Free Bsd ,Darwin kernel,)
When i am connected thru a tunnel, e.g.
(http://www.sixxs.net/tools/whois/?handle=MM76-6BONE) with the mbone, or an ip6 network
and start streaming, can anybody who is connected to the "Mbone"
receive the multicast stream ?
regards
marc manthey
O-)
IPv6 Multicast Streaming
![[nl]](/s/countries/nl.gif) Shadow Hawkins on Sunday, 11 January 2004 17:09:38
sounds nice, but...
How do i set this up?
I downloaded ecmh (the debian package, used alien to convert it, because the sources didn't build for me). I'm running ecmh. As soon as I enabled my tunnel to Concepts, this showed up in my syslog: Jan 11 15:48:41 server ecmh: Added concepts, link 59, hw sit/776 with an MTU of 1480, linklocal: fe80::503c:3190.
So far so good, I think. I tried finding info on subscribe to the address, but I didn't find anything. Also, how do I add the stream to FreeAmp?
Both router and client (on the subnet over the tunnel) are running the latest gentoo, router with 2.4.24, client 2.6.0
IPv6 Multicast Streaming
Can you submit problem reports to either my email address (jeroen@unfix.org) or the SourceForge bugs database? Ofcourse be specific etc.
Freeamp can be used by hitting the open button and specifying:
rtp://[ff08::4]:1500 and then "open url"
At least for my stream :)
If it doesn't work... try to do some tcpdump's.
You can also send a -SIGUSR1 to the ecmh pid (or use /etc/init.d/ecmh dumpstats)
which will dump the stats in /var/run/ecmh.dump and you can see what it is doing at that moment. Otherwise, compile the tool with debugging enabled (define DEBUG in ecmh.h) and receive a lot of information ;)
IPv6 Multicast Streaming
Shadow Hawkins on Sunday, 11 January 2004 18:05:58
Do I need IP:multicast in the kernel? (router, client, or both)
IPv6 Multicast Streaming
Nope.. that is IPv4 btw. But theortically speaking you don't even need IPv6 in your kernel for this to work as ecmh takes care of that part ;)
IPv6 Multicast Streaming
Shadow Hawkins on Sunday, 11 January 2004 18:23:30
good, that saves me 2 reboots.
Should it work on the client at all?
Setup:
Concepts POP --tunnel-- router --subnet-- client
The client is ipv6 reachable.
I'm running ecmh on both client and router.
Ofcourse i'd try running it on the router, but that doesn't have ipv6, and
I can't find anything for the commandline
IPv6 Multicast Streaming
Don't run ecmh on the client, it is not needed.
You only need it if you got two or more interfaces on a machine that needs to forward the traffic.
What do you mean with that the router doesn't have IPv6 ?
uplink <-- tunnel --> router (running ecmh) <-- ethernet --> client(s)
Try p0c.
IPv6 Multicast Streaming
Shadow Hawkins on Sunday, 11 January 2004 19:48:04
the router is ipv6 enabled as well ofcourse, my bad.
pob tells me this:
root@server poc-0.3.6 # ./pob-3119-rb -s ff08::4
gethostbyname: Success
Could not open socket
FreeAmp tells me: buffering 0% (and stays like this forever)
on the router, tcpdump | grep multicast tells me mainly this:
fe80::503c:3190 > ip6-allnodes: HBH icmp6: multicast listener query max resp delay: 2000 addr: :: [hlim 1]
a little less this:
fe80::d5c5:1bfc > ip6-allnodes: HBH icmp6: multicast listener query max resp delay: 2000 addr: :: [hlim 1]
even less this:
fe80::d5c5:1bfc > ff08::4: HBH icmp6: multicast listener report max resp delay: 0 addr: ff08::4 [hlim 1]
and one time this:
18:55:36.885124 fe80::d5c5:1bfc > ::: HBH icmp6: multicast listener report max resp delay: 0 addr: :: [hlim 1]
18:55:36.897620 fe80::d5c5:1bfc > ::7835:1540:48f3:ffbf:c4f4:ffbf: HBH icmp6: multicast listener report max resp delay: 0 addr: ::7835:1540:48f3:ffbf:c4f4:ffbf [hlim 1]
on the client tcpdumps | grep muticast keeps repeating this:
18:35:04.767892 fe80::250:fcff:fe2a:79c9 > ff02::1:ff2a:79c9: HBH icmp6: multicast listener report max resp delay: 0 addr: ff02::1:ff2a:79c9 [hlim 1]
18:39:43.461376 fe80::280:48ff:fe19:f4e6 > ip6-allnodes: HBH icmp6: multicast listener query max resp delay: 2000 addr: :: [hlim 1]
18:39:43.591329 fe80::250:fcff:fe2a:79c9 > ff02::1:ff84:df8e: HBH icmp6: multicast listener report max resp delay: 0 addr: ff02::1:ff84:df8e [hlim 1]
18:39:44.091911 fe80::250:fcff:fe2a:79c9 > ff02::1:ff2a:79c9: HBH icmp6: multicast listener report max resp delay: 0 addr: ff02::1:ff2a:79c9 [hlim 1]
18:39:44.267045 fe80::250:fcff:fe2a:79c7 > ff02::1:ff2a:79c7: HBH icmp6: multicast listener report max resp delay: 0 addr: ff02::1:ff2a:79c7 [hlim 1]
18:39:44.767698 fe80::250:fcff:fe2a:79c7 > ff02::1:ff05:4a42: HBH icmp6: multicast listener report max resp delay: 0 addr: ff02::1:ff05:4a42 [hlim 1]
18:40:03.542891 fe80::250:bfff:fed9:4f89 > ip6-allnodes: HBH icmp6: multicast listener query max resp delay: 2000 addr: :: [hlim 1]
18:40:03.614569 fe80::250:fcff:fe2a:79c9 > ff02::1:ff84:df8e: HBH icmp6: multicast listener report max resp delay: 0 addr: ff02::1:ff84:df8e [hlim 1]
18:40:04.615717 fe80::250:fcff:fe2a:79c9 > ff02::1:ff2a:79c9: HBH icmp6: multicast listener report max resp delay: 0 addr: ff02::1:ff2a:79c9 [hlim 1]
18:40:04.791052 fe80::250:fcff:fe2a:79c7 > ff02::1:ff2a:79c7: HBH icmp6: multicast listener report max resp delay: 0 addr: ff02::1:ff2a:79c7 [hlim 1]
all output is very occasional, about 30 lines per hour on the router, and the client about 20 in 10 minutes
Note: fe80::503c:3190 is on the tunnel (my end)
fe80::250:bfff:fed9:4f89 is on the only interface of the client
the others are not assigned to any of my boxes
IPv6 Multicast Streaming
fe80::503c:3190 > ip6-allnodes: HBH icmp6: multicast listener query max resp delay: 2000 addr: :: [hlim 1]
This is your box asking if someone could tell him in what kind of groups the others are interrested in.
The following tells that the POP (nlams01) wants to receive traffic destined to ff08::4 as it knows someone who wants that traffic (which is at least my client)
fe80::d5c5:1bfc > ff08::4: HBH icmp6: multicast listener report max resp delay: 0 addr: ff08::4 [hlim 1]
This two are bugs, I think as one should never ever ask for :: and the other is currupted, wonder why it does that.
18:55:36.885124 fe80::d5c5:1bfc > ::: HBH icmp6: multicast listener report max resp delay: 0 addr: :: [hlim 1] 18:55:36.897620 fe80::d5c5:1bfc > ::7835:1540:48f3:ffbf:c4f4:ffbf: HBH icmp6: multicast listener report max resp delay: 0 addr: ::7835:1540:48f3:ffbf:c4f4:ffbf [hlim 1]
These are neighbour discovery.
18:35:04.767892 fe80::250:fcff:fe2a:79c9 > ff02::1:ff2a:79c9: HBH icmp6: multicast listener report max resp delay: 0 addr: ff02::1:ff2a:79c9 [hlim 1]
I don't see any reports where your box asks for ff08::4 btw...
Hmmm using Windows XP ? Try and turn of the firewall ;)
See the FAQ page.
IPv6 Multicast Streaming
Shadow Hawkins on Sunday, 11 January 2004 20:05:35 Hmmm using Windows XP ? Try and turn of the firewall ;)
See the FAQ page.
Well, yeah... on the 2 boxes in the network I haven't mentioned (which means neither server nor client). No firewalling whatsoever on server or client.
also, ecmh.dump shows this:
*** Subscription Information Dump
Group: ff08::4
Interface: concepts
::
*** Subscription Information Dump (end - 1 groups, 1 subscriptions)
*** Interface Dump
Interface: concepts
Index : 59
MTU : 1280
LL : fe80::503c:3190
<3 more interfaces>
*** Interface Dump (end - 3 interfaces)
*** Statistics Dump
Version : ecmh 2004.01.10
Started : 2004-01-11 19:04:34
Uptime : 0 days 00:36:43
Interfaces Monitored : 3
Groups Managed : 1
Total Subscriptions : 1
Packets Received : 12731
Packets Sent : 30
Bytes Received : 1626007
Bytes Sent : 2256
*** Statistics Dump (end)
IPv6 Multicast Streaming
Windows XP has default builtin firewalling that is enabled and filters multicast.... check the FAQ and turn it off.
*** Subscription Information Dump Group: ff08::4 Interface: concepts :: *** Subscription Information Dump (end - 1 groups, 1 subscriptions)
This means that the POP wants to receive data destined to ff08::4, which is correct ;)
No subscriptions for you though.
IPv6 Multicast Streaming
Shadow Hawkins on Sunday, 11 January 2004 20:15:19
Ok, more clear this time:
No WinXP involved in the whole problem.
Only Gentoo Linux 1.4 on both the router and the client, neither of them firewalled.
IPv6 Multicast Streaming
Then I suggest tcpdumping the interface's between your router and client and watching for ICMPv6 messages. You should see both Report (froms the client and router) and Queries (from the router) every now and then.
When you start your IPv6 multicast tool it should directly send a Report onto the network asking for the traffic.
Check /proc/net/dev_mcast and /proc/net/mcfilter6 too to see if it subscribed correctly.
IPv6 Multicast Streaming
Shadow Hawkins on Sunday, 11 January 2004 20:32:25
Nothing but the normal stuff on the interfaces: normal neighbor sol/adv, and router advertisement
client:
workstation root # cat /proc/net/mcfilter6
Idx Device Multicast Address Source Address INC EXC
workstation root # cat /proc/net/dev_mcast
2 eth0 1 0 333300000004
2 eth0 1 0 3333ffd94f89
2 eth0 1 0 333300000001
2 eth0 1 0 01005e000001
5 vmnet8 1 0 3333ffc00008
5 vmnet8 1 0 333300000001
5 vmnet8 1 0 01005e000001
router:
server root # cat /proc/net/mcfilter6
server root # cat /proc/net/dev_mcast
2 eth0 1 0 3333ff000000
2 eth0 1 0 333300000002
2 eth0 1 0 3333ff758663
2 eth0 1 0 333300000001
2 eth0 1 0 01005e000001
6 eth1 1 0 3333ff000000
6 eth1 1 0 333300000002
6 eth1 1 0 3333ff000002
6 eth1 1 0 3333ff19f4e6
6 eth1 1 0 333300000001
6 eth1 1 0 01005e000001
IPv6 Multicast Streaming
Hmm odd as your application should do a JOIN to the group which should cause the machine to send a REPORT to the interface that the application is listening on. Could you verify that the application is sending the REPORT to the correct interface?
I also have a gut feeling btw that Linux only does MLDv2 on some newer kernels and I will be rounding up support for that tonight/tomorrow.
IPv6 Multicast Streaming
Shadow Hawkins on Tuesday, 13 January 2004 14:03:35
I tried compiling emch with DEBUG, and after some time I succeeded. My syslog is now showing this:
Jan 13 13:43:22 server ecmh: ecmh 2004.01.10 by Jeroen Massar <jeroen@unfix.org>
Jan 13 13:43:22 server ecmh: Running as PID 22655
Jan 13 13:43:22 server ecmh: Updating Interfaces
Jan 13 13:43:22 server ecmh: Added concepts, link 59, hw sit/776 with an MTU of 1280, linklocal: fe80::503c:3190
Jan 13 13:43:22 server ecmh: Added eth0, link 2, hw ether/1 with an MTU of 1500, linklocal: fe80::220:35ff:fe75:8663
Jan 13 13:43:22 server ecmh: Added eth1, link 6, hw ether/1 with an MTU of 1500, linklocal: fe80::280:48ff:fe19:f4e6
Jan 13 13:43:22 server ecmh: *** Updating Interfaces - done
Jan 13 13:43:22 server ecmh: *** Sending MLD Queries
Jan 13 13:43:22 server ecmh: *** Sending MLD Queries - done
Jan 13 13:48:22 server ecmh: *** Timeout
Jan 13 13:48:22 server ecmh: Updating Interfaces
Jan 13 13:48:22 server ecmh: *** Updating Interfaces - done
Jan 13 13:48:22 server ecmh: *** Sending MLD Queries
Jan 13 13:48:22 server ecmh: *** Sending MLD Queries - done
Jan 13 13:48:22 server ecmh: *** Timeout - done
Jan 13 13:51:04 server ecmh: Last update was 317 seconds ago -> resending
Jan 13 13:53:22 server ecmh: *** Timeout
Jan 13 13:53:22 server ecmh: Updating Interfaces
Jan 13 13:53:22 server ecmh: *** Updating Interfaces - done
Jan 13 13:53:22 server ecmh: *** Sending MLD Queries
Jan 13 13:53:22 server ecmh: *** Sending MLD Queries - done
Jan 13 13:53:22 server ecmh: *** Timeout - done
Jan 13 13:56:05 server ecmh: Last update was 601 seconds ago -> resending
Jan 13 13:56:23 server ecmh: Last update was 319 seconds ago -> resending
Jan 13 13:58:22 server ecmh: *** Timeout
Jan 13 13:58:22 server ecmh: Updating Interfaces
Jan 13 13:58:22 server ecmh: *** Updating Interfaces - done
Jan 13 13:58:22 server ecmh: *** Sending MLD Queries
Jan 13 13:58:22 server ecmh: *** Sending MLD Queries - done
Jan 13 13:58:22 server ecmh: *** Timeout - done
IPv6 Multicast Streaming
This described that it has some groups and actually only is handy for checking the behaviour of the program aka that it is doing it's stuff.
Btw 2004.01.11 is out already and a version sporting MLDv2 is due for tonight/tomorrow depending on the debugging sessions it is undergoing.
As apparently some folks wrote up a quite similar idea I will be adjusting ecmh to adhere to the specs of that document.
Though I am still intending to add the loopchecking code thus allowing it to be deployed without the trouble described in that document.
IPv6 Multicast Streaming
I've updated the IP address of the stream.
It is now using rtp://radio.unfix.org:1833, thus a nice hostname which is persistent and port 1833 as that is called udpradio. There is no fixed port number so that should be the most relevant one. The IP address is built based on the RFC3306 and RFC3307. The last bit almost spells RADIO (8AD10).
IPv6 Multicast Streaming
![[hu]](/s/countries/hu.gif) Carmen Sandiego on Friday, 16 January 2004 21:16:05
Hi!
Is this working now ?
I wanted to try it. With freeamp I had no success. Then I tried pob-3119-rb.
I got no sound, it just keep saying 'Prebuffering: 0.00%', but I can see some multicasting relevant packets in tcpdump. My config is: Concepts - router (running ecmh) - client. Client and router are both Linux.
ecmh.dump contains the following:
*** Subscription Information Dump
Group: ff08::4
Interface: sixxs
:: (241996 seconds old)
Group: ff3e:3c:3ffe:8114:2000:8052:6164:696f
Interface: sixxs
:: (241697 seconds old)
Group: ff3e:3c:3ffe:8114:2000:240:8008:ad10
Interface: sixxs
:: (160397 seconds old)
Group: ff05::2
Interface: sixxs
:: (201356 seconds old)
*** Subscription Information Dump (end - 4 groups, 4 subscriptions)
[...]
*** Statistics Dump
Version : ecmh 2004.01.11
Started : 2004-01-13 21:18:31 GMT
Uptime : 2 days 22:52:31
Interfaces Monitored : 3
Groups Managed : 4
Total Subscriptions : 4
Packets Received : 3414304
Packets Sent : 2763
Bytes Received : 953204712
Bytes Sent : 209148
*** Statistics Dump (end)
I can show the other parts of it. But I don't want to make a too long post.
I found the following in tcpdump's output:
21:08:22.262632 fe80::a00:1 > ip6-allnodes: HBH icmp6: multicast listener query max resp delay: 2000 addr: :: [hlim 1]
21:13:06.491233 fe80::a00:1 > ff02::16: HBH icmp6: type-#206 [hlim 1]
Has anybody managed to get it work by the way ? I'd like to try this multicasting think, but I have no ideal.
Thanks,
Mark Szabo
IPv6 Multicast Streaming
There is a issue with Linux 2.4.22+ not falling back to MLDv1. As ecmh will have MLDv2 support fully implemented and tested the coming week this will solve that problem without everybody needing to patch their kernels.
IPv6 Multicast Streaming
Shadow Hawkins on Saturday, 14 February 2004 23:16:27
not meaning to hurry you, but any ETA on this? or, alternatively, any kernelpatch?
(sigh, why won't multicast work for me)
IPv6 Multicast Streaming
(sigh, why won't multicast work for me)
Because your kernel sucks(tm) ;)
The newer Linux kernels do MLDv2 and have a problem falling back to v1.
At least that is the most probable answer.
You could ofcourse provide some debugging information on what you are trying to accomplish.
As for ecmh supporting MLDv2; working on it, but the RFC is quite a mess ;)
In the mean time I did improve a lot of features in the normal edition
which should cause it to be more compliant to the standards, it even
correctly lowers ttl now and responds to icmpv6 echo requests, thus
one is able to traceroute6 it, that is when those traceroute tools
would support multicast correctly, mtr for instance hangs on the
first hop as the hoplimit isn't set correctly. A ping6 -t 1, -t 2 etc
does work though. UDP Multicast traceroutes won't work ofcourse.
But I'll make ecmh mtrace6 compliant as then it will work.
IPv6 Multicast Streaming
FYI from the Linux 2.6.3 tree:
linux-2.6.3/net/ipv6/mcast.c
8<-------------------------------
int igmp6_event_query(struct sk_buff *skb)
...
if (len == 24) {
int switchback;
/* MLDv1 router present */
...
} else if (len >= 28) {
max_delay = (MLDV2_MRC(ntohs(mlh2->mrc))*HZ)/1000;
if (!max_delay)
...
------------------------------->8
Aka, according to this snippet it should nicely fall back to MLDv1.
But.... MLDv2 in ecmh is almost working ;)
|
![[ch]](/s/countries/ch.gif)
on Sunday, 11 January 2004 03:39:09
Posting is only allowed when you are