Your message dated Tue, 3 Dec 2019 12:17:00 +0100 with message-id <925233a6-9511-e3ed-2a78-32bd04b60...@debian.org> and subject line Re: Bug#794969: udev: change in network device naming scheme unnecessarily and incorrectly renames WiMAX devices has caused the Debian Bug report #794969, regarding udev: change in network device naming scheme unnecessarily and incorrectly renames WiMAX devices to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 794969: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794969 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---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
Description: Digital signature
--- End Message ---
--- Begin Message ---Am 03.12.19 um 01:25 schrieb brian m. carlson: > On 2019-12-02 at 17:04:29, Michael Biebl wrote: >> Control: tags -1 + moreinfo >> >> 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. Since I only have this one system where it works properly, I assume this is fixed and since you no longer have access to your old system, I think it's best to close the bug report, as we have no means to further investigate this. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Description: OpenPGP digital signature
--- End Message ---