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.