1 files changed, 33 insertions, 0 deletions

diff --git a/gitlab/issues/target_missing/host_missing/accel_missing/2951.toml b/gitlab/issues/target_missing/host_missing/accel_missing/2951.toml
new file mode 100644
index 00000000..6a303d53
--- /dev/null
+++ b/gitlab/issues/target_missing/host_missing/accel_missing/2951.toml
@@ -0,0 +1,33 @@
+id = 2951
+title = "First byte of USB NIC is hardcoded to 0x40"
+state = "opened"
+created_at = "2025-05-06T16:08:57.518Z"
+closed_at = "n/a"
+labels = ["USB"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/2951"
+host-os = "Debian 13"
+host-arch = "x86_64"
+qemu-version = "10.0.0"
+guest-os = "n/a"
+guest-arch = "n/a"
+description = """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?"""
+reproduce = "n/a"
+additional = "n/a"