I can't find a place to tell whether your MAC address is valid for your chip. forcedeth makes one up in a certain valid sub-range not associated with any hardware. it looks like a valid MAC for some chip. the forcedeth ones all begin with an unusual 00:00 before the random hex, but this is probably just a forcedeth quirk and not approved behaviour.
the crucial question, is whether your MAC address is the same on reboot, or after suspend/resume. The persistent net rules behaviour is consistent with it seeing new devices; the bug is that the same device is given new MAC addresses. If your MAC is changing, you could look at my trivial code changes for forcedeth and apply them to the relevant module. This is probably not as hard as it sounds as I have already hacked together the infrastructure for the most simple imaginable kernel module dkms patch.
I'm not clear whether this bug is especially related to forcedeth behaviour, or just any invalid MAC.
I can't find a place to tell whether your MAC address is valid for your chip. forcedeth makes one up in a certain valid sub-range not associated with any hardware. it looks like a valid MAC for some chip. the forcedeth ones all begin with an unusual 00:00 before the random hex, but this is probably just a forcedeth quirk and not approved behaviour.
the crucial question, is whether your MAC address is the same on reboot, or after suspend/resume. The persistent net rules behaviour is consistent with it seeing new devices; the bug is that the same device is given new MAC addresses. If your MAC is changing, you could look at my trivial code changes for forcedeth and apply them to the relevant module. This is probably not as hard as it sounds as I have already hacked together the infrastructure for the most simple imaginable kernel module dkms patch.
I'm not clear whether this bug is especially related to forcedeth behaviour, or just any invalid MAC.