Cannot receive multicast¶

How to receive multicast¶

You can check the ability to receive a multicast stream on your computer by the following ways:

Try to start the probe and configure a task to analyze a desired multicast stream.
Try to play the stream using a network player (for example, VLC player). If the stream is successfully played, that means you can receive a stream at your PC, and it can also be received by the Boro probe. If the stream is not played, it does not necessarily mean that you are not receiving the multicast streaming. Probably, your routing table has wrong settings. In order to avoid routing rules, Boro uses a direct assignment of network interface. Please, fill in the field “Network interface IP” correctly and check if the Boro probe is receiving data. In case “Network interface IP” field is empty, the probe will receive data according to the routing table.
Try to dump the stream using a socat utility. Please refer to the section Creating dump of multicast stream to find out more details about a socat utility and to see an example of a command. If dump is successfully created, it means that you are receiving the stream. In case a dump file is created but nothing is recorded in this file (file size is equal to 0), it means that you are not receiving the specified stream in your user space for some reasons. Since the direct assignment of a network interface is used in socat, a routing table does not affect on receiving the stream.

If other programs (e.g. VLC player) can receive multicast, refer to Computer receives multicast but probe does not see stream.

If no software is capable of receiving the stream, additional research and adjustments are required, see Computer does not receive multicast.

Computer receives multicast but probe does not see stream¶

If your PC is receiving the specified multicast stream, the problem may relate to the probe’s settings:

The most popular problem is incorrect task assignment to the probe, which means that the multicast group was incorrectly specified.

The example of the correct URI: udp://235.0.0.5:123.

The examples of the incorrect address: udp://235.0.0:5:1234 or udp://235.0.0.0.5:1234.

That it is quite difficult to find such a mistake at the first sight, so be careful while entering the URI address.
The second most typical mistake is incorrect choice of the network interface IP. Please check if the IP address is specified correctly. As a next step, make sure that your interface is still present in the system, and the desired NIC is used for receiving multicast. Network cards’ IP, virtual interfaces’ IP and 127.0.0.1 address (aka localhost) can be also used as the address. If the address is not specified, the streams will be received according to the routing table.

This mistake often occurs while manual copying the probes’ configuration files from one PC to another. We recommend using a helpful tool for Saving/Applying Configuration which is available at the Probe page on the server.
If during the probe operation, the user has changed network settings (e.g., got a new IP address or created a VLAN), the probe restart can solve the issue of multicast receiving.

Computer does not receive multicast¶

Checking for multicast traffic¶

To check whether your PC is capable of receiving multicast streaming, it is necessary to use capturing packets. This allows to avoid the influence of system filters and firewalls on the multicast receiving. You need to follow two steps:

Establish multicast group membership;
Explore traffic on a required network interface.

Linux

You may add multicast group membership using this command:

socat -u UDP4-RECV:7777,ip-add-membership=<MULTICAST_IP>:<NIC_IP>,reuseaddr CREATE:/dev/null

The following methods can be used in order to check traffic. The methods relate to a packet capture (bypassing all possible system filters). Moreover, you may use a Promiscuous mode — a mode which enables a NIC to pass all traffic it receives to the CPU rather than passing only the frames that the controller is intended to receive:

The iftop utility in a promiscuous mode (see Manual):
```
iftop -p -i <INTERFACE_NAME> -F <MULTICAST_IP>/32
```
A line with the specified multicast group should appear in the table.
The tcpdump utility (see Manual):
```
tcpdump -i <INTERFACE_NAME> dst <MULTICAST_IP> and udp dst port <MULTICAST_PORT>
```
A list of received packets should be displayed (within 10-20 sec) at the specified MULTICAST IP.

Windows

You may establish multicast group membership by playing the stream in VLC player or starting to dump a stream using a socat utility.

It is recommended to use the following utilities in order to capture traffic:

The WinDump utility (see Manual). It requires installation of the WinPcap or NPcap driver. The command is identical to the one described for Linux OS:
```
WinDump.exe -i <INTERFACE_INDEX> dst <MULTICAST_IP> and udp dst port <MULTICAST_PORT>
```
The only difference is specification of the adapter’s name. For Windows it is necessary to use indexes which can be got using a command:
```
WinDump.exe -D
```
The WireShark program (You can download the program and read Manual at the official Wireshark website). Traffic can be filtered according to the rule: dst <MULTICAST_IP> and udp dst port <MULTICAST_PORT>.

In case you do not receive a traffic, the cause may be due to the problems with the source of multicast streaming, network equipment or malfunction of IGMP joining. The further study of such problems goes beyond the current guide.

If your PC is capable of receiving traffic, most probably traffic is filtered and hence cannot reach user space. Below, you may find a list of possible reasons why traffic might be filtered.

Checking the Firewall¶

Linux — CentOS

In order to make sure the problem is caused by firewall, you may temporarily switch it off:
systemctl stop firewalld
Instead of switching off a firewall, one of the following solutions can be applied in CentOS 7/8:
Add permissions for all incoming IGMP and multicast UDP packets for all interfaces:
firewall-cmd --permanent --add-rich-rule="rule family=ipv4 destination address=224.0.0.0/4 protocol value=udp accept"
firewall-cmd --permanent --add-rich-rule="rule family=ipv4 protocol value=igmp accept"
firewall-cmd --reload
Move interface to a trusted zone (using FirewallD in CentOS terms):
firewall-cmd --zone=trusted --change-interface=<INTERFACE_NAME>

Linux — Ubuntu

In order to make sure the problem is caused by firewall you may temporarily switch it off:
ufw disable
Instead of switching off a firewall, you can add persistent permissions for all incoming IGMP and multicast UDP packets for all interfaces:
ufw allow proto udp to 224.0.0.0/4
ufw allow proto igmp to any

Windows

Sometimes, Windows firewall may forbid the access to multicast streaming. In that case you should allow streamMonitor.exe using private and public networks (set “private” and “public” checkboxes in Windows firewall).

Note

Configuration methods applicable to firewall settings vary in different versions of Windows OS, use a “Search” option in your browser.

Reverse Path Filtering¶

Linux

Reverse Path Filtering — is a mechanism checking whether a receiving packet source address is routable (more information). To determine whether the filter affects the certain interface <IFACE>, switch off the filter using following commands:
echo 0 >/proc/sys/net/ipv4/conf/<IFACE>/rp_filter
echo 0 >/proc/sys/net/ipv4/conf/all/rp_filter
After switching off the filter, check if the probe starts receiving the data. In some cases, the probe restart is required. If the probe starts receiving data and the filter’s influence is identified, we recommend to permanently switch off the filter by editing sysctl.conf (<IFACE> should be replaced with the interface name) as follows:
cat >>/etc/sysctl.conf <<EOF
# disable RP filter:
net.ipv4.conf.<IFACE>.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
EOF
Thus, after editing the config file and restarting the OS, the RPF filter will remain inactive for the target interface.

Root Privileges¶

Linux

Using port less than 1024 on Linux requires root privileges. Such ports are regarded as system in many OS. Correspondingly, probe is not able to receive data (will fail to bind to a port). The similar log will be shown in a console, when running the probe as a non-root user:
09:08:28 source_udp_start()[258]: Creating UDP/RTP receiver for 224.1.5.172:1001 (bind iface 172.16.67.10)
09:08:28 small_rtp_init_receiver()[254]: ERROR: bind failed, err 0xD
09:08:28 small_rtp_init2()[414]: ERROR: small_rtp_init_receiver: failed
09:08:28 source_udp_start()[279]: ERROR: small_rtp_init failed with code -1
There is only one simple solution of this problem – you should start the probe as root:
sudo ./streamMonitor

Version of IGMP Protocol¶

Linux

Outdated network equipment may not support the latest version of the IGMP protocol. To check current version of IGMP and IP addresses subscribed for multicasting, see the /proc/net/igmp file:
cat /proc/net/igmp
You may set IGMP protocol version on Linux using a following command:
echo 2 > /proc/sys/net/ipv4/conf/<IFACE>/force_igmp_version

Creating Dump of Multicast Stream¶

The easiest way to dump (save to .ts file) the multicast stream is to use a socat utility. More information in the Manual.

Linux

The example of the command:

MULTICAST=235.0.0.1:1234
INTERFACE=10.10.30.229 # name, ip or id of network interface
socat -u \
    UDP4-RECV:${MULTICAST#*:},ip-add-membership=${MULTICAST%:*}:$INTERFACE,bind=${MULTICAST%:*},reuseaddr \
    CREATE:dump_$(tr ':' '_' <<<"$MULTICAST").$(date +'%F_%H.%M').ts

The stream will be saved to a file with a specified data and name until a utility is stopped.

Windows

At the moment of writing this paper, socat version 2.0.0 (beta 5) has been tested on Windows 8.1. You may download a socat build for Windows at the download page.

The example of the command:
socat -u UDP4-RECV:<PORT>,ip-add-membership=<MULTICAST_IP>:<NIC_IP>,reuseaddr CREATE:dump_name.ts
The stream will be saved to a file with a specified name until a utility is stopped.