You are not logged in.
Hi,
I'm new to Arch (yesterday night !) and I cannot manage to make the automatic wireless connection works ![]()
The profile is ok (was succesfully created by wifi-menu).
Just after the boot :
journalctl -xn shows no error
# ip link show wlan0
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT qlen 1000
link/ether 00:22:43:42:8b:73 brd ff:ff:ff:ff:ff:ff# netctl status wlan0-Caripoule2
netctl@wlan0\x2dCaripoule2.service - Networking for netctl profile wlan0-Caripoule2
Loaded: loaded (/usr/lib/systemd/system/netctl@.service; static)
Active: inactive (dead)
Docs: man:netctl.profile(5)# systemctl status netctl-auto@wlan0
netctl-auto@wlan0.service - Automatic wireless network connection using netctl profiles
Loaded: loaded (/usr/lib/systemd/system/netctl-auto@.service; enabled)
Active: inactive (dead)
Docs: man:netctl.special(7) # systemctl enable netctl-auto@wlan0
## systemctl start netctl-auto@wlan0
A dependency job for netctl-auto@wlan0.service failed. See 'journalctl -xn' for details.
# journalctl -xn
Aug 23 15:44:35 austin systemd[1]: Reloading.
Aug 23 15:45:33 austin systemd[1]: Expecting device sys-subsystem-net-devices-wlan0.device...
-- Subject: Unit sys-subsystem-net-devices-wlan0.device has begun with start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit sys-subsystem-net-devices-wlan0.device has begun starting up.
Aug 23 15:47:03 austin systemd[1]: Job sys-subsystem-net-devices-wlan0.device/start timed out.
Aug 23 15:47:03 austin systemd[1]: Timed out waiting for device sys-subsystem-net-devices-wlan0.device.
-- Subject: Unit sys-subsystem-net-devices-wlan0.device has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Documentation: http://www.freedesktop.org/wiki/Software/systemd/catalog/be02cf6855d2428ba40df7e9d022f03d
--
-- Unit sys-subsystem-net-devices-wlan0.device has failed.
--
-- The result is timeout.
Aug 23 15:47:03 austin systemd[1]: Dependency failed for Automatic wireless network connection using netctl profiles.
-- Subject: Unit netctl-auto@wlan0.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Documentation: http://www.freedesktop.org/wiki/Software/systemd/catalog/be02cf6855d2428ba40df7e9d022f03d
--
-- Unit netctl-auto@wlan0.service has failed.
--
-- The result is dependency.
# ip link set wlan0 up
# netctl start wlan0-Caripoule2
Job for netctl@wlan0\x2dCaripoule2.service failed. See 'systemctl status netctl@wlan0\x2dCaripoule2.service' and 'journalctl -xn' for details.
# ip link set wlan0 down
# netctl start wlan0-Caripoule2 At this point the wireless network is ok...
Another way to bring the wireless up is to start wifi-menu, then click cancel, then launch : netctl start wlan0-Caripoule2.
I searched in the wiki and in other posts but unfortunately found nothing.
Please, can somebody help ?
Last edited by heecks (2013-08-26 18:22:50)
Offline
one probable issue can be dhcp timing out before getting assigned an ip-address, it's value is by default low (10).
check config file for your wifi profile (in /etc/netctl -- not sure if correct), open it and edit the value of dhcp timeout to a larger value, I have 60 secs. reboot the system then to make sure.
hope it helps !!
Last edited by vik_k (2013-08-23 12:23:40)
"First learn computer science and all the theory. Next develop a programming style. Then forget all that and just hack." ~ George Carrette
Offline
Hi vik_k and thank you for your suggestion.
However, even after rising the DHCP timeout from 10 to 60 seconds (TimeoutDHCP=60 in the wifi profile), I still have the same issue...
Offline
You see the errors that are telling you first:
Expecting device sys-subsystem-net-devices-wlan0.device..
So basically that is telling you that it is waiting on /sys/subsystem/net/devices/wlan0 to show up before proceeding with the units that depend on its existence. But then it goes on to tell you that:
Timed out waiting for device sys-subsystem-net-devices-wlan0.device.
Leading to its failure to start, and therefore the failure of the device to show up. Without a device for netctl to start on, it cannot actually start, so because the dependencies are not present, it fails.
The netctl service units use the BindsTo functionality of system.units. That is, it tells systemd that the success or failure of that given service is totally dependent on the existence of that interface. So if that interface fails to appear, it obviously cannot start.
Long story short, your interface is probably not named wlan0. Systemd has started to use a udev rule to create a persistent naming scheme for network interfaces. For example, my machine has a wlp3s0 and an enp2s0. These names might seem confusing at first, but are actually generated by the physical location of the card itself in the machine. So it will always be the same. On my machine I have a normal ethernet card built into the motherbaord, but I also have a broadcom wireless card. Broadcom wireless cards stick themselves in the eth* kernel namespace for some idiotic reason. So if I didn't have persistent naming, I would end up with eth0 and eth1, but there would be no way to ever tell which was to be assigned to which on a given boot.
This functionality is handles by the /usr/lib/udev/rules.d/80-net-slot-names.rules file. It can be masked by putting a file of the same name into /etc/udev/rules.d that is either a symlink to /dev/null or simply a blank file. Also any custom persistent naming has to be placed before this rule (so number it <80). On one of my machines I call my interfaces ether0 and wifi0 because they ended up with ungodly long persistent names.
I hope that is a decent explanation of what is going on here.
Offline
Right, your interface name must be different. To find out type:
iw dev
This should give you something like
Interface ***
Then you type:
systemctl enable netctl-auto@***.service
systemctl start netctl-auto@***.service
It should be wlp*s0 according to what WonferWoofy said. Mine was wlp2s0 for eg.
We are not the same, I am a MARTIAN!
Offline
Thank you WonderWoofy for the detailed explanation and simbaarch
But unfortunately, my interface really seems to be named wlan0 :
# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT qlen 1000
link/ether 00:23:54:45:50:b0 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT qlen 1000
link/ether 00:22:43:42:8b:73 brd ff:ff:ff:ff:ff:ff
# iw dev
phy#0
Interface wlan0
ifindex 3
wdev 0x1
addr 00:22:43:42:8b:73
type managed
channel 13 (2472 MHz), width: 20 MHz (no HT), center1: 2472 MHzMoreover, I manage to manually start the connection using the name wlan0).
I don't know if it helps but during the installation, my two interfaces were named using the new scheme. After I rebooted on the newly installed system, the interfaces were named the old way (eth0 / wlan0).
Is it possible that the interface names change at some point during the boot process ?
Offline
Maybe you should mask to 80-net-slot-names.rules file just to make absolutely sure that they are going to be using the old naming scheme. It seems like your machine only has one wireless card (which registers in the wlan* namespace) and one ethernet card (which registers itself in the eth* namespace). So having predicable interface naming, in this case, wouldn't actually prove any benefit since they will be consistently named every time anyway.
I have experienced at times my wireless interface still ending up as eth*, though my ethernet card consistenly changes every time. I assume this must be some kind of a race condition, but I am really not entirely sure. If mask that file, they will never experience that name change, and so you will be able to know for certain that the naming scheme is not going to affect the success or failure of the interface names.
Offline
Mark the title of this thread as solved if your problem has been resolved.
We are not the same, I am a MARTIAN!
Offline
Mark the title of this thread as solved if your problem has been resolved.
Did you read the last post from the OP? He/she is still having an issue with this.
Offline
As suggested by WonderWoofy, I replaced /usr/lib/udev/rules.d/80-net-slot-names.rules by a symlink to /dev/null and this did the trick : now the wifi is automatically started at boot.
Many thanks your help !
But still... I do not understand :
- why it does work now although my two interfaces are still named the same as before (eth0 and wlan0).
- why my interfaces were named wlan0 / eth0 before I /dev/nulled /usr/lib/udev/rules.d/80-net-slot-names.rules. I thought that the purpose of this file was to use predictable names ?
Of course, I can live with that, but I have the feeling that this issue was solved the wrong way : I thought it would have ended with my two interfaces being named wlp*s* and enp*s*...
If someone has an idea...
Offline
I can't tell you why it would have been fudging things up in the way that it was. The only plausible guess that I can come up with my my head is that there was some kind of a race between udev's triggering and the actual hardware initialization. But that is just a guess, and I cannot determine in my head why this wuold be the case in your machine but not any number of others. I guess though that it might be the same reason why my network interface sometimes keeps its original kernel namespace.
You masked the 80-net-slot-names.rules file wrong as well. Though this will work for the time being, as soon as there is an update, it is going to be overwritten. The idea of having /usr/lib/udev/rules.d and /etc/udev/rules.d is that the things in the /usr directory are there to be managed by the package manager and contain files that are shipped with your packages. So the /etc directory is for things that the administrator (that's you on your machine) modifies, and typically the things located there are either not shipped by the package (you create them) or they are protected by the backup array of the package. Do pacman -Qii <package> and you will see the stuff that indicates 'MODIFIED' and 'UNMODIFIED' files on the bottom of the output. Those are the files that pacman has a checksum of to determine if any changes have been made.
So if you have a file /usr/lib/udev/rules.d/20-stinky.rules that is shipped with the 'stinky' package (fictional), but you are unhappy with the rules there, you can either copy the file to /etc/udev/rules.d/20-stinky.rules or make your own file of the same name. From then on the one in /usr/lib will not be applied whatsoever because that file that you placed/created now takes precedence over it. So you can then modify the rules or create your own, know that it the ones in the originally shipped file won't be applied, but still not lose those modifications on updates.
So you need to create that symlink to /dev/null as /etc/udev/rules.d/80-net-slot-names.rules. You should also delete the symlink that you created before and touch an empty file there. Otherwise pacman will refuse to upgrade systemd the next time an upgrade comes around. This is because pacman will not replace the symlink with a file (or a directory if that were the case).
This idea of having consistent shipped files with an administrator editable area that takes priority also applies to systemd units. The systemd unit files that ship with packages are in /usr/lib/systemd/system while you can do the same kind of overriding with /etc/systemd/system.
Offline
I put the original file in /usr/lib/udev/rules.d/ and make a symlink in /etc/udev/rules.d and it works fine.
Thank you again for your support and your detailed explanations.
Offline