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
signature.asc
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?
signature.asc
Description: OpenPGP digital signature
--- End Message ---
