You are not logged in.
Hello,
1 of my machines is unable to connect wirelessly to my network now.
It usually is on NetworkManager, and fails at the "setting address" stage.
I switched to manual setup to see where it fails and this I what I have:
ip link set dev wl works
rfkill indicates no block
wpa_supplican connects
BUT
that's where it stops, I cannot get a DHCP lease with either dhclient or dhcpcd.
They both timeout with nothing.
Strangely when I look at my router's log file, I see the requests coming but they are a bit strange, requests coming from this machine are as this:
Jun 28 22:19:28 tomato daemon.info dnsmasq-dhcp[898]: DHCPDISCOVER(br0) 192.168.1.114 <MAC ADDRESS>
Jun 28 22:19:28 tomato daemon.info dnsmasq-dhcp[898]: DHCPOFFER(br0) 192.168.1.114 <MAC ADDRESS>
Jun 28 22:19:44 tomato daemon.info dnsmasq-dhcp[898]: DHCPDISCOVER(br0) 192.168.1.114 <MAC ADDRESS>
Jun 28 22:19:44 tomato daemon.info dnsmasq-dhcp[898]: DHCPOFFER(br0) 192.168.1.114 <MAC ADDRESS>
Jun 28 22:19:51 tomato daemon.info dnsmasq-dhcp[898]: DHCPDISCOVER(br0) 192.168.1.114 <MAC ADDRESS>
Jun 28 22:19:51 tomato daemon.info dnsmasq-dhcp[898]: DHCPOFFER(br0) 192.168.1.114 <MAC ADDRESS>
Jun 28 22:19:59 tomato daemon.info dnsmasq-dhcp[898]: DHCPDISCOVER(br0) 192.168.1.114 <MAC ADDRESS>
Jun 28 22:19:59 tomato daemon.info dnsmasq-dhcp[898]: DHCPOFFER(br0) 192.168.1.114 <MAC ADDRESS>
...
While for machines that connect it looks like this:
Jun 28 22:13:41 tomato daemon.info dnsmasq-dhcp[480]: DHCPDISCOVER(br0) 192.168.1.108 <OTHER MAC ADDRESS>
Jun 28 22:13:41 tomato daemon.info dnsmasq-dhcp[480]: DHCPOFFER(br0) 192.168.1.108 <OTHER MAC ADDRESS>
Jun 28 22:13:41 tomato daemon.info dnsmasq-dhcp[480]: DHCPREQUEST(br0) 192.168.1.108 <OTHER MAC ADDRESS>
Jun 28 22:13:41 tomato daemon.info dnsmasq-dhcp[480]: DHCPACK(br0) 192.168.1.108 <OTHER MAC ADDRESS> <HOSTNAME>
What does the one having issue not send the DHCPREQUEST?
I assume the ACK is coming from the router in exchange for the REQUEST.
Thanks!
Offline
Hi. I had the same issue.
In my case it was caused by this bug: https://bugzilla.kernel.org/show_bug.cgi?id=78581
I solved it by downgrading the kernel, but there is also a workaround: setting the modprobe to "options ath9k_htc nohwcrypt=1" (I haven't yet tested this).
EDIT: The workaround works fine, I've just tested it. Simply create a file named /etc/modprobe.d/ath9k_htc.conf with the line "options ath9k_htc nohwcrypt=1", then reload the ath9k_htc module.
Last edited by fg (2014-07-01 12:02:01)
Offline
the modprobe.d trick worked thanks so much!
I can't believe I didn't even try to rollback the kernel this time...
You saved me!
Offline
Damn, I had not realized another machine had a similar problem.
Although that one could connect to the network every time, it was super slow... using the trick worked there as well!
So thanks again
Offline
Please remember to mark your thread as [Solved] by editing your first post and prepending it to the title.
Offline
Yesterdays update improved WLAN connectivity dramatically for me (which was really an issue last weeks). So you might drop the workaround now...
Offline