Hello,
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 tried to play with few seemingly related wpa_supplication config params, 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. I'm currently reading TI's docs on WL1835MOD (http://processors.wiki.ti.com/index.php/WL18xx) to see if there's anything related, but if someone may have any hints, that would be appreciated.
Thanks, Paul
Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
On 15 March 2015 at 00:35, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
Hello,
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: 1) 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.
Any suggestion?
-Guodong
I'm currently reading TI's docs on WL1835MOD (http://processors.wiki.ti.com/index.php/WL18xx) to see if there's anything related, but if someone may have any hints, that would be appreciated.
Thanks, Paul
Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog _______________________________________________ Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
Hi Guodong,
On 16 March 2015 at 17:31, Guodong Xu guodong.xu@linaro.org wrote:
On 15 March 2015 at 00:35, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
Hello,
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.
Any suggestion?
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 the build: http://builds.96boards.org/snapshots/hikey/android/47
-Guodong
I'm currently reading TI's docs on WL1835MOD (http://processors.wiki.ti.com/index.php/WL18xx) to see if there's anything related, but if someone may have any hints, that would be appreciated.
Thanks, Paul
Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog _______________________________________________ Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
On Thu, 26 Mar 2015 21:25:22 +0530 Vishal Bhoj vishal.bhoj@linaro.org wrote:
Hi Guodong,
On 16 March 2015 at 17:31, Guodong Xu guodong.xu@linaro.org wrote:
On 15 March 2015 at 00:35, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
Hello,
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.
Any suggestion?
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
-Guodong
[]
Paul, Vishal
I'm now upgrading WiFi driver to TI R8.5 release. My local test shows it is much stabler than the current version.
With ELP mode disabled, I verified with my AP over night, - leaving WiFi in connect-ping-disconnect-scan loop, and found no any error. 11g and 11n are both ok as well. But since you reported AP association issue, and you can reproduce that issue 100% for sure (which I never reproduced in my env.) would you please help me verify R8.5 in your environment?
I will send you the driver tar ball in another email, together with instructions.
Appreciate that.
Best regards, Guodong Xu
On 27 March 2015 at 01:20, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
On Thu, 26 Mar 2015 21:25:22 +0530 Vishal Bhoj vishal.bhoj@linaro.org wrote:
Hi Guodong,
On 16 March 2015 at 17:31, Guodong Xu guodong.xu@linaro.org wrote:
On 15 March 2015 at 00:35, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
Hello,
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.
Any suggestion?
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
-Guodong
[]
-- Best Regards, Paul
Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
-
Guodong Xu -
Paul Sokolovsky -
Vishal Bhoj