IGMPv2 on the WAN side

[daniel...@gmail.com]

Hi,

I see that although mcproxy supports IGMPv2 clients, it always sends IGMPv3 in the WAN (upstream) side. My situation is as follow:

The IPTV client only supports IGMPv2, is on the downstream side.

The IPTV server only supports IGMPv2, is on the upstream side.

The router, that has mcproxy, understands the IGMPv2 messages from the client, but it sends IGMPv3 to the upstream side, which the IPTV server doesn't understand.

I tried to change the configuration to be << protocol IGMPv2; >> but it still sends IGMPv3 messages.

I was thinking to find any advantage by using v1.0.5 but I can't because the router doesn't have boost libraries and I don't prefer to install it. The router is using OpenWRT.

Do you have any idea? Should I "just" change the config or do I need to change the code? Thank you.

-daniel-

[Sebastian Wölke]

Hello and sorry for the late answer,

Mcproxy uses the socket functions of the operation system to send join and leave messages to the upstream.
In other word, you have to tell the operation system, which IGMP version it has to use for the upstream interface (force_igmp_version=2).
Howto: https://wiki.openwrt.org/doc/howto/udp_multicast#force_igmp_version

Regards,
Sebastian

[daniel...@gmail.com]

Hi Sebastian,

Thank you for the answer. I think that is a good idea. The router now sends IGMPv2 to the WAN side. 

However, the General Query message in the LAN side is still in IGMPv3. I think when the router sends this message again, the client won't understand and reply. As a result, the router will stop forwarding the multicast packets from the WAN side to the LAN side. Furthermore, forcing the kernel to use IGMPv2 disables IGMPv3 clients to take advantages of IGMPv3 features, such as source-specific multicast. 

Now my workaround solutions is to create switch for user to choose either IGMPv1/v2 or IGMPv3. The first option forces the kernel to use IGMPv2 with the corresponding behaviors specified above. The second one enables IGMPv3, but the IPTV server in the WAN side will never respond to the request because it doesn't understand IGMPv3.

- IGMPv1/2 is implemented either by forcing the kernel to use IGMPv2 OR by using igmpproxy. The igmpproxy is now a quicker solution because it already provides full IGMPv2 functionalities.

- IGMPv3 is implemented by switching back the kernel to be able to use IGMPv3 (default mode). if igmpproxy is used to implement IGMPv1/v2, it will be disabled if user choose IGMPv3.

What do you think? Thank you.

-daniel-

[Sebastian Wölke]

Hello Daniel,

Just for the understanding, a Multicast-Proxy operates in the client mode at the upstream side (your WAN side) and in the router mode on the downstream side (your LAN side).
The client mode is for sending join and leave messages, a basic feature provided by most operating system.
The router mode has to be implemented by the Multciast-Proxy and sends Multicast-Queries and maintains the group states of the Multicast-Clients.

IGMPv3 provides a number of compatibility modes (https://tools.ietf.org/html/rfc3376#section-7):
The IGMPv3 Router (provided by Mcproxy) does understand IGMPv2 join/leave messages and switches automatically to an IGMPv2 compatibility mode.
Furthermore, an IGMPv2 client does understand IGMPv3 Multicicast-Queries. In fact, the IGMPv2 client does not fully understand these messages, but the necessary part (for an IGMPv2 client) of the message it does.
On the other side, an IGMPv2 Router does not understand IGMPv3 join/leave messages. (Thats why you have to force the IGMP version of your upstream interface to 2).

This means when you have an IGMPv2 IPTV Server at the upstream side of Mcproxy, you have to force the upstream interface to IGMPv2.
And when you have an IGMPv2 IPTV client on the downstream side of Mcproxy, you do not have to do anything, as the IPTV client understands the IGMPv3 Multicast-Queries and Mcproxy understands the IGMPv2 join/leave messages.

Regards,
Sebastian