Enter Persistent CARP Maintenance Mode not working since 24.7

[USBAkimbo]

Important notices

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

• [x] I have read the contributing guide lines at https://github.com/opnsense/src/blob/master/CONTRIBUTING.md
• [x] 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

A clear and concise description of what the bug is, including last known working version (if any).

• I have a setup of 2 OPNsense VMs running on 2 separate Proxmox nodes
• Each node is configured for CARP HA
• I have a script made by the OPNsense community that handles the WAN side on failover which lives at /usr/local/etc/rc.syshook.d/carp/50-dhcp
• The script itself can be found here
• This setup works, but since the 24.7 update I am unable to press Enter Persistent CARP Maintenance Mode to force failover from the primary to the secodary
• I press it, then it sets Current CARP demotion level to 240 but the CARP status doesn't change to BACKUP and the secondary doesn't become MASTER
• I'm not sure what's changed that causes this, but I can press Temporarily Disable CARP and that will force the failover, but it's not as gentle

To Reproduce

• Follow the steps from the docs to configure CARP on each interface on both firewalls
• Install the script to the path I linked above
• Press Enter Persistent CARP Maintenance Mode

Expected behavior

• The primary demotes to BACKUP and the secondary becomes MASTER

Describe alternatives you considered

• Disabling CARP entirely on the primary, but that isn't as gentle and won't tolerate the secondary failing
• I have looked on the primary and it says Current CARP demotion level 0 and the secondary says Current CARP demotion level 240

Screenshots

• Primary
• Secondary

Environment

• 2x Proxmox VMs - 2 vCPUs, 4GB RAM, 30GB SSD

[bitcoredotorg]

I can confirm that I also experience this problem on 24.7, even without the carp rc.syshook.d scripts installed at all. They seem to have no effect on if it works or not.

Entering persistent maintenance mode does make the demotion level to 240, but a failover never occurs.

Primary: advbase:1 advskew:0

Secondary: advbase:1 advskew:100

[USBAkimbo]

Following up on this, I was able to reset the demotion level on both nodes to 0 which seems to have fixed it

That said, I don't know how it ended up in this place to begin with

I was able to reset the demotion level using the power of Google to find the right commands to reset it