Bug 907365 - initscripts tries to rename added type 803 monitor mode interface
initscripts tries to rename added type 803 monitor mode interface
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Lukáš Nykrýn
Fedora Extras Quality Assurance
:
: 912323 (view as bug list)
Depends On:
Blocks: ovirt-3.2-release
  Show dependency treegraph
 
Reported: 2013-02-04 03:25 EST by Edward Sheldrake
Modified: 2013-02-25 21:44 EST (History)
12 users (show)

See Also:
Fixed In Version: initscripts-9.42.2-1.fc18
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-25 21:44:52 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
udevadm test output (6.10 KB, text/plain)
2013-02-04 08:05 EST, Edward Sheldrake
no flags Details

  None (edit)
Description Edward Sheldrake 2013-02-04 03:25:00 EST
Description of problem:
When attempting to add an extra monitor mode interface to a wifi interface, systemd attempts to rename it to wlan0, complains that wlan0 is already in use, then renames it to renameN.

Version-Release number of selected component (if applicable):
systemd-197-1.fc18.2.x86_64

How reproducible:
Always?

Steps to Reproduce:
1. iw phy phy0 interface add moni0 type monitor
2.
3.
  
Actual results:
systemd-udevd[3656]: Tried to rename network interface moni0, but the target name wlan0 already exists! The names that udev rules assign to network interfaces must be changed. Avoid names that collide with kernel created ones. A workaround will be attempted now, but this WILL BREAK in a future release! See https://bugs.freedesktop.org/show_bug.cgi?id=56929#c3
systemd-udevd[3656]: renamed network interface moni0 to rename8

Expected results:
moni0 monitor mode interface created

Additional info:
I think this is a regression in the 197-1.fc18.2 updates-testing release. I tried commenting out everything in /etc/udev/rules.d/70-persistent-net.rules and doing "udevadm control --reload", but this made no difference.
Comment 1 Michal Schmidt 2013-02-04 04:31:45 EST
Please attach:
- the file /etc/udev/rules.d/70-persistent-net.rules
- the output of: udevadm test /sys/class/net/rename8
Comment 2 Kay Sievers 2013-02-04 07:22:18 EST
This might be caused by creating a device with the same MAC address. The
logic never really covered these cases.

/etc/udev/rules.d/70-persistent-net.rules is a left-over from an earlier
distribution, we do not create any files in /etc any more.

Unfortunately, it requires manual attention, and we cannot do the cleanup/
conversion by RPM. It's not simple to find out, if people edited or added
things to that file. 

After removing all entries in /etc/udev/rules.d/70-persistent-net.rules,
or by just deleting the file and rebooting, the device name should not
be touched any more, right?
Comment 3 Edward Sheldrake 2013-02-04 08:05:01 EST
Created attachment 692704 [details]
udevadm test output
Comment 4 Edward Sheldrake 2013-02-04 08:18:02 EST
I removed 70-persistent-net.rules (and 70-persistent-cd.rules) and rebooted.
I now have Auto_eth0 instead of eth0, lo, wlan0, and rename4 instead of moni0.
Comment 5 Michal Schmidt 2013-02-04 08:19:41 EST
From the udevadm test output:

PROGRAM '/lib/udev/rename_device' /usr/lib/udev/rules.d/60-net.rules:1
starting '/lib/udev/rename_device'
'/lib/udev/rename_device' [4321] exit with return code 0
NAME 'wlan0' /usr/lib/udev/rules.d/60-net.rules:1

So the name comes from the renaming performed by initscripts (based on /etc/sysconfig/network-scripts/ifcfg-* contents). Since initscripts' rename_device naively chooses the name to apply based on the MAC address only, I don't see how that could have possibly been doing anything sane in the presence of wlan monitor interfaces.

Did this setup work for you in Fedora 17?
Comment 6 Kay Sievers 2013-02-04 08:36:00 EST
(In reply to comment #4)
> I removed 70-persistent-net.rules (and 70-persistent-cd.rules) and rebooted.
> I now have Auto_eth0 instead of eth0, lo, wlan0, and rename4 instead of
> moni0.

If these are really your network interface names, "Auto_eth0" sounds like
some NetworkManager weirdness stored in /etc/sysconfig/network-scripts/ifcfg-*.

It is no name the base system would choose.

Can you try removing files from:
  /etc/sysconfig/network-scripts/ifcfg-*
?
Comment 7 Edward Sheldrake 2013-02-04 11:10:08 EST
My setup was working fine until this morning, which was the first time I booted since installing systemd-197-1.fc18.2.

Yes, part of the trouble comes from the /etc/sysconfig/network-scripts/ifcfg-* files. I deleted /etc/sysconfig/network-scripts/ifcfg-Auto_eth0 and unloaded and reloaded the r8169 module to get it back to eth0.

I have removed the HWADDR line with the MAC address from /etc/sysconfig/networking/devices/ifcfg-wlan0 and now systemd no longer attempts to rename moni0.
Comment 8 Edward Sheldrake 2013-02-04 11:31:37 EST
Previous Fedora 18 versions quietly logged:
Jan 21 11:41:44 obsidian systemd-udevd[273]: error changing net interface name moni0 to wlan0: File exists

but didn't then proceed to rename moni0 to something else.
Comment 9 Kay Sievers 2013-02-04 11:46:19 EST
Systemd just follows the instructions from initscripts, which should not
try to rename the monitor devices, which are device type 803 instead of 1.

Reassigning to initscripts.
Comment 10 Michal Schmidt 2013-02-04 12:55:54 EST
(In reply to comment #8)
> Previous Fedora 18 versions quietly logged:
> Jan 21 11:41:44 obsidian systemd-udevd[273]: error changing net interface
> name moni0 to wlan0: File exists

Yes. And people hated it. See bug 896135.
That's why I was specifically interested in how Fedora 17 behaved. Because the change in systemd-197-1.fc18.2 is trying to restore udev's ability to rename net interfaces like it did in F17.
Comment 11 Lukáš Nykrýn 2013-02-05 04:05:10 EST
Unfortunately my udev skills are quite poor, do you think that patch like this will fixed the issue?

diff --git a/udev/rules.d/60-net.rules b/udev/rules.d/60-net.rules
index 1e9d940..876ff9b 100644
--- a/udev/rules.d/60-net.rules
+++ b/udev/rules.d/60-net.rules
@@ -1 +1,3 @@
+KERNEL=="wlan*", ATTRS{type}=="803", GOTO="net_rules_end"
 ACTION=="add", SUBSYSTEM=="net", PROGRAM="/lib/udev/rename_device", RESULT=="?*", NAME="$result"
+LABEL="net_rules_end"
Comment 12 Kay Sievers 2013-02-05 06:47:47 EST
I suspect initscripts should not rename anything besides type == "1"
devices. Many of the other device types get a device name passed by the
tools that create them, and renaming is not too useful then.

Limiting initscripts to the absolute minimum that is expected, seems like the
best approach, blacklisting explicit types doesn't sound like the right thing
considering the "creativity" in the network device type area. :)
Comment 13 Lukáš Nykrýn 2013-02-05 06:54:45 EST
So something like following?
ACTION=="add", SUBSYSTEM=="net", ATTRS{type}=="1", PROGRAM="/lib/udev/rename_device", RESULT=="?*", NAME="$result"
Comment 14 Michal Schmidt 2013-02-20 08:27:36 EST
I'm getting good results with the following rule in 60-net.rules:

ACTION=="add", SUBSYSTEM=="net", DRIVERS=="?*", ATTR{type}=="1", PROGRAM="/lib/udev/rename_device", RESULT=="?*", NAME="$result"

The DRIVERS check is important, as it excludes virtual devices (such as VLANs, ...). I found this by looking at how older Fedora releases (and RHEL6) worked. The check was not present directly in 60-net.rules, but it was included in the generated rules.

Note there's ATTR, not ATTRS. We don't need to look at parent attributes.
Comment 15 Michal Schmidt 2013-02-20 08:28:58 EST
*** Bug 912323 has been marked as a duplicate of this bug. ***
Comment 16 Michal Schmidt 2013-02-20 08:31:25 EST
Lukáš,
I'd like to have the fixed initscripts added to the systemd-197-1.fc18.2 update in Bodhi, to make it a grouped update.
Comment 17 Fedora Update System 2013-02-21 04:07:51 EST
initscripts-9.42.2-1.fc18, systemd-197-1.fc18.2 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/FEDORA-2013-1590/initscripts-9.42.2-1.fc18,systemd-197-1.fc18.2
Comment 18 Fedora Update System 2013-02-22 20:03:02 EST
Package initscripts-9.42.2-1.fc18, systemd-197-1.fc18.2:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing initscripts-9.42.2-1.fc18 systemd-197-1.fc18.2'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-1590/initscripts-9.42.2-1.fc18,systemd-197-1.fc18.2
then log in and leave karma (feedback).
Comment 19 Fedora Update System 2013-02-25 21:44:56 EST
initscripts-9.42.2-1.fc18, systemd-197-1.fc18.2 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.