pfSense

Hmm, yeah, that could be fallout from the unicast carp work. In unicast mode we use the interface Mac as source (mostly so AWS doesn't drop the packet). That shouldn't be the case in multicast mode though, so I'm not quite sure what's going on here.
The check in carp_output() looks correct. I'll debug when I'm back.

Hi Jim, yes, master & backup states are OK, even the switchover is OK, however without the right announcements coming from the master with the CARP virtual src MAC, switches can't learn to which port should they forward the traffic so both units get it. Also there are mgmt webgui timeouts since this change (always on the backup unit) and of course the kernel messages also mentioned in https://redmine.pfsense.org/issues/14163

Mar 27 15:28:09 kernel [nl_generic] PID 15866 genl_handle_message: received family carp cmd SIOCGVH len 28
Mar 27 15:28:09 kernel [nl_generic] PID 15866 genl_handle_message: received family nlctrl cmd GETFAMILY len 32
Mar 27 15:28:09 kernel [nl_generic] PID 15380 genl_handle_message: received family carp cmd SIOCGVH len 28
Mar 27 15:28:09 kernel [nl_generic] PID 15380 genl_handle_message: received family nlctrl cmd GETFAMILY len 32

BR, Robert

Switches do not learn what port to use based on the carp announcements, so that's not actually something to worry about.
It's not quite correct according to the CARP protocol (insofar as that protocol is specified), so we will fix it.

The netlink messages are there because carp configuration now uses netlink. The log messages are overly verbose, but harmless and can safely be ignored.

Actually, they do.

The bug is fairly obvious now. The check for multicast in carp_output() expects the IP address to be in host endianness, and it's presented in network endianness. The fix is trivial and has gone upstream in https://cgit.freebsd.org/src/commit/?id=ccff2078af42dc066e1c38d25fcb83d960c3c22b
We'll pick that up in future merges, probably in a week or two.

Looking good on 2.7.0.a.20230331.1347, these are virtual src MACs coming from the MASTER:

tcpdump -e -i

00:13:34.850333 00:00:5e:00:01:16 (oui IANA) > 01:00:5e:00:00:12 (oui Unknown), ethertype IPv4 (0x0800), length 70: 10.10.10.2 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 22, prio 0, authtype none, intvl 1s, length 36
00:13:35.851443 00:00:5e:00:01:16 (oui IANA) > 01:00:5e:00:00:12 (oui Unknown), ethertype IPv4 (0x0800), length 70: 10.10.10.2 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 22, prio 0, authtype none, intvl 1s, length 36
00:13:36.874236 00:00:5e:00:01:16 (oui IANA) > 01:00:5e:00:00:12 (oui Unknown), ethertype IPv4 (0x0800), length 70: 10.10.10.2 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 22, prio 0, authtype none, intvl 1s, length 36