Hi,
I upgraded last night to the latest version 25.7.10
It errored out in the middle of the first upgrade and told me to repeat the process which seemed to complete successfully.
However ever since I have the error
2025-12-22T21:52:35
Warning
igmpproxy
MRT_DEL_MFC; Errno(49): Can't assign requested address
As everyone will be aware IGMP Proxy is essential for correct functioning of multicast sat. signals on the local network and IPTV, and since the upgrade these are now broken on my local network.
Is anyone else experiencing this after the latest upgrade ?
Seems when this has happened previously its not a straightforward fix and can take considerable time for a solution to be rolled out. Really bad timing two days before Xmas.
Stephen
I believe I have a temporary workaround by directing all my network traffic through a dumb switch. Should hopefully get me through Xmas. A bit early to tell if this is a robust solution.
The underlying issue remains though.
Have a look at the "snapshots" feature (a.k.a ZFS boot environments) for future upgrades:
https://docs.opnsense.org/manual/snapshots.html
https://www.youtube.com/watch?v=Z1OX0CKU__U
It doesn't fix broken plugins but it sure can spare a ruined holiday.
Also use IGMP Proxy here. No issues with the upgrade and IGMP is working as it should. I have a standard configuration for KPN (NLD ISP) IPTV.
Upstream is configured for the IPTV platform
213.75.0.0/16, 217.166.0.0/16, 195.121.0.0/1
Downstream has my IPTV LAN VLAN 192.168.40.0/24
My IGMP Proxy is definitely throwing errors and the behaviour of my network is entirely in keeping with what you would expect from IGMP failure.
I wonder if the error i saw when performing the upgrade is the cause.
Is it possible to rerun the upgrade over the top of the existing upgrade (ie 25.10.7 over 25.10.7) to eliminate this as the possible root cause.
Quote from: Shoog on December 23, 2025, 12:04:20 PMMy IGMP Proxy is definitely throwing errors and the behaviour of my network is entirely in keeping with what you would expect from IGMP failure.
I wonder if the error i saw when performing the upgrade is the cause.
Is it possible to rerun the upgrade over the top of the existing upgrade (ie 25.10.7 over 25.10.7) to eliminate this as the possible root cause.
Maybe it is a better idea to uninstall the IGMP Proxy plugin first, reboot the system, reinstall the IGMP Proxy plugin and configure it from scratch. Reinstalling the plugin will trigger the system to register everything (whatever it requires) again from scratch. Maybe there is a corrupt file or something. If that doesn't do the trick, you may need a reinstall. Dunno if you can reinstall the upgrade the way you describe.
Quote from: Rene78 on December 23, 2025, 05:12:08 PMQuote from: Shoog on December 23, 2025, 12:04:20 PMMy IGMP Proxy is definitely throwing errors and the behaviour of my network is entirely in keeping with what you would expect from IGMP failure.
I wonder if the error i saw when performing the upgrade is the cause.
Is it possible to rerun the upgrade over the top of the existing upgrade (ie 25.10.7 over 25.10.7) to eliminate this as the possible root cause.
Maybe it is a better idea to uninstall the IGMP Proxy plugin first, reboot the system, reinstall the IGMP Proxy plugin and configure it from scratch. Reinstalling the plugin will trigger the system to register everything (whatever it requires) again from scratch. Maybe there is a corrupt file or something. If that doesn't do the trick, you may need a reinstall. Dunno if you can reinstall the upgrade the way you describe.
Will give reinstalling IGMP Proxy a go and see if it helps.
Reinstalling IGMPproxy didn't help.
I have just reverted the kernel back to 25.7.8 and initial indications are that this may have solved it. Sort of points to a regression in kernel 25.7.10
On ixl cards? Intel probably just broke it again after I had to advocate for a revert when the first commit came in.
https://github.com/opnsense/src/commit/aa1fce8528200
Good luck with that.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283820
Cheers,
Franco
Sounds like setting the allmulti or promisc flag on the interface can fix this?
Just try setting the Promiscuous mode in the interface settings (e.g., Interfaces -> LAN... etc), that will force all multicast groups to be accepted if there is no bigger bug.