On Mon, Dec 02, 2024 at 12:50:15PM +0900, Dominique MARTINET wrote: > Hi, > > Oliver Neukum wrote on Thu, Oct 17, 2024 at 09:18:37AM +0200: > > The fix for MAC addresses broke detection of the naming convention > > because it gave network devices no random MAC before bind() > > was called. This means that the check for the local assignment bit > > was always negative as the address was zeroed from allocation, > > instead of from overwriting the MAC with a unique hardware address. > > So we hit the exact inverse problem with this patch: our device ships an > LTE modem which exposes a cdc-ethernet interface that had always been > named usb0, and with this patch it started being named eth1, breaking > too many hardcoded things expecting the name to be usb0 and making our > devices unable to connect to the internet after updating the kernel. > > > Long term we'll probably add an udev rule or something to make the name > explicit in userspace and not risk this happening again, but perhaps > there's a better way to keep the old behavior? > > (In particular this hit all stable kernels last month so I'm sure we > won't be the only ones getting annoyed with this... Perhaps reverting > both patches for stable branches might make sense if no better way > forward is found -- I've added stable@ in cc for heads up/opinions) Device names have NEVER been stable. They move around and can change on every boot, let alone almost always changing between kernel versions. That's why we created udev, to solve this issue. But how is changing the MAC address changing the device naming here? How are they linked to suddenly causing the names to switch around? thanks, greg k-h
