Steven M. Bellovin wrote:
> In message <4355847E.6050001@errno.com>, Sam Leffler writes:
> 
> 
>>I'm starting to ramp up involvement in netbsd.  OTOH I typically ignore 
>>complaints unless they include useful info.  Perhaps netbsd folks don't 
>>have ready access to useful tools like athstats, 80211stats and the 
>>equivalent *debug apps--or maybe they're integrated into other programs 
>>(I'm still learning).  The ath support in general is not perfect but it 
>>actually works very well on many systems.  If netbsd folks are having 
>>problems then it should be possible to remedy them.  Of course if you're 
>>not willing to deal with some bumps then by all means fall back to 
>>another card.
>>
> 
> 
> 
> Sam, as far as I know the only diagnostic output we can get is from 
> wlanctl and ifconfig.  Here's the output from my laptop right now -- it 
> associated, but it took a few tries.
> 
> # ifconfig ath0
> ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         ssid yyyyyyyy nwkey xxxxxxxxxxxxx
>         powersave off
>         bssid 00:0f:66:77:73:d3 chan 6
>         address: 00:05:4e:4d:3e:20
>         media: IEEE802.11 autoselect mode 11g (OFDM36 mode 11g)
>         status: active
>         inet 192.168.2.6 netmask 0xffffff00 broadcast 255.255.255.255
>         inet6 fe80::205:4eff:fe4d:3e20%ath0 prefixlen 64 scopeid 0x2
> # wlanctl ath0
> ath0: mac 00:0f:66:75:3d:75 bss 00:0f:66:75:3d:75
>         node flags 0000
>         ess <yyyyyyyy>
>         chan 1 freq 2412MHz flags 00e0<cck,ofdm,2.4GHz>
>         capabilities 0411<ess,privacy,short slot-time>
>         beacon-interval 100 TU tsft 6234588389675 us
>         rates *1.0 *2.0 *5.5 6.0 9.0 *11.0 12.0 18.0 24.0 36.0 48.0 [54.0]
>         assoc-id 0 assoc-failed 2 inactivity 300s
>         rssi 19 txseq 15 rxseq 32672
> ath0: mac 00:0f:66:77:73:d3 bss 00:0f:66:77:73:d3
>         node flags 0001<bss>
>         ess <yyyyyyyy>
>         chan 6 freq 2437MHz flags 00e0<cck,ofdm,2.4GHz>
>         capabilities 0411<ess,privacy,short slot-time>
>         beacon-interval 100 TU tsft 6234441523590 us
>         rates *1.0 *2.0 *5.5 6.0 9.0 *11.0 12.0 18.0 24.0 [36.0] 48.0 54.0
>         assoc-id 49155 assoc-failed 0 inactivity 300s
>         rssi 54 txseq 2 rxseq 26976

Well I suggest this should change.  There is extensive debugging support 
in the ath driver and the net80211 layer.  You can control each with a 
sysctl but the better way is through some tools I wrote for freebsd that 
should port over trivially---athdebug and 80211debug (aka wlandebug). 
With these you can do something like

wlandebug scan+auth+assoc+state

to get debug msgs from the net80211 layer about scanning, 
authentication, association, and state transitions (using msgs to the 
console).  Otherwise the equivalent stats programs show statistics for 
ath and the net80211 layer.  I'm rather anal that any failure is counted 
and usually you can also enable a debug msg to observe failures in realtime.

Folks that want to figure out problems with ath need to first identify 
what card they have using the mac+phy data sent to the console.  Past 
that when someone observes something like their link state dropping 
unexpectedly they can enable debugging and see _why_.  Typically this is 
a normal occurence; e.g. when an ap drops it's association due to 
inactivity, but it can also be caused by a beacon miss.  athstats 
reports bmiss interrupts in the driver; 80211stats/wlanstats reports 
equivalent stuff in the net80211 layer.  Without this kind of 
information it's pretty much impossible to help.

	Sam