On Sun, Feb 04, 2018 at 09:54:35PM +0100, Stefan Sperling wrote: > > On Sun, Feb 04, 2018 at 11:15:01AM +0100, Stefan Sperling wrote: > > On Sun, Feb 04, 2018 at 12:01:58AM +0100, Stefan Sperling wrote: > > > I have also briefly tested hostap with both AR9271 and AR7010 and it > > > now seems to work well enough to justify removing the BUGS section from > > > the athn(4) page. > > > > I have to retract the above statement. > > I've done some more testing and hostap mode still has serious problems. > > But it can be fixed later. I've already got some ideas about what's wrong. > > Here is a new version with fixed hostap mode. > > There were two major problems for hostap with the previous code: > > 1) The previous code tried to add each new node to the firmware's table > when an ASSOC request is about to be confirmed. But that is too late. > We need to add the new client to the firmware's node table already > when net80211 tries to acknowledge the AUTH request. > Otherwise our AUTH response will be dropped by the device because it > has no destination node in the firmware. The client will now keep > trying to AUTH, and until it has done so it won't try to ASSOC. > The fix requires a new function hook in net80211 which drivers can set if > they need to do something before an incoming AUTH request is acknowledged. > Some client capabilities are not available this early, so this driver > still needs to update the node's rate set when an ASSOC request is > acknowledged (otherwise we'd break 11n support). > > 2) There is only room for 8 nodes in the firmware's node table. > The previous code used a counter to keep track of nodes added/removed, > but for hostap a counter is insufficient as nodes will show up and leave > in no particular order. > What is needed instead is a bitmask which keeps track of free node slots. > Since there are only 8 slots, we need to be a bit aggressive about removing > inactive clients when the table is full and a new client wants to connect. > However, it is still hard for new clients to steal slots which are being > legitimately used. We rely on net80211's inactivity timer to detect inactive > clients. It takes about a minute or so for a new client to associate to > an AP with a full table and no active clients. I think this is acceptable. > > This diff keeps growing.... Can I commit?
A quick test went fine for me. Tested in hostap mode and client mode with: athn0 at uhub0 port 2 configuration 1 interface 0 "ATHEROS USB2.0 WLAN" rev 2.00/1.08 addr 2 athn0: AR9271 rev 1 (1T1R), ROM rev 13, address xx:xx:xx:xx:xx:xx In client mode, I see TCP download rates go up to 750KB/s; when running an AP with this device, TCP download rates for iwn are a little slower. ok kevlo@
