How to list joined multicast groups?

Bobi B.

Bobi B.

Is there a utility, or perhaps a netstat(1) command-line switch, to list multicast groups host is joined to and issuing IGMP reports for?

I'm debugging an issue, where, even thou there is no application reading from a multicast address, host is reporting couple of addresses. ffmpeg have been started, recently, to process a multicast signal. However after ffmpeg ends (or is interrupted), IGMP reports for this multicast group remains (verified with tcpdump(1) on both ends -- signal source and this host).

AFAIK, on Linux, multicast groups can be listed with ip maddr; is there FreeBSD equivalent?
 
Well, my problem is this. Before ffmpeg:
Code: 
# ifmcstat -i lagg0.200
lagg0.200:
    inet 192.168.200.80
    igmpv3 rv 2 qi 125 qri 100 uri 3
        group 224.0.0.1 mode exclude
            mcast-macaddr 01:00:5e:00:00:01

While ffmpeg runs and after it finishes and no-longer running:
Code: 
lagg0.200:
    inet 192.168.200.80
    igmpv2
        group 239.0.200.1 mode exclude
            mcast-macaddr 01:00:5e:00:c8:01
        group 224.0.0.1 mode exclude
            mcast-macaddr 01:00:5e:00:00:01
If I read this correctly network interface continues asking for multicast signal for group 239.0.200.1 even if no application needs it. Seems so:
Code: 
# tcpdump -penvi lagg0.200 igmp
tcpdump: listening on lagg0.200, link-type EN10MB (Ethernet), capture size 262144 bytes
14:53:26.026990 XX:XX:XX:XX:XX:XX > 01:00:5e:00:00:01, ethertype IPv4 (0x0800), length 56: (tos 0x10, ttl 1, id 26, offset 0, flags [none], proto IGMP (2), length 28)
    192.168.200.22 > 224.0.0.1: igmp query v2 [max resp time 1]
14:53:26.100276 XX:XX:XX:XX:XX:XX > 01:00:5e:00:c8:01, ethertype IPv4 (0x0800), length 46: (tos 0x0, ttl 1, id 38046, offset 0, flags [none], proto IGMP (2), length 32, options (RA))
    192.168.200.80 > 239.0.200.1: igmp v2 report 239.0.200.1

Any ideas why that is so and how to drop multicast group 239.0.200.1 from this network interface?
 
Last edited by a moderator:
When hosts want to leave a multicast group, they can silently leave, or they can send a leave message. I don't know how ffmpeg works. But you can use mtest to test your multicast routing or if you don't use multicast with ffmpeg you can disabled it using broadcast=0 or setting ttl.

On Cisco the switch is sending periodically a group query to detemrinate if the host is still needs this trafic or not:

IGMP Configurable-Leave Timer

You can configure the time that the switch waits after sending a group-specific query to determine if hosts are still interested in a specific multicast group. The IGMP leave response time can be configured from 100 to 5000 milliseconds. The timer can be set either globally or on a per-VLAN basis. The VLAN configuration of the leave time overrides the global configuration.
Click to expand...
 
Hi Bobi!

I faced the same situation. And I noticed that this problem appeared on FreeBSD 12.x but everything ok when using 11.x. After log search, I found Bug 242677 which describes the degradation of IGMP Leave. The bug is marked as "closed and fixed" but I don't see any positive changes in the fresh 12.x releases.

I may mistake, of course, and I'm not sure that your problem is connected to that bug. But I confirm that the problem still exists.
 
I made a parallel experiment on two machines with 11.3 and 12.1. I tested multicast 234.5.2.157:1234 with ffprobe. At the same time, I was making dumps of IGMP requests. And ffprobe was started with truss which gave a detailed log of system calls.

Here is the result.

1) Let's take a look at setsockopt calls in truss logs:

11.3:
Code: 
setsockopt(3,SOL_SOCKET,SO_NOSIGPIPE,0x7fffffffd92c,4) = 0 (0x0)
setsockopt(3,SOL_SOCKET,SO_REUSEADDR,0x80ecba028,4) = 0 (0x0)
setsockopt(3,IPPROTO_IP,IP_ADD_MEMBERSHIP,0x7fffffffe360,8) = 0 (0x0)
setsockopt(3,SOL_SOCKET,SO_RCVBUF,0x7fffffffe360,4) = 0 (0x0)
setsockopt(3,IPPROTO_IP,IP_DROP_MEMBERSHIP,0x7fffffffe440,8) = 0 (0x0)

12.1:
Code: 
setsockopt(3,SOL_SOCKET,SO_NOSIGPIPE,0x7fffffffd3ac,4) = 0 (0x0)
setsockopt(3,SOL_SOCKET,SO_REUSEADDR,0x8055869e8,4) = 0 (0x0)
setsockopt(3,IPPROTO_IP,IP_ADD_MEMBERSHIP,0x7fffffffdde0,8) = 0 (0x0)
setsockopt(3,SOL_SOCKET,SO_RCVBUF,0x7fffffffdde0,4) = 0 (0x0)
setsockopt(3,IPPROTO_IP,IP_DROP_MEMBERSHIP,0x7fffffffe290,8) = 0 (0x0)

We see that ffprobe has sent IGMP Leave in both cases.

2) What about real IGMP queries?

11.3:
Code: 
14:42:39.191842 IP 192.168.171.66 > 234.5.2.157: igmp v2 report 234.5.2.157
14:42:43.428794 IP 192.168.171.66 > all-routers.mcast.net: igmp leave 234.5.2.157

12.1:
Code: 
14:42:25.372999 IP 192.168.71.100 > 234.5.2.157: igmp v2 report 234.5.2.157
14:42:47.548742 IP 192.168.71.100 > 234.5.2.157: igmp v2 report 234.5.2.157

We see that there were no IGMP Leave query on 12.1.

What am I doing wrong?..
 
I found the problem. Here is the PR 248512 which is a duplicate of the PR 246629. I made a comparative testing:
  • 12.1-RELEASE
  • snapshot r364392 (which was the freshest on the other day)
IGMP Leave doesn't work on the release and does work on the snapshot.
Now we just have to wait...
 
You must log in or register to reply here.
Back
Top