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

Reply via email to