48
edits
Multicast: Difference between revisions
m
→Relaying the stream
mNo edit summary |
|||
| (7 intermediate revisions by 2 users not shown) | |||
|
= FTTC =
<strong>Unofficially and completely at own risk</strong>, it has been found to be possible to watch the [https://community.bt.com/t5/YouView-Boxes/IPC6023-Advanced-Diagnosis/td-p/1154880 Test Channel] as described on the BT website, on an AAISP provided FTTC line. This is [https://community.bt.com/t5/YouView-from-BT/Multicast-Test-Channel-URL/td-p/2223426 updated as of 2022]
== Example for Debian GNU/Linux ==
Have extracted some
eval `tdbdump /var/run/pppd2.tdb | grep CALL_FILE | cut -d'"' -f2`
echo ip route add 234.81.
Play stream.
Caveats : It starts when the network receives an IGMP join and stops with IGMP leave.
ffplay rtp://234.81.
or:
vlc rtp://234.81.
=== 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.
It may be possible later to have other programs listen for IGMP/MLD and then "manage" smcroute, due to a possible linux limitation of only allowing one userspace program manage kernel mrouting at a time, to have maximum flexibility in upstreams and downstreams including internal sources.
Other software that may be useful is [https://manpages.debian.org/stable/igmpproxy igmpproxy] and [https://unfix.org/projects/ecmh/ ecmh]
For testing and usage, smcroute can reflect the multicast to other attached networks. The smcroute 2.4.4 as found in Debian 11, would not configure the interface without an IP address on it, however the very latest smcroute allows 0.0.0.0 to be used to originate the IGMP3 joins, this needed the upgrade from ip_mreq to ip_mreqn in the smcroute code.
smcroute requires the source address, this was found with wireshark and could be subject to change, <var>int0</var> and <var>ext0</var> are example devices to copy multicast packets to, these could be internal vlans on a home network:▼
Additionally the sysctl rp_filter is disabled on $DEVICE and "all" to allow the incoming multicast without a matching outgoing route, also desirable. iptables and/or nftables would still be used to filter.
smcroute -a $DEVICE <var>109.159.247.1</var> 234.81.130.4 <var>int0 ext0</var>▼
▲smcroute requires the source address, this was found with wireshark or tcpdump, and could be subject to change, <var>int0</var> and <var>ext0</var> are example devices to copy multicast packets to, these could be internal vlans on a home network:
▲
smcroutectl add $DEVICE 109.159.247.216 234.81.132.216 <var>int0 ext0</var>
To actually start, substituting for the other addresses beginning 234. above for the other channels.
smcroutectl join $DEVICE 234.81.131.194
and stop:
see for forwarding statistics:
cat /proc/net/ip_mr_cache && ip mroute show
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
== Example Notes ==
* [http://ideas.aa.net.uk/?ia=7937 Votes on the idea]
* [http://www.revk.uk/2012/11/multicast.html AAISP Director on Multicast]
* [https://www.bt.com/about/sinet BT] and [https://www.openreach.co.uk/cpportal/help/suppliers-information-notes-(sins) openreach] supplier information notes, especially BT 511 and openreach 503
| |||