Network interface renaming comparison ------------------------------------- INTRODUCTION ------------ The Wireless Tools package includes 'ifrename', a tool to rename network interfaces. However, this is not the only solution to the problem of renaming network interfaces. This document explain the differences between ifrename and the various alternatives. The subject of interface renaming may look simple at first glance, and is simple in 95% of the cases, however there are many complex scenario and those tools have many features, which explain why we need to go in more details than just saying 'tool X is better'. NAMEIF ------ The tool 'nameif' was designed to rename network interfaces. It either loads mapping from the file /etc/mactab or accept mapping on the command line. It is part of the net-tools package : http://www.tazenda.demon.co.uk/phil/net-tools/ Advantages over 'ifrename' : + More widespread, available in very old distributions + simpler/smaller Drawbacks compared to 'ifrename' : - Only support MAC address selector - Does not support hotplug invocation - Does not support module on-demand loading Comments : o The fact that nameif does not support selector other than the MAC address is problematic, as USB-NET devices may not have MAC addresses and some ethernet/wireless drivers can't query the MAC address before 'ifconfig up'. o 'ifrename' was designed as a better 'nameif', and its concept is very similar. IPROUTE ------- The tool 'ip' can rename network interfaces with the following syntax : > ip link set name It is part of the 'iproute' package : http://developer.osdl.org/dev/iproute2/ Advantages over 'ifrename' : + integrated in 'iproute', which most people need anyway Drawbacks compared to 'ifrename' : - Do not support any selector, must use old interface name - No 'batch' mode, must rename each interface manually Comments : o 'ip' only provide the most basic facility. To use it automatically, like in init/hotplug scripts, wrappers adding some rules/selector must be written. DRIVER MODULE PARAMETERS ------------------------ Some network driver have module parameters enabling to specify the network name of all the devices created by the driver. This is driver specific, so you will need to check your driver. Advantages over 'ifrename' : + very simple to get configured and running Drawbacks compared to 'ifrename' : - Not universally supported : few drivers do it - Fragmented : each driver does it differently - The only selector available is the driver Comments : o This method was never popular with the kernel people, and this feature is being removed from driver that use to include it. UDEV ---- The package 'udev' include facility to rename network interfaces, with rules such as : KERNEL="eth*", SYSFS{address}="00:52:8b:d5:04:48", NAME="lan" This is part of the udev package : http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html Advantages over 'ifrename' : + simpler to setup if 'udev' is already properly setup + automatically generates persistent rules Drawbacks compared to 'ifrename' : - Less selectors that 'ifrename' - Require kernel 2.6.X or later with sysfs support - Do no support non-hotplug interfaces - Require 'udev', not everybody uses it (static /dev, devfs) Comments : o 'udev' support many selectors, basically all those present in 'sysfs' (excluding symlinks), even if the documentation only show instructions to use the MAC address (which is problematic with virtual devices some drivers - see above). 'ifrename' can also use all selectors present in 'sysfs' (like 'udev'), can use sysfs symlinks and parent directories, plus some other selectors not present in sysfs that were found to be useful. o Not all interfaces are managed by hotplug. All virtual devices, such as tunnels and loopbacks, are not associated with a hardware bus, and therefore are not managed by hotplug. All driver compiled statically into the kernel are not managed by hotplug. 'udev' can't deal with those devices. o It is common practice on embedded system to use a static /dev and not 'udev' to save space and boot time. And to not use hotplug for the same reasons. o 'ifrename' has now a udev compatiblity mode that enables to trivially integrate it into 'udev' as an IMPORT rule. This requires udev version 107 or better and ifrename 29-pre17 or better. SELECTOR AWARE NETWORK SCRIPTS ------------------------------ Another method is to not rename the interface at all, and make the various network script selector aware. The basic idea is to simply ignore the interface name and have all the network scripts based on selectors. The main example is the original Pcmcia network scripts. They allow you to configure an interface directly based on MAC address and Pcmcia socket. Another example is the script get-mac-address.sh used as a mapping in some Debian configuration. On the other hand, Red-Hat and Fedora scripts don't apply, as they wrap around 'nameif'. Advantages over 'ifrename' : + usually simpler to setup and understand Drawbacks compared to 'ifrename' : - Less selectors that 'ifrename' - Only work for the scripts, other tools left confused Comments : o This method is conceptually simpler, and works well. It eliminates the two steps process of other methods (renaming ; configuring). o Unfortunately, this method only apply to the specific scripts, and not to the majority of the networking tools which are still based on interface name. This means that when the user use those other tools, he is left guessing which interface is which. o Distributions never never really embraced this method, as they all replaced the original Pcmcia scripts with one using the interfacename. Have fun... Jean