On Thu, 26 Mar 2015 21:25:22 +0530 Vishal Bhoj email@example.com wrote:
On 16 March 2015 at 17:31, Guodong Xu firstname.lastname@example.org wrote:
On 15 March 2015 at 00:35, Paul Sokolovsky email@example.com wrote:
As was noted in recent messages on the list, recent Debian builds (e.g. #118, #124) has WiFi working. However, I had troubles connecting to my Internet access point, with wpa_supplicant (or kernel while running it) throwing timeout errors waiting for AP authentication response.
After fiddling with it, I remembered that the AP is 802.11g, grabbed a 802.11n mobile router, and the HiKey connected to it without issues.
I guess I know what do you mean. When I changed my AP from 11n to 11g (by limiting the channel speed up to 54Mbps/11g instead of 300Mbps/11n), it got much more harder to associate with the AP. In the log, I can see a lot of beacon loss/ reassociation messages, repetitively. But that's not any software issue. My guess that's due to weak signals. 11n got more antennas and new algorithm. So in 11n's case, the physical link quality gets better.
Try echo: echo 0x3C01 > /sys/module/wlcore/parameters/debug_level to see my messages from wlcore. Ref: http://processors.wiki.ti.com/index.php/WL18xx_Driver_Debug
I tried to play with few seemingly related wpa_supplication config params,
wpa_supplicant -B -iwlan0 -c/etc/wpa_supplicant.conf -Dnl80211 That's mine and it works. And my AP is configured to use WPA2-PSK [AES].
but nothing had an effect (btw, it's a bit of chore, because on stop, wpa_supplicant brings wlan0 down, and it's broken after that, not up'able again; "reboot" doesn't work, and there's no hardware reset button, so disconnecting power jack is the only choice). So, I figure the problem is in driver.
It's easy to reproduce this error when you run 'iw wlan0 disconnect', then run 'iw wlan0 scan' repeatedly. But I don't think this is a driver problem. Since,
In my tests, I found so far: all problems can be grouped into two categories:
- wlcore: ERROR SW watchdog interrupt received!
That's a firmware watchdog timer interrupt and reported from FW to the host. 2) wlcore: Scan completed due to error. That's a scan timeout error. By changing the timeout value from 30 seconds to longer does'n help. And again, here I didn't see any SDIO or wlcore driver side errors. The only thing noticeable is just a firmware side timeout.
On Android, I get timeout during authentication: <6>[ 391.982758] wlan0: send auth to 94:fb:b3:b8:f3:c3 (try 1/3) <6>[ 392.062318] wlan0: send auth to 94:fb:b3:b8:f3:c3 (try 2/3) <6>[ 392.124924] wlan0: send auth to 94:fb:b3:b8:f3:c3 (try 3/3) <6>[ 392.186366] wlan0: authentication with 94:fb:b3:b8:f3:c3 timed out
The APs are scanned and listed but authentcation seems to be timing out.
This is 100% what I saw. Sorry, I didn't reply to Guodong right away, because I wanted to back my report with logs, and then got sidetracked. But it's not the case that 802.11g has "weaker" signal than 802.11n, and it takes more attempts to associate to 802.11g. In my setting I get 100% timeout error like the above, and I left it for 30 mins and I only get the same timeouts. I have 5 other WiFi devices, and they connect to the same 802.11g access point without issue.
Vishal, thanks for confirming that. I guess if Guodong was able to connect to 802.11g, then it might depend on some parameters of an AP. So, it would be nice to capture result of a scan, and probably submit all that as a github ticket to track it easier. Vishal, if you could do it, that would be appreciated. I hope to get to it on weekend too.
This is the build: http://builds.96boards.org/snapshots/hikey/android/47