Multicast: Difference between revisions

From AAISP Support Site
(multicast draft)
 
No edit summary
Line 23: Line 23:
=== Relaying the stream ===
=== Relaying the stream ===


It may happen that the computer hosting PPPoE is in an inconvenient location for watching and that other networked devices should receive copies of the stream. For real use an IGMP proxy would be used but for first testing smcroute lets one try multicast even if clients don't send IGMP join correctly, but this also means the stream has to be manually started and stopped.
It may happen that the computer hosting PPPoE is in an inconvenient location for watching and that other networked devices should receive copies of the stream. For real use an IGMP proxy would be used but for first testing smcroute lets one try multicast even where clients don't send IGMP join and leave correctly, but this also means the stream has to be manually started and stopped.


For testing, using smcroute we can reflect the multicast to other attached networks. SMCroute does not configure the interface without a legacy IP, so can copy WAN address:
For testing, using smcroute we can reflect the multicast to other attached networks. SMCroute does not configure the interface without a legacy IP, so can copy WAN address:

Revision as of 00:07, 14 July 2015

FTTC

Unofficially and completely at own risk, it has been found to be possible to watch the Test Channel as described on the BT website, on an AAISP provided FTTC line.

Example for Debian GNU/Linux

Have extracted some paramaters from pppd, this may not work correctly if there is more than one instance.

eval `tdbdump /var/run/pppd2.tdb | grep CALL_FILE | cut -d'"' -f2`

Add a route to the multicast group on the device upon which PPPoE runs, aimed at the openreach modem. Also found to work without legacy unicast IP by adding a route:

echo ip route add 234.81.130.4 dev $DEVICE

Play stream. Caveats : It starts when the network receives an IGMP join and stops with IGMP leave.

ffplay rtp://234.81.130.4:5802

or:

vlc rtp://234.81.130.4:5802

Relaying the stream

It may happen that the computer hosting PPPoE is in an inconvenient location for watching and that other networked devices should receive copies of the stream. For real use an IGMP proxy would be used but for first testing smcroute lets one try multicast even where clients don't send IGMP join and leave correctly, but this also means the stream has to be manually started and stopped.

For testing, using smcroute we can reflect the multicast to other attached networks. SMCroute does not configure the interface without a legacy IP, so can copy WAN address:

ifconfig $DEVICE $IPLOCAL

smcroute requires the source address, this was found with wireshark and could be subject to change, int0 and ext0 are example devices to copy multicast packets to, these could be internal vlans on a home network:

smcroute -a $DEVICE 109.159.247.1 234.81.130.4 int0 ext0

To actually start:

smcroute -j $DEVICE 234.81.130.4

and stop:

smcroute -l $DEVICE 234.81.130.4

now ffmpeg, vlc or other client can be ran elsewhere on the internal network, if their ethernet interfaces do not have legacy ip addresses and the client does not specify an interface, use the ip route

Example Notes

This had been tested on several linux bridges for ebtables purposes, each on 802.1q vlan tags, on a managed ethernet switch where the other untagged port for PPPoE is connected to the openreach modem.