WLAN: current status and new bits of weirdness

Philip Rhoades phil at pricom.com.au
Thu Feb 19 06:51:16 CET 2009


Werner,


Werner Almesberger wrote:
> Three of the current WLAN problems appear to be caused by flaws in the
> firmware. I've reported them to Atheros and they're looking into the
> issues. Specifically, these are:
> 
> - Target assertion at line 0x393
> - Target assertion at line 0x87A
> - AR6k sometimes associates at the wrong channel when roaming
> 
> The target associations are serious because all we can do to recover
> from them is to reset the module. The channel problem causes obscure
> performance degradation when it happens, but it seems to need a fairly
> exotic environment to occur and may not matter all that much in real
> life.
> 
> There are two more issues that I'm currently investigating:
> 
> - sometimes, the key exchange of wpa_supplicant fails, causing
>   indefinite attempts to associate.
> 
>   So far, this appears to happen only when I do one successful
>   association, get a DHCP lease, and then restart wpa_supplicant.
>   I've also only seen it with a WRT54G running the orignal Linksys
>   firmware, but not with a PC acting as AP.
> 
>   The key exchange fails because the answers wpa_supplicant thinks
>   it's sending apparently never get put in the air, but I don't
>   know yet where exactly they get lost.
> 
> - FSO MS5 is reported to have troubles with WPA as well. I haven't
>   reproduced this one yet.


While trying to debug WiFi uptime issues using:

   wlan-trial-20090206.uImage
   openmoko-fso-image-glibc-ipk--20090202-om-gta02.rootfs.jffs2

I have been trying to use the following u-boot (NOR) CLI commands:

   setenv bootargs_base ${bootargs_base} log_buf_len=2M
   setenv bootcmd setenv bootargs \${bootargs_base} \${mtdparts}\; nand 
read.e 0x32000000 kernel 0x300000\; bootm 0x32000000
   boot

even WITHOUT the backslash that I had previously before the "$" in line 
one, this line still seems to be a problem - at each boot, I STILL get 
the FR taking forever to start with hundreds of lines like:

   [xxxx:yyyyyy] r5:.... r4:.....
   [xxxx:yyyyyy] ..... kernel ....
   [xxxx:yyyyyy] r5:0000... r4:0000.....

Do you want me to try anything else with this setup or should I just 
start testing the uptime on more recent images?

Regards,

Phil.
-- 
Philip Rhoades

GPO Box 3411
Sydney NSW	2001
Australia
E-mail:  phil at pricom.com.au



More information about the devel mailing list