You are not logged in.
My network interface name keeps changing between wlp2s0 and wlan0. This is a real pain, since I never know what name will be generated at boot. Most of the time it's called wlp2s0, so this is what netctl is set up to handle by itself. At boots were wlan0 is generated I have to connect manually.
I've tried making the name static by adding a rule to the /etc/udev/rules.d/10-network.rules. The rule i added was:
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="48:5d:60:7e:64:e9", NAME="wlp2s0"
Wlp2s0 is generated at boot alright, but I still have to connect manually with this solution. As if the "new" wlp2s0 is not recognized as the old one (same MAC). What gives?
This is on an Asus Eee 1001PXD, with the Qualcomm Atheros AR9285.
Last edited by madr (2013-05-18 20:09:34)
Offline
Hmm, https://wiki.archlinux.org/index.php/Ne … vice_names should not behave like this.
Have you created the symlink?
Offline
I find this strange too, because of this feature of the Systemd v197. Are you talking about this symlink:
ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules
Won't this just disable this feature? Are you talking about disabling the functionality, and then creating a static name with a rule? Just checking.
EDIT:
Oh, just saw this:
it is better to use interface names that are not used by the kernel as default
May be it? If so, it applies to the rule issue. But not the original, strange issue.
Last edited by madr (2013-05-17 19:51:55)
Offline
Grep through the logs and post what you find. Probably the interface is being claimed by some program before udev can change its name.
Last edited by msthev (2013-05-17 20:05:30)
Offline
Grep through the logs and post what you find. Probably the interface is being claimed by some program before udev can change its name.
Sounds reasonable. I'm sorry for my ignorance, but I'm not that familiar with grep. I would really appreciate it if you could guide me towards the information you need. If you have the time. If not, I have to read up on it right now, and I don't have the time for that just now.
Offline
Here's a really quick read: https://wiki.archlinux.org/index.php/Systemd#Journal
I don't know specifically what network programs you run, so I can't tell you what exactly to look for. When something like this happens, udev outputs
error changing net interface name eth0 to enp2s0: Device or resource busy
If you find it, then look at what happened before — was there maybe dhcpcd started? Anything network related.
Offline
I've now been able to replicate the issue, and run the command:
journalctl -b
I did find the output:
mai 18 02:30:02 <hostname> systemd-udevd[126]: error changing net interface name wlan0 to wlp2s0: Device or resource busy
I haven't been able to process the whole output yet (I'll continue tomorrow if necessary), but I've found some things that I hope will clearify things. I get similar outputs to the following a lot throughout:
mai 18 02:30:03 <hostname> dhcpcd[237]: wlan0: carrier lost
mai 18 02:30:03 <hostname> dhcpcd[237]: wlan0: waiting for carrier
mai 18 02:30:04 <hostname> systemd[1]: netctl-auto@wlp2s0.service: control process exited, code=exited status=1
mai 18 02:30:04 <hostname> systemd[1]: Failed to start Automatic wireless network connection using netctl profiles.
mai 18 02:30:04 <hostname> systemd[1]: Unit netctl-auto@wlp2s0.service entered failed state.
mai 18 02:30:04 <hostname> systemd[1]: Starting Network.
mai 18 02:30:04 <hostname> systemd[1]: Reached target Network.
EDIT:
I see now that this is later in time, so that's not so strange after all. I'll look some more.
EDIT2:
The error code that a name change i impossible is the first time the term 'wlan0' occurs in the log. However there's a line much earlier that talks about wlp2s0:
mai 18 02:29:59 <hostname> systemd[1]: Expecting device sys-subsystem-net-devices-wlp2s0.device...
But as I said, if this information doesn't help, I'll have a closer look at the output tomorrow. Getting late here in Norway now.
Last edited by madr (2013-05-18 01:20:50)
Offline
Could you post the output of
$ systemctl | grep 'dhcp'
?
Offline
dhcpcd.service loaded active running dhcpcd on all interfaces
Offline
dhcpcd.service is known to be buggy regarding the interface renaming. It takes control of the network devices before udev can rename them (the interface specific dhcpcd@.service does not have this problem). Why are you even using dhcpcd and netctl at the same time?
Offline
Why are you even using dhcpcd and netctl at the same time?
Well; some residue from the installation process I assume. I'll have a look at it and report back.
Offline
NAME=
That can be overriden by a later rule assignation. Use NAME:= instead, notice the colon.
Offline
madr wrote:NAME=
That can be overriden by a later rule assignation. Use NAME:= instead, notice the colon.
This has nothing to do with his problem, he shouldn't need this rule at all.
Offline
dhcpcd.service is known to be buggy regarding the interface renaming. It takes control of the network devices before udev can rename them (the interface specific dhcpcd@.service does not have this problem). Why are you even using dhcpcd and netctl at the same time?
I tried to disable the dhcpcd.service. The name now appear correct at boot, but I couldn't get a connection. I checked my primary network profile, and that said
IP=dhcp
Can this be it? I then tried to run the
systemctl enable dhcpcd@wlp2s0.service
Now it seems to work perfectly. I'll leave the thread unsolved until I've tried this over a (small) period of time. Like I said; this problem doesn't occur at every boot.
Please give me a heads up if I've done something wrong. I'm still in a learning process, so all hints are highly appreciated. A big thank you to everybody so far.
EDIT:
It seems to be working on every boot now. I'll mark this as solved, and open it again if the problem resurfaces in the next couple of days.
Last edited by madr (2013-05-18 20:09:09)
Offline
Thanks, this thread helped me a lot. I had the same problem, which in its turn caused NetworkManager to fail when connecting to the Wlan. Once I disabled dhcpcd.service, NetworkManager (which does have dhcpcd as dependency) started to work perfectly. In my case I didn't have to enable an interface specific dhcpcd service. Hope that helps anyone.
Offline