veth mac changes between cniADD and cniCheck

[mccv1r0]

CNI add creates:

$ cnitool add crio /var/run/netns/mcc-cni-test0
{
    "cniVersion": "1.0.0",
    "interfaces": [
        {
            "name": "cni0",
            "mac": "a6:2d:36:d9:1c:6c"
        },
        {
            "name": "veth5c225f9c",
            "mac": "b6:64:dc:fc:71:c2"
        },
        {
            "name": "ens0",
            "mac": "e2:34:e2:1e:ef:64",
            "sandbox": "/var/run/netns/mcc-cni-test0"
        }
    ],
    "ips": [
        {
            "interface": 2,
            "address": "10.85.0.4/16",
            "gateway": "10.85.0.1"
        }
    ],
    "routes": [
        {
            "dst": "0.0.0.0/0"
        }
    ],
    "dns": {}
}

The veth on the host side is changed by TBD:

323: veth5c225f9c@if88: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master cni0 state UP group default 
    link/ether 06:1a:2c:18:b7:e9 brd ff:ff:ff:ff:ff:ff link-netns mcc-cni-test0
    inet6 fe80::41a:2cff:fe18:b7e9/64 scope link 
       valid_lft forever preferred_lft forever

This causes check to fail:

$ cnitool check crio /var/run/netns/mcc-cni-test0
Interface veth5c225f9c Mac doesn't match: b6:64:dc:fc:71:c2 not found
$ 

[mccv1r0]

Looks like bridge plugin specific

[squeed]

what the heck is changing the mac!?

[mccv1r0]

what the heck is changing the mac!?

Right now it looks like the kernel does this "underneath" us.

I've added lots of debug code after every if statement:

		// check the MAC
		if savedhostInterfaceMac != hostVeth.Attrs().HardwareAddr.String() {
			return fmt.Errorf("debugX: mac addr changed from %q to  %q: %v", savedhostInterfaceMac, hostVeth.Attrs().HardwareAddr.String(), err)
		}

where debugX is unique in each case. We hit at random points, including after an if statement I know to be false for my test configlist. That is the macs were the same, if test false so next the macs are compared again and they are now different.