You are not logged in.
Hi,
I ever used wifi-menu(netctl) to set up my usb wifi adapter (TL-WN722N) with the ath9k_htc module. And it ever worked
But today after i upgrade the kernel from 3.14 to 3.15, i have no connections.
Running journalctl -xn i see this messages:
dhcpcd[620]: wlp0s20u3: soliciting a DHCP lease
dhcpcd[620]: timed out
dhcpcd[620]: exited
network[550]:DHCP IP lease attempt failed on interface 'wlp0s20u3'
kernel: wlp0s20u3: desauthenticating from 00:23:69:fd:6d:8a: by local choice (Reason 3=DEFAULT_LEAVING)
kernel: cfg80211: Calling CRDA to update world regulatory domain
network[550]: Failed to bring the network up for profile '1'
systemd[1]: netctl@1.service: main process exited, code=exited, status=1/FAILURE
systemd[1]: Failed to start Automatically generated profile by wifi-menu.
-- Subject: Unit netctl@1.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-level
--
-- Unit netctl@1.service has failed.
--
-- The result is failed
systemd[1]: Unit netctl@1.service entered failed state.
My ip link output is:
...
3: wlp0s20u3: <BROADCAST.MULTICAST> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 100
link/ether f4:ec:38:90:cd:63 brd ff:ff:ff:ff:ff:ff
When i do
ip link set wlp0s20u3 up
everything appear be working, the lights of the card start to blink as normal.
And my netctl profile called 1 is so:
Interface=wlp0s20u3
Connection=wireless
Security=wpa
ESSID=linksys
IP=dhcp
Key= //a lot of numbers
And no i can't downgrade linux kernel cause it's not on my cache
How should i fix it?
Last edited by henriqueleng (2014-06-20 05:43:39)
Emacs - tmux - Cmus - Mutt - Lynx/w3m - ....
Offline
Not a Kernel issue, moving to NC...
What does the journal tell you about why it is failing? You truncated that output so no-one here can help.
Offline
Ok. I completed.
Emacs - tmux - Cmus - Mutt - Lynx/w3m - ....
Offline
Well, if bringing it up manually is working, the problem seems to be with netctl. Try using something decent, like connman...
Offline
Not a Kernel issue, moving to NC...
why so sure? I have the same problem, and downgrading only a kernel to previous 3.14-5 brought my wifi back. NC is definitely not the place.
What does the journal tell you about why it is failing? You truncated that output so no-one here can help.
even though the output is really cut off by OP, there is an error reason
dhcpcd[620]: wlp0s20u3: soliciting a DHCP lease
dhcpcd[620]: timed out
dhcpcd[620]: exited
I have the same on my system too - wpa_supplicant associated with an AP, but dhcpcd just timed out. As I mentioned - I downgraded ONLY the kernel and all started working again.
My adapter is usb TL-WN721N. Here s my logs:
Jun 19 09:10:08 localhost kernel: wlan0: authenticate with 20:7c:8f:97:aa:5d
Jun 19 09:10:09 localhost kernel: wlan0: send auth to 20:7c:8f:97:aa:5d (try 1/3)
Jun 19 09:10:09 localhost kernel: wlan0: authenticated
Jun 19 09:10:09 localhost kernel: wlan0: associate with 20:7c:8f:97:aa:5d (try 1/3)
Jun 19 09:10:09 localhost kernel: wlan0: RX AssocResp from 20:7c:8f:97:aa:5d (capab=0x431 status=0 aid=5)
Jun 19 09:10:09 localhost kernel: wlan0: associated
Jun 19 09:10:09 localhost kernel: IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Jun 19 09:10:08 localhost dhcpcd[1452]: wlan0: carrier acquired
Jun 19 09:10:08 localhost dhcpcd[1452]: DUID 00:01:00:01:1a:25:b0:ab:bc:ae:c5:29:38:c9
Jun 19 09:10:08 localhost dhcpcd[1452]: wlan0: IAID 52:19:9e:61
Jun 19 09:10:08 localhost dhcpcd[1452]: wlan0: soliciting a DHCP lease
/* then nothing happens - dhcpcd just times out like in OP log */
I connect with 2 command shell script:
sudo wpa_supplicant -B -Dwext -iwlan0 -c/etc/wpa_supplicant/wpa_supplicant.conf
sudo dhcpcd -w -4C resolv.conf -t 64 wlan0
After upgrade to 3.15 i've extended dhcpcd timeout to 64 seconds, but it didn't help.
Does it worth mentioning that I can install 3.15, reboot and reproduce? :-)
Offline
Yes, it's really a kernel issue, because the problem just happened after a kernel upgrade. So the problem is the new kernel.
How i have no older kernel in my pacman cache, i have two options. Fix it, or, download an old version of the kernel in other computer.
Emacs - tmux - Cmus - Mutt - Lynx/w3m - ....
Offline
It is easy you could reasd the arch wiki section for downgrading packages (https://wiki.archlinux.org/index.php/Do … g_packages). Use the Arch rollback machine. There is an automatic script in the AUR called "downgrade" to do what it says. it is really easy.
Offline
I have same bug on TL-WN722N in AP (hostapd) mode, and posted it to kernel bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=78581
How kernel architecture are you have: i686 or x86_64?
Last edited by Natrio (2014-06-21 10:55:18)
Offline
Is it this bug? https://bugs.archlinux.org/task/40905
As suggested there if someone affected by it could do a git bisect between 3.14.6 and 3.15.1
Offline
Hi,
I moved to Gentoo, i compiled my own kernel with all my drivers need and now everything is working to me!
I don't know what to do with this post, i think i't will be useful for other people with the same issue, but i don't pretend to write here.
Emacs - tmux - Cmus - Mutt - Lynx/w3m - ....
Offline
Not a Kernel issue, moving to NC...
Definitely a Kernel issue, not a NC post.
The temporary solution is to reload the module disabling hardware encryption:
$ modprobe -r ath9k_htc
$ modprobe ath9k_htc nohwcrypt=1
A patch has been posted here.
Last edited by sardina (2014-06-29 09:34:58)
Offline
A patch has been posted here.
permalink to the specific thread?
EDIT: it's also weird that `modprobe -r ath9k_htc && modprobe ath9k_htc nohwcrypt=1` does not make NetworkManager happy; I have to reboot with the parameter set in modprobe.d/ath9k_htc.conf to make it work. Maybe it's a NetworkManager bug...
Last edited by lolilolicon (2014-06-29 11:22:10)
This silver ladybug at line 28...
Offline
EDIT: it's also weird that `modprobe -r ath9k_htc && modprobe ath9k_htc nohwcrypt=1` does not make NetworkManager happy; I have to reboot with the parameter set in modprobe.d/ath9k_htc.conf to make it work. Maybe it's a NetworkManager bug...
With netctl and ath_9k the same problem arise, and adding nohwcrypt=1 fixes it.
Offline
lolilolicon wrote:EDIT: it's also weird that `modprobe -r ath9k_htc && modprobe ath9k_htc nohwcrypt=1` does not make NetworkManager happy; I have to reboot with the parameter set in modprobe.d/ath9k_htc.conf to make it work. Maybe it's a NetworkManager bug...
With netctl and ath_9k the same problem arise, and adding nohwcrypt=1 fixes it.
By "the same problem" do you mean that, to get a connection, you also have to reboot, instead of simply reloading the module with modprobe?
I thought it (that I had to reboot) was a separate NetworkManager issue that it seemed to fail to start dhcpcd again after the failure.
OTOH, someone suggested that I wasn't doing the bisect correctly. If someone is interested in finding the first bad commit that introdced this bug, feel free to do the bisect yourself. I started with v3.14 as good and v3.15-rc1 as bad.
This silver ladybug at line 28...
Offline
twix wrote:lolilolicon wrote:EDIT: it's also weird that `modprobe -r ath9k_htc && modprobe ath9k_htc nohwcrypt=1` does not make NetworkManager happy; I have to reboot with the parameter set in modprobe.d/ath9k_htc.conf to make it work. Maybe it's a NetworkManager bug...
With netctl and ath_9k the same problem arise, and adding nohwcrypt=1 fixes it.
By "the same problem" do you mean that, to get a connection, you also have to reboot, instead of simply reloading the module with modprobe?
I thought it (that I had to reboot) was a separate NetworkManager issue that it seemed to fail to start dhcpcd again after the failure.
Sorry I thought you meant that the connection problem was only felt with NetworkManager, so please ignore my comment. I did not check whether reloading the module with nohwcrypt=1 when using netctl was working without reboot.
Offline