Re: [ath9k-devel] Increasing maximum number of stations in AP mode
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
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
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