If this isn't documented clearly enough, it should likely be documented better. :)
That said, it's a relatively big firmware API change to make the API much lighter (and yay, that means more buffers in the long run) and just treat it as a transmit/receive offload with the rest being register access. But, it needs some further planning. -a On 29 April 2014 11:29, Gergely Kiss <mail.g...@gmail.com> wrote: > Adrian Chadd <adrian <at> freebsd.org> writes: > >> >> On 7 April 2013 13:40, Andrew Connell <andrew.connell <at> gmail.com> wrote: >> > Hi, >> > I'm interested in modifying the firmware so as to increase the number of >> > stations that can be connected when an ath9k device is in AP mode. >> > Currently, after 7 devices are connected, whenever another device tries to >> > connect, hostapd shows "Could not add STA to kernel driver". I understand >> > this is a firmware issue and I've been told that I can modify the firmware >> > to get around this -- is this the case? I can't imagine why there'd be such >> > a low limit without good reason. >> > I managed to build and install the 1.4 firmware but it suffers from the >> > same >> > issue, if someone could give me a pointer on where to find the appropriate >> > part so I can increase the limit (if it's indeed possible), it'd be much >> > appreciated. >> >> Well, the firmware is open so you can go and take a look at exactly >> what kind of state is being kept in the firmware. >> >> Right now the state includes rate control and TX retransmission, so >> it's quite plausible you'll hit memory exhaustion limits there. >> >> Felix (and I, increasingly) are thinking of evolving the firmware to >> not keep that kind of state in the firmware and leave it up to the >> host. That way we can run much more than 7 stations in AP mode as all >> the firmware will be doing is the acting as a data pipe. I think we >> may still want to do retransmission in firmware to get around some >> latency issues, but only very simple retransmission. Anything else >> gets complicated when you want to do any kind of fair queuing.) >> >> But, yes, you have the source. I encourage people to go look at it and >> document what they find. >> >> adrian >> > > Dear List, > > sorry about digging up such an old thread but this limitation caused me some > serious trouble in a project I've been working on recently and just wanted > to make a note about it for other people. > > I'm not sure if all ath9k based chipsets are involved but I can confirm that > the limitation still exists, at least for wifi dongles using the AR9271 > chipset. > > Moreover, I noticed that once the 7th station is associated, no more > stations can connect even if all the others disassociate until the interface > is brought down and then back up. > > I love Atheros-based devices as they still are amongst the best quality > wireless chips on the market but this limitation drove me pretty mad as I > got to know about it after the project went live. > > Do you have any plans to fix this as it was suggested by Adrian? > > Regards, > Gergely > > _______________________________________________ > ath9k-devel mailing list > ath9k-devel@lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel