IGMP proxy not releasing multicast streams after upgrading to 24.7

[jorisvervuurt]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/src/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/src/issues?q=is%3Aissue

Describe the bug

I have created this issue by request of franco on the forum:
https://forum.opnsense.org/index.php?topic=41719.0

I live in The Netherlands and use an OPNsense router as a replacement for the ISP (KPN) modem/router.
We also have two TVs; these STBs use multicast (IGMP) so I use os-igmp-proxy to get this to work.

According to the traffic graph, each stream uses around 14.4 Mbps of bandwidth. On 24.1, switching TV channels resulted in a short increase in traffic (28.8 Mbps) which would very quickly drop down back to 14.4 Mbps. I believe this is how IGMP works due to a subscriber unsubscribing.

After upgrading to 24.7 this does not happen anymore... the traffic graph keeps showing an increase in traffic after each TV channel switch but also does not come down anymore. Eventually (after 5-10 minutes it seems) it does come down (in 14.4 Mbps steps), but it's no more instant like it was on 24.1 and causes the STB to freeze once the traffic gets too much.

These errors were in the logs:

igmpproxy	MRT_DEL_MFC; Errno(49): Can't assign requested address
igmpproxy	select() failure; Errno(4): Interrupted system call

Searching for this error results in some older topics, also after an OPNsense update:

https://forum.opnsense.org/index.php?topic=18347.0
and
https://forum.opnsense.org/index.php?topic=18490.msg84154#msg84154

Looking back at the posts from 2020, this change that seemed to have fixed it back then (not sure if there's more changes from that thread that are relevant though):
https://forum.opnsense.org/index.php?topic=18490.msg84346#msg84346

Perhaps comparing these files might lead to the solution (I'm not familiar enough with C to understand the code), but of course it could also be something else:

IPv4:
https://github.com/opnsense/src/blob/stable/24.1/sys/netinet/in_mcast.c
https://github.com/opnsense/src/blob/stable/24.7/sys/netinet/in_mcast.c

IPv6:
https://github.com/opnsense/src/blob/stable/24.1/sys/netinet6/in6_mcast.c
https://github.com/opnsense/src/blob/stable/24.7/sys/netinet6/in6_mcast.c

To Reproduce

A bit hard to explain step by step, but basically it happens when switching TV channels. This starts a new IGMP multicast stream (I use os-igmp-proxy). Each channel switch results in 14.4 Mbps being added.

Expected behavior

When switching TV channels, the multicast stream for which the STB send an unsubscribe request should be closed by OPNsense.
The used bandwidth should only very shortly increase but quickly reduce again.

Describe alternatives you considered

Tried a few test kernels from franco on the forum, unfortunately these did not fix the issue:
https://forum.opnsense.org/index.php?topic=41719.0

Environment

My ISP is KPN and I am using their TV+ STBs which work over multicast (IGMP).
The problem did not exist in 24.1.10_8. I have not changed anything configuration-wise. The STBs are on a VLAN and both are connected directly to my OPNsense box through a bridge (this is fine performance wise).

Software version used and hardware type if relevant, e.g.:

OPNsense 24.1.10_8 and 24.7_5 (amd64)
Intel® N100 Quad Core
Network Intel® i226
os-igmp-proxy version 1.5_2

[jorisvervuurt]

Unfortunately I have just discovered another related issue.
After a day of OPNsense running and the TV being used occasionally, somehow TV channels start stuttering after a few seconds (even if the traffic graph does not show abnormal things). I have checked the logs but didn’t see anything related to this.

Restarting the IGMP proxy service seems to have fixed the stuttering… probably related to all the streams that haven’t been released?

I think the main issue is that unsubscribe requests aren’t handled correctly. That’s just a multicast thing. IGMP proxy probably doesn’t handle that properly causing the stuttering (which explains why restarting the service fixes the stuttering).

I think this issue will be fixed as well if the streams are correctly released after the unsubscribe request.

[fichtner]

New test kernel:

# opnsense-update -zkr 24.7_9

[jorisvervuurt]

Woohoo, that one seems to have fixed the problem! I'll keep monitoring if there are other issues, but for now everything seems to be working as it was with 24.1. I don't see any IGMP proxy errors in the logs anymore either. :)

Thanks so much!

[fichtner]

Thanks for confirming. 8)

Here is the timeline...

1. Bad fix introduced to FreeBSD main 31.08.23 https://cgit.freebsd.org/src/commit/?id=fa03d37432
2. Bad fix cherry-picked to FreeBSD stable/14 branch 07.09.23 https://cgit.freebsd.org/src/commit/?id=70fbe797c0
3. FreeBSD 14.0 released based on broken releng/14.0 (from stable/14) state 20.11.23
4. Bad fix removed from FreeBSD main 14.12.23 https://cgit.freebsd.org/src/commit/?id=c196e43243b8
5. Proper fix introduced to FreeBSD main 14.12.23 https://cgit.freebsd.org/src/commit/?id=c2e340452c1
6. FreeBSD 14.1 released based on broken releng/14.0 (from stable/14) state 04.06.24

I've added these two commits for 24.7.1 (which are in 24.7_9 as tested):

48570316
e81800f6a

Cheers,
Franco