Re: ath problem

Andy Bontoft wrote:
> Hello,
> I'm unable to get a wireless access point to work properly and for the 
> life of me I can't work out why. I've spent the past few evenings 
> trawling the mailing list archives without much success. I'm hoping 
> someone can point me in the right direction.
> It's an Atheros 5212 (Wistron cm9 miniPCI) in a soekris 4801 box.

5212 Wistron cm9 means nothing; dmesg|grep ath will get you the mac+phy 
revs that identify your part.

> A test client (WinXP SP2) can associate and on occasion obtains an 
> address from the DHCP server on the ether side of the AP. Most of the 
> time it is unable to obtain an address however, and even when it does 
> after a few seconds it changes to the default not connected address of 
> the 169.254/16 network.
> Initially I was trying to configure hostap for wpa+802.1x (EAP_TLS), the 
> 802.1x worked fine and the XP laptop received its address, again after a 
> few seconds the address would revert to the 169.254/16 network. To try 
> and identify the issue I switched to a simple wep mode (without hostap), 
> but I have the same issue. The athstats tool reports a lot of failures.
> I haven't attached pages and pages of debug output as I'm not sure what 
> would be required and don't want to flood the list. I have just attached 
> a few of the basic things, but if more information is required I can 
> obviously supply it.
> Thanks for your time
> andy
> btw - the same laptop works perfectly with an identical config (except 
> the SSID is different) on second 'off the shelf' AP.
> 
> ap# ifconfig ath0
> ath0: flags=8847<UP,BROADCAST,DEBUG,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>        inet6 fe80::20b:6bff:fe35:cb82%ath0 prefixlen 64 scopeid 0x4
>        inet 0.0.0.0 netmask 0xff000000 broadcast 0.255.255.255
>        ether 00:0b:6b:35:cb:82
>        media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <hostap>
>        status: associated
>        ssid Z channel 9 bssid 00:0b:6b:35:cb:82
>        authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit txpowmax 53
>        protmode CTS dtimperiod 1 bintval 100

Run open and simplify your config until you figure out what's wrong. 
Channels 1, 6, and 11 are usually the best for signal w/ 6 preferred. 
Not sure why your ap is using 9.

You don't indicate if the client is using 11g or 11b; based on the 
statistics I'm guessing 11g.

You probably need to setup a 3rd machine and sniff the traffic to see 
what's going on.  Windows has some serious timing requirements in their 
system and if you enable debugging on the ap you may slow things down 
enough that the client will time out.

	Sam

> 
> ap# sysctl net.link.ether.bridge
> net.link.ether.bridge_cfg: "ath0,sis0"
> net.link.ether.bridge_ipfw: 0
> net.link.ether.bridge_ipf: 0
> net.link.ether.bridge.config: "ath0,sis0"
> net.link.ether.bridge.enable: 1
> net.link.ether.bridge.predict: 0
> net.link.ether.bridge.dropped: 0
> net.link.ether.bridge.packets: 0
> net.link.ether.bridge.ipfw_collisions: 0
> net.link.ether.bridge.ipfw_drop: 0
> net.link.ether.bridge.copy: 0
> net.link.ether.bridge.ipfw: 0
> net.link.ether.bridge.ipf: 0
> net.link.ether.bridge.debug: 2
> net.link.ether.bridge.version: 031224
> 
> ap# ./athstats
> 1666 tx management frames
> 5 tx frames discarded prior to association
> 996 tx failed 'cuz too many retries
> 11502 long on-chip tx retries
> 221 tx frames with no ack marked
> 204 tx frames with short preamble
> 57002 rx failed 'cuz of bad CRC
> 136258 rx failed 'cuz of PHY err
>    122418 OFDM timing
>    13840 CCK timing
> 28961 beacons transmitted
> 165 periodic calibrations
> 4 rfgain value change
> 4489 rate control checks
> 5 rate control dropped xmit rate

This is odd; are you using ath_rate_sample?  If there is noise causing 
the rate control code to drop the tx rate then

> rssi of last ack: 19
> avg recv rssi: 33
> 59 switched default/rx antenna
> Antenna profile:
> [1] tx      472 rx     3037
> [2] tx      414 rx       29
>