nexmon – Blame information for rev 1
?pathlinks?
Rev | Author | Line No. | Line |
---|---|---|---|
1 | office | 1 | Network interface renaming comparison |
2 | ------------------------------------- |
||
3 | |||
4 | INTRODUCTION |
||
5 | ------------ |
||
6 | The Wireless Tools package includes 'ifrename', a tool to |
||
7 | rename network interfaces. However, this is not the only solution to |
||
8 | the problem of renaming network interfaces. This document explain the |
||
9 | differences between ifrename and the various alternatives. |
||
10 | The subject of interface renaming may look simple at first |
||
11 | glance, and is simple in 95% of the cases, however there are many |
||
12 | complex scenario and those tools have many features, which explain why |
||
13 | we need to go in more details than just saying 'tool X is better'. |
||
14 | |||
15 | NAMEIF |
||
16 | ------ |
||
17 | The tool 'nameif' was designed to rename network |
||
18 | interfaces. It either loads mapping from the file /etc/mactab or |
||
19 | accept mapping on the command line. |
||
20 | It is part of the net-tools package : |
||
21 | http://www.tazenda.demon.co.uk/phil/net-tools/ |
||
22 | |||
23 | Advantages over 'ifrename' : |
||
24 | + More widespread, available in very old distributions |
||
25 | + simpler/smaller |
||
26 | Drawbacks compared to 'ifrename' : |
||
27 | - Only support MAC address selector |
||
28 | - Does not support hotplug invocation |
||
29 | - Does not support module on-demand loading |
||
30 | Comments : |
||
31 | o The fact that nameif does not support selector other |
||
32 | than the MAC address is problematic, as USB-NET devices may not have |
||
33 | MAC addresses and some ethernet/wireless drivers can't query the MAC |
||
34 | address before 'ifconfig up'. |
||
35 | o 'ifrename' was designed as a better 'nameif', and |
||
36 | its concept is very similar. |
||
37 | |||
38 | IPROUTE |
||
39 | ------- |
||
40 | The tool 'ip' can rename network interfaces with the following |
||
41 | syntax : |
||
42 | > ip link set <oldname> name <newname> |
||
43 | It is part of the 'iproute' package : |
||
44 | http://developer.osdl.org/dev/iproute2/ |
||
45 | |||
46 | Advantages over 'ifrename' : |
||
47 | + integrated in 'iproute', which most people need anyway |
||
48 | Drawbacks compared to 'ifrename' : |
||
49 | - Do not support any selector, must use old interface name |
||
50 | - No 'batch' mode, must rename each interface manually |
||
51 | Comments : |
||
52 | o 'ip' only provide the most basic facility. To use it |
||
53 | automatically, like in init/hotplug scripts, wrappers adding some |
||
54 | rules/selector must be written. |
||
55 | |||
56 | DRIVER MODULE PARAMETERS |
||
57 | ------------------------ |
||
58 | Some network driver have module parameters enabling to specify |
||
59 | the network name of all the devices created by the driver. This is |
||
60 | driver specific, so you will need to check your driver. |
||
61 | |||
62 | Advantages over 'ifrename' : |
||
63 | + very simple to get configured and running |
||
64 | Drawbacks compared to 'ifrename' : |
||
65 | - Not universally supported : few drivers do it |
||
66 | - Fragmented : each driver does it differently |
||
67 | - The only selector available is the driver |
||
68 | Comments : |
||
69 | o This method was never popular with the kernel |
||
70 | people, and this feature is being removed from driver that use to |
||
71 | include it. |
||
72 | |||
73 | UDEV |
||
74 | ---- |
||
75 | The package 'udev' include facility to rename network |
||
76 | interfaces, with rules such as : |
||
77 | KERNEL="eth*", SYSFS{address}="00:52:8b:d5:04:48", NAME="lan" |
||
78 | This is part of the udev package : |
||
79 | http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html |
||
80 | |||
81 | Advantages over 'ifrename' : |
||
82 | + simpler to setup if 'udev' is already properly setup |
||
83 | + automatically generates persistent rules |
||
84 | Drawbacks compared to 'ifrename' : |
||
85 | - Less selectors that 'ifrename' |
||
86 | - Require kernel 2.6.X or later with sysfs support |
||
87 | - Do no support non-hotplug interfaces |
||
88 | - Require 'udev', not everybody uses it (static /dev, devfs) |
||
89 | Comments : |
||
90 | o 'udev' support many selectors, basically all those |
||
91 | present in 'sysfs' (excluding symlinks), even if the documentation |
||
92 | only show instructions to use the MAC address (which is problematic |
||
93 | with virtual devices some drivers - see above). 'ifrename' can also |
||
94 | use all selectors present in 'sysfs' (like 'udev'), can use sysfs |
||
95 | symlinks and parent directories, plus some other selectors not present |
||
96 | in sysfs that were found to be useful. |
||
97 | o Not all interfaces are managed by hotplug. All |
||
98 | virtual devices, such as tunnels and loopbacks, are not associated |
||
99 | with a hardware bus, and therefore are not managed by hotplug. All |
||
100 | driver compiled statically into the kernel are not managed by |
||
101 | hotplug. 'udev' can't deal with those devices. |
||
102 | o It is common practice on embedded system to use a |
||
103 | static /dev and not 'udev' to save space and boot time. And to not use |
||
104 | hotplug for the same reasons. |
||
105 | o 'ifrename' has now a udev compatiblity mode that |
||
106 | enables to trivially integrate it into 'udev' as an IMPORT rule. This |
||
107 | requires udev version 107 or better and ifrename 29-pre17 or better. |
||
108 | |||
109 | SELECTOR AWARE NETWORK SCRIPTS |
||
110 | ------------------------------ |
||
111 | Another method is to not rename the interface at all, and make |
||
112 | the various network script selector aware. The basic idea is to simply |
||
113 | ignore the interface name and have all the network scripts based on |
||
114 | selectors. |
||
115 | The main example is the original Pcmcia network scripts. They |
||
116 | allow you to configure an interface directly based on MAC address and |
||
117 | Pcmcia socket. Another example is the script get-mac-address.sh used |
||
118 | as a mapping in some Debian configuration. On the other hand, Red-Hat |
||
119 | and Fedora scripts don't apply, as they wrap around 'nameif'. |
||
120 | |||
121 | Advantages over 'ifrename' : |
||
122 | + usually simpler to setup and understand |
||
123 | Drawbacks compared to 'ifrename' : |
||
124 | - Less selectors that 'ifrename' |
||
125 | - Only work for the scripts, other tools left confused |
||
126 | Comments : |
||
127 | o This method is conceptually simpler, and works |
||
128 | well. It eliminates the two steps process of other methods (renaming ; |
||
129 | configuring). |
||
130 | o Unfortunately, this method only apply to the |
||
131 | specific scripts, and not to the majority of the networking tools |
||
132 | which are still based on interface name. This means that when the user |
||
133 | use those other tools, he is left guessing which interface is which. |
||
134 | o Distributions never never really embraced this |
||
135 | method, as they all replaced the original Pcmcia scripts with one |
||
136 | using the interfacename. |
||
137 | |||
138 | Have fun... |
||
139 | |||
140 | Jean |
||
141 |