Discussion:
Bug#794969: udev: change in network device naming scheme unnecessarily and incorrectly renames WiMAX devices
Add Reply
brian m. carlson
2015-08-08 20:40:02 UTC
Reply
Permalink
Package: udev
Version: 224-1
Severity: normal

Previously, my WiMAX device was named something like wmx0. Now, it
appears it's been renamed to enx<MAC Address>. First of all, the name
has changed from what it used to be, and now I have to check that it's
not broken anything. There wasn't supposed to be a naming change for
people with the persistent-net rules in place.

Secondly, this is not an Ethernet device, so en is not correct (it
should be ww). The device is on the USB bus (using the driver
i2400m-usb).

For an example why this matters, think firewall rules: while I might
legitimately want to SSH into my laptop over Ethernet or WiFi (e.g. from
my phone when I'm in the other room), there's no reason I would want
arbitrary people on the Internet (WiMAX) to SSH in. Of course, I have
appropriate security measures in place, but I'd still want to firewall
incoming WiMAX connections, and using an appropriate naming scheme makes
that possible.

-- Package-specific info:

-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages udev depends on:
ii adduser 3.113+nmu3
ii cdebconf [debconf-2.0] 0.195
ii debconf [debconf-2.0] 1.5.57
ii dpkg 1.18.2
ii libacl1 2.2.52-2
ii libblkid1 2.26.2-9
ii libc6 2.19-19
ii libkmod2 21-1
ii libselinux1 2.3-2+b1
ii libudev1 224-1
ii lsb-base 4.1+Debian13+nmu1
ii procps 2:3.3.10-2
ii util-linux 2.26.2-9

udev recommends no packages.

udev suggests no packages.

-- debconf information excluded
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
Marco d'Itri
2015-08-09 22:20:02 UTC
Reply
Permalink
Post by brian m. carlson
Previously, my WiMAX device was named something like wmx0. Now, it
appears it's been renamed to enx<MAC Address>. First of all, the name
has changed from what it used to be, and now I have to check that it's
not broken anything. There wasn't supposed to be a naming change for
people with the persistent-net rules in place.
Indeed: what was the content of your 70-persistent-net.rules file?
I suspect that persistent naming just never worked for you for this
interface.
Post by brian m. carlson
Secondly, this is not an Ethernet device, so en is not correct (it
should be ww). The device is on the USB bus (using the driver
i2400m-usb).
I do not think that such a distinction is relevant here.
Post by brian m. carlson
For an example why this matters, think firewall rules: while I might
legitimately want to SSH into my laptop over Ethernet or WiFi (e.g. from
my phone when I'm in the other room), there's no reason I would want
arbitrary people on the Internet (WiMAX) to SSH in. Of course, I have
appropriate security measures in place, but I'd still want to firewall
incoming WiMAX connections, and using an appropriate naming scheme makes
that possible.
You can still manually set any persistent name you like.
--
ciao,
Marco
brian m. carlson
2015-08-10 23:40:02 UTC
Reply
Permalink
Post by Marco d'Itri
Post by brian m. carlson
Previously, my WiMAX device was named something like wmx0. Now, it
appears it's been renamed to enx<MAC Address>. First of all, the name
has changed from what it used to be, and now I have to check that it's
not broken anything. There wasn't supposed to be a naming change for
people with the persistent-net rules in place.
Indeed: what was the content of your 70-persistent-net.rules file?
I suspect that persistent naming just never worked for you for this
interface.
The interface is clearly missing:

# PCI device 0x8086:/sys/devices/pci0000:00/0000:00:19.0 (e1000e)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="f0:de:f1:b8:36:fd", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x8086:/sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0 (iwlwifi)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="64:80:99:4f:73:a0", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"

I suppose the idea was to skip USB devices, thinking that they were all
removable, but I can't be certain without seeing the generator, which
has been removed.
Post by Marco d'Itri
Post by brian m. carlson
Secondly, this is not an Ethernet device, so en is not correct (it
should be ww). The device is on the USB bus (using the driver
i2400m-usb).
I do not think that such a distinction is relevant here.
If you're going to autogenerate the name, please autogenerate it such
that it's consistent with the naming scheme. The comment in
udev-builtin-net_id.c indicates that ww is appropriate here. People
should be able to predict interface names, such that configuration can
be autogenerated (e.g. for puppet). Naming some WWAN devices as ww but
others as en is silly.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
brian m. carlson
2019-12-03 00:40:01 UTC
Reply
Permalink
Control: tags -1 + moreinfo
Hi
On Mon, 10 Aug 2015 23:25:36 +0000 "brian m. carlson"
Post by brian m. carlson
Post by Marco d'Itri
Post by brian m. carlson
Previously, my WiMAX device was named something like wmx0. Now, it
appears it's been renamed to enx<MAC Address>. First of all, the name
has changed from what it used to be, and now I have to check that it's
not broken anything. There wasn't supposed to be a naming change for
people with the persistent-net rules in place.
Indeed: what was the content of your 70-persistent-net.rules file?
I suspect that persistent naming just never worked for you for this
interface.
# PCI device 0x8086:/sys/devices/pci0000:00/0000:00:19.0 (e1000e)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="f0:de:f1:b8:36:fd", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
# PCI device 0x8086:/sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0 (iwlwifi)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="64:80:99:4f:73:a0", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"
I suppose the idea was to skip USB devices, thinking that they were all
removable, but I can't be certain without seeing the generator, which
has been removed.
Post by Marco d'Itri
Post by brian m. carlson
Secondly, this is not an Ethernet device, so en is not correct (it
should be ww). The device is on the USB bus (using the driver
i2400m-usb).
I do not think that such a distinction is relevant here.
If you're going to autogenerate the name, please autogenerate it such
that it's consistent with the naming scheme. The comment in
udev-builtin-net_id.c indicates that ww is appropriate here. People
should be able to predict interface names, such that configuration can
be autogenerated (e.g. for puppet). Naming some WWAN devices as ww but
others as en is silly.
Is this issue still valid?
I do have an (internal) wimax device which is named wwx02803XXXXX, i.e.
has the ww prefix as one would expect.
If it's still a problem, please attach the output of
udevadm info /sys/class/net/$(iface)
I'm unsure. The issue is now four years old and I'm using a different
laptop without a WiMAX card. If you're sure that it's been fixed, I'm
fine with you closing it.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
Loading...