add new classifier result

1 files changed, 34 insertions, 0 deletions

diff --git a/results/classifier/105/network/2951 b/results/classifier/105/network/2951
new file mode 100644
index 00000000..a70c3a0c
--- /dev/null
+++ b/results/classifier/105/network/2951
@@ -0,0 +1,34 @@
+network: 0.935
+graphic: 0.840
+device: 0.838
+vnc: 0.799
+instruction: 0.765
+socket: 0.693
+other: 0.646
+boot: 0.561
+semantic: 0.529
+KVM: 0.277
+assembly: 0.249
+mistranslation: 0.142
+
+First byte of USB NIC is hardcoded to 0x40
+Description of problem:
+Incus recently added support for USB attached network interfaces.
+As with any network device, we generate a MAC address (using our MAC OUI) and allow the user to override that to a value of their choice.
+
+That's when we noticed that no matter what MAC address we set, the resulting MAC always has the prefix swapped to "40:". Looking into the code, this is done on purpose here:
+
+https://gitlab.com/qemu-project/qemu/-/blob/master/hw/usb/dev-network.c?ref_type=heads#L1386
+
+Unfortunately there is no comment in the code or in any of the commits touching that code as far as why that is.
+
+We've also looked at the libvirt code handling those devices and that code seems to also assume that a user provided MAC will be correctly passed through to the guest, no mention of the odd prefix override.
+
+This is a bit concerning as there are valid IEEE OUI with the "40:" prefix.
+So this means that QEMU may be generating collisions with actual physical MAC addresses...
+
+For a few months now, I've been applying this small patch to my own Incus packages (which bundle QEMU) and haven't heard or seen any obvious issue from the change.
+
+https://github.com/zabbly/incus/blob/daily/patches/qemu-0001-usb-net-mac.patch
+
+Does anyone know why this hardcoded MAC address prefix exists?