On Wed, Sep 06, 2017 at 07:20:56PM +1000, luv-main@luv.asn.au wrote:
On 06.09.17 18:14, Ray via luv-main wrote:
enx0c5b8f279a64 is NOT random 0c5.......64 is the MAC address of the 4G dongle so will only change if the dongle changes. Why it does not use a USB ethernet naming convention (if there is one) I do not know.
OK, I could buy that for a hotplug dongle, but enp5s0 looks awfully short for a MAC? (Mine came out as enp2s0, before I gave it the flick.)
Predictable Network Interface Names (or PNIN): https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfac... ... [..NIC naming supported by udev...] 1. Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: eno1) 1. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1) 1. Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0) 1. Names incorporating the interfaces's MAC address (example: enx78e7d1ea46da) 1. Classic, unpredictable kernel-native ethX naming (example: eth0) ...
I was wondering though about some of these weird device id's
The excuse made for the obfuscated interface names at the user level is that they "avoid name volatility in the event of NIC replacement".
It's about more than that. And it's about more than dealing with extra NICs being added or NICs being removed or moved from one slot to another. The kernel explicitly DOES NOT GUARANTEE that a NIC will get the same name across reboots. There are many factors that may cause a device to get renamed, including module load order and even upgrading the kernel to a new version. PNIN exists to **solve** "random" NIC renaming, not to create it. Relying on something that the kernel devs explicitly tell you can not be relied upon is crazy. Use udev rules. or ifrename if you must (but udev works better). craig -- craig sanders <cas@taz.net.au>