This is 100% what I saw. Sorry, I didn't reply to Guodong right away,On Thu, 26 Mar 2015 21:25:22 +0530
Vishal Bhoj <email@example.com> wrote:
> Hi Guodong,
> 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:
> >> 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?
> 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
> The APs are scanned and listed but authentcation seems to be timing
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:
> > -Guodong