# How to list joined multicast groups?



## Bobi B. (Mar 27, 2020)

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?


----------



## VladiBG (Mar 27, 2020)

maybe ifmcstat will help





						ifmcstat(8)
					






					www.freebsd.org
				








						igmp
					






					www.freebsd.org


----------



## Bobi B. (Mar 27, 2020)

Well, my problem is this. Before `ffmpeg`:

```
# 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:

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

```
# 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?


----------



## VladiBG (Mar 27, 2020)

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.


----------



## Aquitanis (Sep 1, 2020)

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.


----------



## Bobi B. (Sep 1, 2020)

Not sure if PR 242677 is the same issue, as multicast address disappears from ifmcstat(8) in their case, whereas it remains on my end (12.1-RELEASE-p7).


----------



## Aquitanis (Sep 2, 2020)

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

```
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:*

```
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:*

```
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:*

```
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?..


----------



## VladiBG (Sep 2, 2020)

Bug Reports


----------



## Aquitanis (Sep 7, 2020)

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


----------

