Multicast: Difference between revisions

From AAISP Support Site
No edit summary
 
(9 intermediate revisions by 3 users not shown)
Line 1: Line 1:

= FTTC =
= 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.
<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 ==
== Example for Debian GNU/Linux ==


Have extracted some paramaters from pppd, this may not work correctly if there is more than one instance.
Have extracted some parameters 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`
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:
As a workaround to IPv4 not customarily allowing ifindex or interface name specification in addresses, (known as scope or "%", in IPv6) route to the multicast group on the device upon which PPPoE runs, aimed at the openreach modem:


echo ip route add 234.81.130.4 dev $DEVICE
echo ip route add 234.81.131.194 dev $DEVICE


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


ffplay rtp://234.81.130.4:5802
ffplay rtp://234.81.131.194:5802


or:
or:
vlc rtp://234.81.130.4:5802
vlc rtp://234.81.131.194:5802


=== 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 [http://troglobit.github.io/smcroute 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.
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. [http://troglobit.github.io/smcroute smcroute] lets one forward multicast statically at first and can even work where programs do not understand IGMP or in some situations even multicast, which can be aided with DNAT rules and/or use of -j REDIRECT on targets


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.
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:


Other software that may be useful is [https://manpages.debian.org/stable/igmpproxy igmpproxy] and [https://unfix.org/projects/ecmh/ ecmh]
ifconfig $DEVICE $IPLOCAL


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:
To actually start:


smcroute -j $DEVICE 234.81.130.4
smcroutectl add $DEVICE 109.159.247.194 234.81.131.194 <var>int0 ext0</var>
smcroutectl add $DEVICE 109.159.247.200 234.81.131.200 <var>int0 ext0</var>
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:
and stop:


smcroute -l $DEVICE 234.81.130.4
smcroutectl leave $DEVICE 234.81.131.194


see for forwarding statistics:
see for forwarding statistics:
Line 45: Line 50:
cat /proc/net/ip_mr_cache && ip mroute show
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 not specify an interface for IGMP, use <code>ip route add 234.81.130.4</code> on these devices with a device aiming towards the PPPoE host system.
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 allow specification of an interface for IGMP, which is more usual with ipv6, a workaround is <code>ip route add 234.81.131.194/32</code> on these devices with a device aiming towards the PPPoE host system.




== Example Notes ==
== Example Notes ==


This had been tested on several linux bridges for [http://ebtables.netfilter.org/examples/basic.html#ex_nobridge 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.
This had been tested on several linux bridges for [http://ebtables.netfilter.org/examples/basic.html#ex_nobridge 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.

= Further Reading =

* [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


[[Category:3rd Party Routers]]

Latest revision as of 23:56, 29 August 2022

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. This is updated as of 2022

Example for Debian GNU/Linux

Have extracted some parameters 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`

As a workaround to IPv4 not customarily allowing ifindex or interface name specification in addresses, (known as scope or "%", in IPv6) route to the multicast group on the device upon which PPPoE runs, aimed at the openreach modem:

echo ip route add 234.81.131.194 dev $DEVICE

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

ffplay rtp://234.81.131.194:5802

or:

vlc rtp://234.81.131.194: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. smcroute lets one forward multicast statically at first and can even work where programs do not understand IGMP or in some situations even multicast, which can be aided with DNAT rules and/or use of -j REDIRECT on targets

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 igmpproxy and 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.

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 requires the source address, this was found with wireshark or tcpdump, 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:

smcroutectl add $DEVICE 109.159.247.194 234.81.131.194 int0 ext0
smcroutectl add $DEVICE 109.159.247.200 234.81.131.200 int0 ext0
smcroutectl add $DEVICE 109.159.247.216 234.81.132.216 int0 ext0

To actually start, substituting for the other addresses beginning 234. above for the other channels.

smcroutectl join $DEVICE 234.81.131.194

and stop:

smcroutectl leave $DEVICE 234.81.131.194

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 allow specification of an interface for IGMP, which is more usual with ipv6, a workaround is ip route add 234.81.131.194/32 on these devices with a device aiming towards the PPPoE host system.

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.

Further Reading

  • BT and openreach supplier information notes, especially BT 511 and openreach 503