Subject: Re: ath seems still buggy
To: Steven M. Bellovin <>
From: Sam Leffler <>
List: current-users
Date: 10/18/2005 19:26:43
Steven M. Bellovin wrote:
> In message <>, Thor Lancelot Simon writes:
>>On Tue, Oct 18, 2005 at 11:11:39PM +0000, Marcin Jessa wrote:
>>>When it comes to the ath implementation for NetBSD it seems to be there
>>>just for the records. 
>>>Sadly it looks like it can't be used for any serious purpose.
>>That's nonsense.  I use it every day, in NetBSD-current, and it works
>>In fact, I'm typing this through a Soekris with an Atheros wireless
>>module in hostap mode right now.
> Sometimes it works well; other times, it doesn't.  I put in many hours 
> on a wireless connection in my house over the last week; except for 
> eating my battery alive, it worked flawlessly.  A month ago, I was 
> completely unable to acquire carrier at a public hot spot, even though
> wlanctl said that I was receiving a strong signal.  
> It's not useless, but in congested networks it can be pretty close to 
> it.  At the IETF meeting in Paris, I sometimes had to find a wired 
> connection, because it either couldn't acquire or couldn't hold 
> carrier.  Beyond that, even when it's been working, I see frequent 
> instances of carrier drop/carrier restore, with the laptop a meter from 
> the access point.  (Oddly enough, I did not see *anything* like that 
> over this last week.  Maybe recent changes have helped.  I do note, 
> though -- and I'm not the only one -- that my card is running at 36 
> Mbps right now (on 802.11g), even though it's in its usual meter-away
> position.)

Again, anectdotal reports are not helpful.  You haven't even identified 
what hardware you have or what version of the driver you're using. 
There are known issues with "phantom beacon miss" interrupts on 5212 
parts operating in station mode that I have workarounds for.  These 
typically occur during periods of heavy traffic but have also been 
reported at other times.  When you see a link state transition check 
what athstats reports and see if the bmiss count is going up.  In lieu 
of that turn on state transition debugging in the net80211 layer to see 
what's going.

As to rate control one of the first things I noticed in working with 
netbsd current is that the default tx rate control algorithm for ath is 
still onoe and not sample.  This is a likely a cause for significant 
performance loss.  However even the sample algorithm is suboptimal 
compared to other algorithms.  If you compare performance of ath parts 
to the Atheros ndis driver you will see this quite clearly (though there 
are many other factors). John Bickett has improvements to sample that 
only exist right now in the linux code and need to be brought over.

Again, rather than kvetching that something doesn't work provide some 
useful info.