Re: [ath9k-devel] Increasing maximum number of stations in AP mode

2014-04-29 Thread Adrian Chadd
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  wrote:
> Adrian Chadd  freebsd.org> writes:
>
>>
>> On 7 April 2013 13:40, Andrew Connell  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


Re: [ath9k-devel] Increasing maximum number of stations in AP mode

2014-04-29 Thread Gergely Kiss
Adrian Chadd  freebsd.org> writes:

> 
> On 7 April 2013 13:40, Andrew Connell  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


Re: [ath9k-devel] Increasing maximum number of stations in AP mode

2013-04-07 Thread Adrian Chadd
On 7 April 2013 13:40, Andrew Connell  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
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel