pfSense

vhid field in CARP packet is one byte long, so this GUI change does not make any sense.

We have a patch in the builds which expands the field to two bytes.

Understood.
So the pfSense is not compatible with *BSD.
And I understood why CARP is broken now.

Does anyone looking into the issue with broken CARP?

yes

According to packet dump

carp vhid=1

192.168.252.254 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 0, authtype #128, intvl 1s, length 36, addrs(7): 107.95.16.142,89.11.4.1,28.106.118.248,149.43.12.212,148.195.215.246,252.189.185.117,56.253.61.5
0x0000: 0100 5e00 0012 0000 5e00 0101 0800 4510
0x0010: 0038 d66a 4000 ff70 0000 c0a8 fcfe e000
0x0020: 0012 2101 0007 8001 b7a9 6b5f 108e 590b
0x0030: 0401 1c6a 76f8 952b 0cd4 94c3 d7f6 fcbd
0x0040: b975 38fd 3d05

carp vhid=256

192.168.253.254 > 224.0.0.18: VRRPv2, Advertisement, vrid 0, prio 0, authtype simple, intvl 1s, length 36, addrs(7): 137.7.31.146,238.223.10.81,90.241.214.208,59.45.154.124,64.216.227.11,117.38.205.9,26.19.86.208[|vrrp]
0x0000: 0100 5e00 0012 0000 5e00 0100 0800 4510
0x0010: 0038 8271 4000 ff70 0000 c0a8 fdfe e000
0x0020: 0012 2100 0007 0101 5dc9 8907 1f92 eedf
0x0030: 0a51 5af1 d6d0 3b2d 9a7c 40d8 e30b 7526
0x0040: cd09 1a13 56d0

seems like there is something wrong with bit shifting for vhidx field (previously it was known as "carp_pad1" field).
When interface's vhid<=255 - it's allways 10000000b (0x80) and only when interface's vhid>=255 everything works as expected.

2ALL: Temporary workaround for this situation is to use VHID greater than 255.

In the patch file, I saw this change that commented out this line:

-     ch.carp_pad1 = 0;     /* must be zero */
+     //ch.carp_pad1 = 0;     /* pfSense HACK */

In the part just before that, carp_vhidx (renamed from carp_pad1) is not initialized to 0 in the <= 255 case, so it likely does not get initialized at all. (this may be the cause of the issue) Rather than this (about line 923, if I calculated right from the diff):

    if (sc->sc_vhid <= 255)
        ch.carp_vhid = sc->sc_vhid;
    else {
        ch.carp_vhid = sc->sc_vhid & 0xff;
        ch.carp_vhidx = sc->sc_vhid >> 8;
    }

It should probably be this:

    if (sc->sc_vhid <= 255)
        ch.carp_vhid = sc->sc_vhid;
        ch.carp_vhidx = 0;
    else {
        ch.carp_vhid = sc->sc_vhid & 0xff;
        ch.carp_vhidx = sc->sc_vhid >> 8;
    }

There also may be a MAC conflict for vhid's of <= 255 and the ones in the range of 256 - 511. There are some cases like the following example that either set a value to 1 or the upper 8 bits, and the upper 8 bits equal that same value for the 256 - 511 range. Something probably needs to be done about that (assuming the patch is even left in).

            if (sc->sc_vhid <= 255) {
                eh->ether_shost[4] = 1;
                eh->ether_shost[5] = sc->sc_vhid;
            } else {
                eh->ether_shost[4] = sc->sc_vhid >> 8;
                eh->ether_shost[5] = sc->sc_vhid & 0xff;
            }