[SOLVED] IGMP proxy not releasing streams after upgrading to 24.7

[jorisvervuurt]

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.

What could be causing this? 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).

[jorisvervuurt]

Just noticed these errors in the logs:

Code: [Select]

igmpproxy MRT_DEL_MFC; Errno(49): Can't assign requested address

Code: [Select]

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

Hopefully this can be fixed soon, because this is flooding the STB causing it to freeze.

Thanks!

[DutchCrownNL]

Same issue for me, also with KPN as ISP.
It seems that the streams are beeing dropped after a while (4 mins orso), but if you change channels quickly the bandwith increases very quickly.

IGMP Proxy version is the same as before, and re-installing the proxy doesn't fix the issue.

[jorisvervuurt]

Same issue for me, also with KPN as ISP.
It seems that the streams are beeing dropped after a while (4 mins orso), but if you change channels quickly the bandwith increases very quickly.

IGMP Proxy version is the same as before, and re-installing the proxy doesn't fix the issue.

Yep, it seems to be a kernel issue (that's where they fixed it before if I read correctly). The problem lies with the multicast group unsubscribe failing. The streams are eventually dropped by KPN; I've noticed the streams staying up even after rebooting OPNsense.

I just hope the amazing folks at Deciso can solve it because otherwise I'm afraid I'm going to have to downgrade to 24.1 (the people I live with are complaining haha).

[franco]

Any idea which patch could be missing? stable/14 may be incomplete or regressed a bit oO

[franco]

Well I see two larger changes from 2023 done for FreeBSD 14. Maybe this is groundhog day all over?

Will look at it closer next week. Tickets on GitHub welcome...easier to follow up.


Cheers,
Franco

[franco]

And yes there are some fixes on FreeBSD main that have no backport. This is great (stable) stuff.

[franco]

Can you install this kernel and reboot?

# opnsense-update -zkr 24.7_2

Better or same?


Cheers,
Franco

[jorisvervuurt]

Thanks for the replies @franco!
I will try the new kernel in about half an hour and will report back.

[DutchCrownNL]

Can you install this kernel and reboot?

# opnsense-update -zkr 24.7_2

Better or same?


Cheers,
Franco

Will try this later tonight aswell and report back.

[jorisvervuurt]

Can you install this kernel and reboot?

# opnsense-update -zkr 24.7_2

Better or same?


Cheers,
Franco

Just tried this one; unfortunately the problem remains the same so I have switched back to the current kernel using `opnsense-update -k`.

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

As for GitHub issues: I'd be more than happy to create an issue there, but in which repo should I create the issue?

[franco]

I checked the old stuff but the commit in question is still there. Let's try to revert one of the possible breaking candidates instead:

# opnsense-update -zkr 24.7_1

The bug report should go to opnsense/src.


Cheers,
Franco

[jorisvervuurt]

I checked the old stuff but the commit in question is still there. Let's try to revert one of the possible breaking candidates instead:

# opnsense-update -zkr 24.7_1

The bug report should go to opnsense/src.


Cheers,
Franco

Thanks very much for the effort, but unfortunately this one doesn't fix the issue either (is it correct that the version naming is lower compared to the previous kernel test version?).

I have just created the GitHub issue:
https://github.com/opnsense/src/issues/210

Thanks again and have a nice weekend!

[franco]

Yes I did not push the two backports to GitHub because they were useless so the revert was just one commit after 24.7 tag. Ok, so that's not either. I'm willing to roll back one more commit but if that's not it I'm unsure what it actually is.


Cheers,
Franco

[franco]

# opnsene-update -zkr 24.7_5

Last one for triage, then we should continue structurally in the ticket.


Thanks,
Franco