* Max clients on wifi access point with 7265
@ 2018-02-14 10:55 Mickaël PANNEQUIN
2018-02-14 11:30 ` Johannes Berg
0 siblings, 1 reply; 11+ messages in thread
From: Mickaël PANNEQUIN @ 2018-02-14 10:55 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
Hi,
I use a Intel Dual Band Wireless-N 7265. The OS is Linux Debian 8 (Kernel 3=
.16.0-4_amd64).
=20
Do you know the limit of the number of users connected at the same time on =
the wifi? Works fine with 14 connected devices but not more.
How to increase it?
This limit is hardware?
I can't find information about this.
# Technical information
iw list
Wiphy phy0
max # scan SSIDs: 20
max scan IEs length: 393 bytes
Retry short limit: 7
Retry long limit: 4
Coverage class: 0 (up to 0m)
Device supports RSN-IBSS.
Device supports AP-side u-APSD.
Supported Ciphers:
* CCMP (00-0f-ac:4)
* TKIP (00-0f-ac:2)
* WEP40 (00-0f-ac:1)
* WEP104 (00-0f-ac:5)
* CMAC (00-0f-ac:6)
* WPI-SMS4 (00-14-72:1)
Available Antennas: TX 0 RX 0
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
* P2P-client
* P2P-GO
* P2P-device
Band 1:
Capabilities: 0x11e2
HT20/HT40
Static SM Power Save
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 3839 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 4 usec (0x05)
HT TX/RX MCS rate indexes supported: 0-15, 32
Bitrates (non-HT):
* 1.0 Mbps
* 2.0 Mbps (short preamble supported)
* 5.5 Mbps (short preamble supported)
* 11.0 Mbps (short preamble supported)
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
Frequencies:
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (20.0 dBm) (no IR)
* 2472 MHz [13] (20.0 dBm) (no IR)
Band 2:
Capabilities: 0x11e2
HT20/HT40
Static SM Power Save
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 3839 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 4 usec (0x05)
HT TX/RX MCS rate indexes supported: 0-15, 32
VHT Capabilities (0x038071a0):
Max MPDU length: 3895
Supported Channel Width: neither 160 nor 80+80
short GI (80 MHz)
TX STBC
SU Beamformee
VHT RX MCS set:
1 streams: MCS 0-9
2 streams: MCS 0-9
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
VHT RX highest supported: 0 Mbps
VHT TX MCS set:
1 streams: MCS 0-9
2 streams: MCS 0-9
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
VHT TX highest supported: 0 Mbps
Bitrates (non-HT):
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
Frequencies:
* 5180 MHz [36] (20.0 dBm) (no IR)
* 5200 MHz [40] (20.0 dBm) (no IR)
* 5220 MHz [44] (20.0 dBm) (no IR)
* 5240 MHz [48] (20.0 dBm) (no IR)
* 5260 MHz [52] (20.0 dBm) (no IR, radar detection)
DFS state: usable (for 544 sec)
DFS CAC time: 60000 ms
* 5280 MHz [56] (20.0 dBm) (no IR, radar detection)
DFS state: usable (for 544 sec)
DFS CAC time: 60000 ms
* 5300 MHz [60] (20.0 dBm) (no IR, radar detection)
DFS state: usable (for 544 sec)
DFS CAC time: 60000 ms
* 5320 MHz [64] (20.0 dBm) (no IR, radar detection)
DFS state: usable (for 544 sec)
DFS CAC time: 60000 ms
* 5500 MHz [100] (22.0 dBm) (no IR, radar detection=
)
DFS state: usable (for 544 sec)
DFS CAC time: 60000 ms
* 5520 MHz [104] (22.0 dBm) (no IR, radar detection=
)
DFS state: usable (for 544 sec)
DFS CAC time: 60000 ms
* 5540 MHz [108] (22.0 dBm) (no IR, radar detection=
)
DFS state: usable (for 544 sec)
DFS CAC time: 60000 ms
* 5560 MHz [112] (22.0 dBm) (no IR, radar detection=
)
DFS state: usable (for 544 sec)
DFS CAC time: 60000 ms
* 5580 MHz [116] (22.0 dBm) (no IR, radar detection=
)
DFS state: usable (for 544 sec)
DFS CAC time: 60000 ms
* 5600 MHz [120] (22.0 dBm) (no IR, radar detection=
)
DFS state: usable (for 544 sec)
DFS CAC time: 60000 ms
* 5620 MHz [124] (22.0 dBm) (no IR, radar detection=
)
DFS state: usable (for 544 sec)
DFS CAC time: 60000 ms
* 5640 MHz [128] (22.0 dBm) (no IR, radar detection=
)
DFS state: usable (for 544 sec)
DFS CAC time: 60000 ms
* 5660 MHz [132] (22.0 dBm) (no IR, radar detection=
)
DFS state: usable (for 544 sec)
DFS CAC time: 60000 ms
* 5680 MHz [136] (22.0 dBm) (no IR, radar detection=
)
DFS state: usable (for 544 sec)
DFS CAC time: 60000 ms
* 5700 MHz [140] (22.0 dBm) (no IR, radar detection=
)
DFS state: usable (for 544 sec)
DFS CAC time: 60000 ms
* 5720 MHz [144] (disabled)
* 5745 MHz [149] (disabled)
* 5765 MHz [153] (disabled)
* 5785 MHz [157] (disabled)
* 5805 MHz [161] (disabled)
* 5825 MHz [165] (disabled)
Supported commands:
* new_interface
* set_interface
* new_key
* start_ap
* new_station
* new_mpath
* set_mesh_config
* set_bss
* authenticate
* associate
* deauthenticate
* disassociate
* join_ibss
* join_mesh
* remain_on_channel
* set_tx_bitrate_mask
* frame
* frame_wait_cancel
* set_wiphy_netns
* set_channel
* set_wds_peer
* start_sched_scan
* probe_client
* set_noack_map
* register_beacons
* start_p2p_device
* set_mcast_rate
* Unknown command (104)
* connect
* disconnect
Supported TX frame types:
* IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 =
0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x=
90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0x=
a0 0xb0 0xc0 0xd0 0xe0 0xf0
* AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x=
90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* mesh point: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80=
0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80=
0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x9=
0 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80=
0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
Supported RX frame types:
* IBSS: 0x40 0xb0 0xc0 0xd0
* managed: 0x40 0xd0
* AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
* AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
* mesh point: 0xb0 0xc0 0xd0
* P2P-client: 0x40 0xd0
* P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
* P2P-device: 0x40 0xd0
WoWLAN support:
* wake up on disconnect
* wake up on magic packet
* wake up on pattern match, up to 20 patterns of 16-128 by=
tes,
maximum packet offset 0 bytes
* can do GTK rekeying
* wake up on GTK rekey failure
* wake up on EAP identity request
* wake up on 4-way handshake
* wake up on rfkill release
* wake up on TCP connection
software interface modes (can always be added):
* AP/VLAN
* monitor
valid interface combinations:
* #{ managed } <=3D 1, #{ AP, P2P-client, P2P-GO } <=3D 1,=
#{ P2P-device } <=3D 1,
total <=3D 3, #channels <=3D 1
HT Capability overrides:
* MCS: ff ff ff ff ff ff ff ff ff ff
* maximum A-MSDU length
* supported channel width
* short GI for 40 MHz
* max A-MPDU length exponent
* min MPDU start spacing
Device supports TX status socket option.
Device supports HT-IBSS.
Device supports SAE with AUTHENTICATE command
Device supports scan flush.
Device supports per-vif TX power setting
P2P GO supports CT window setting
P2P GO supports opportunistic powersave setting
Driver supports a userspace MPM
=20
lspci | grep "Network"
=20
02:00.0 Network controller: Intel Corporation Wireless 7265 (rev 61)
=20
nano /etc/hostapd/hostapd.conf
=20
country_code=3DFR
driver=3Dnl80211
ssid=3DSSID-TEST
interface=3Dwlan0
hw_mode=3Dg
channel=3D5
wmm_enabled=3D1
auth_algs=3D1
ieee80211n=3D1
ht_capab=3D[SHORT-GI-40][HT40+][HT40-][DSSS_CCK-40][SHORT-GI-20][SHORT-GI-4=
0]
=20
=20
=20
Best regards.=20
=A0 =20
Micka=EBl PANNEQUIN=
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: Max clients on wifi access point with 7265
2018-02-14 10:55 Max clients on wifi access point with 7265 Mickaël PANNEQUIN
@ 2018-02-14 11:30 ` Johannes Berg
2018-02-14 22:04 ` Samuel Sieb
0 siblings, 1 reply; 11+ messages in thread
From: Johannes Berg @ 2018-02-14 11:30 UTC (permalink / raw)
To: Mickaël PANNEQUIN, linux-wireless@vger.kernel.org
On Wed, 2018-02-14 at 10:55 +0000, Mickaël PANNEQUIN wrote:
> Do you know the limit of the number of users connected at the same
> time on the wifi? Works fine with 14 connected devices but not more.
>
> How to increase it?
You can't.
> This limit is hardware?
More or less, yes. The HW/FW can support 16 STAs, but needs two for
other bookkeeping.
johannes
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Max clients on wifi access point with 7265
2018-02-14 11:30 ` Johannes Berg
@ 2018-02-14 22:04 ` Samuel Sieb
2018-02-14 22:36 ` Johannes Berg
2018-02-14 22:38 ` Steve deRosier
0 siblings, 2 replies; 11+ messages in thread
From: Samuel Sieb @ 2018-02-14 22:04 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
On 02/14/2018 03:30 AM, Johannes Berg wrote:
> On Wed, 2018-02-14 at 10:55 +0000, Mickaël PANNEQUIN wrote:
>
>> Do you know the limit of the number of users connected at the same
>> time on the wifi? Works fine with 14 connected devices but not more.
>>
>> How to increase it?
>
> You can't.
>
>> This limit is hardware?
>
> More or less, yes. The HW/FW can support 16 STAs, but needs two for
> other bookkeeping.
As a general question, is there a standard way to determine this limit
for any particular hardware?
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Max clients on wifi access point with 7265
2018-02-14 22:04 ` Samuel Sieb
@ 2018-02-14 22:36 ` Johannes Berg
2018-02-14 22:38 ` Steve deRosier
1 sibling, 0 replies; 11+ messages in thread
From: Johannes Berg @ 2018-02-14 22:36 UTC (permalink / raw)
To: Samuel Sieb, linux-wireless@vger.kernel.org
On Wed, 2018-02-14 at 14:04 -0800, Samuel Sieb wrote:
>
> As a general question, is there a standard way to determine this limit
> for any particular hardware?
That's a good question, but I don't think there is.
johannes
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Max clients on wifi access point with 7265
2018-02-14 22:04 ` Samuel Sieb
2018-02-14 22:36 ` Johannes Berg
@ 2018-02-14 22:38 ` Steve deRosier
2018-02-19 6:07 ` Kalle Valo
1 sibling, 1 reply; 11+ messages in thread
From: Steve deRosier @ 2018-02-14 22:38 UTC (permalink / raw)
To: Samuel Sieb; +Cc: linux-wireless@vger.kernel.org
On Wed, Feb 14, 2018 at 2:04 PM, Samuel Sieb <samuel@sieb.net> wrote:
> On 02/14/2018 03:30 AM, Johannes Berg wrote:
>>
>> On Wed, 2018-02-14 at 10:55 +0000, Micka=C3=ABl PANNEQUIN wrote:
>>
>>>
>>> Do you know the limit of the number of users connected at the same
>>> time on the wifi? Works fine with 14 connected devices but not more.
>>>
>>> How to increase it?
>>
>>
>> You can't.
>>
>>> This limit is hardware?
>>
>>
>> More or less, yes. The HW/FW can support 16 STAs, but needs two for
>> other bookkeeping.
>
>
> As a general question, is there a standard way to determine this limit fo=
r
> any particular hardware?
Yes, but there's no easy way. Put it in AP mode and connect clients to
it until it starts rejecting new clients or dropping the old ones.
Usually while watching it with a sniffer. That's how I've always had
to do it.
Different chips will have different limits, and there's no reliable
way to determine the limit across all chips other than trial and
error. It seems a common desire of people to try to use client chips
as poor-man APs. While it will work for very limited number of
clients, they're not intended as AP chips. If you want something to
work as an AP, I recommend you choose an AP chip.
- Steve
--
Steve deRosier
Cal-Sierra Consulting LLC
https://www.cal-sierra.com/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Max clients on wifi access point with 7265
2018-02-14 22:38 ` Steve deRosier
@ 2018-02-19 6:07 ` Kalle Valo
2018-02-19 9:26 ` Luca Coelho
0 siblings, 1 reply; 11+ messages in thread
From: Kalle Valo @ 2018-02-19 6:07 UTC (permalink / raw)
To: Steve deRosier; +Cc: Samuel Sieb, linux-wireless@vger.kernel.org
Steve deRosier <derosier@gmail.com> writes:
> On Wed, Feb 14, 2018 at 2:04 PM, Samuel Sieb <samuel@sieb.net> wrote:
>> On 02/14/2018 03:30 AM, Johannes Berg wrote:
>>>
>>> On Wed, 2018-02-14 at 10:55 +0000, Micka=C3=ABl PANNEQUIN wrote:
>>>
>>>>
>>>> Do you know the limit of the number of users connected at the same
>>>> time on the wifi? Works fine with 14 connected devices but not more.
>>>>
>>>> How to increase it?
>>>
>>>
>>> You can't.
>>>
>>>> This limit is hardware?
>>>
>>>
>>> More or less, yes. The HW/FW can support 16 STAs, but needs two for
>>> other bookkeeping.
>>
>>
>> As a general question, is there a standard way to determine this limit f=
or
>> any particular hardware?
>
>
> Yes, but there's no easy way. Put it in AP mode and connect clients to
> it until it starts rejecting new clients or dropping the old ones.
> Usually while watching it with a sniffer. That's how I've always had
> to do it.
>
> Different chips will have different limits, and there's no reliable
> way to determine the limit across all chips other than trial and
> error. It seems a common desire of people to try to use client chips
> as poor-man APs. While it will work for very limited number of
> clients, they're not intended as AP chips. If you want something to
> work as an AP, I recommend you choose an AP chip.
We do have wiphy::max_ap_assoc_sta, but I see only ath10k, qtnfmac and
rsi_91x setting it. I wish all drivers would use that.
* @max_ap_assoc_sta: maximum number of associated stations supported in AP=
mode
* (including P2P GO) or 0 to indicate no such limit is advertised. The
* driver is allowed to advertise a theoretical limit that it can reach in
* some cases, but may not always reach.
--=20
Kalle Valo
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Max clients on wifi access point with 7265
2018-02-19 6:07 ` Kalle Valo
@ 2018-02-19 9:26 ` Luca Coelho
2018-02-19 11:18 ` Luca Coelho
0 siblings, 1 reply; 11+ messages in thread
From: Luca Coelho @ 2018-02-19 9:26 UTC (permalink / raw)
To: Kalle Valo, Steve deRosier; +Cc: Samuel Sieb, linux-wireless@vger.kernel.org
On Mon, 2018-02-19 at 08:07 +0200, Kalle Valo wrote:
> Steve deRosier <derosier@gmail.com> writes:
>
> > On Wed, Feb 14, 2018 at 2:04 PM, Samuel Sieb <samuel@sieb.net>
> > wrote:
> > > On 02/14/2018 03:30 AM, Johannes Berg wrote:
> > > >
> > > > On Wed, 2018-02-14 at 10:55 +0000, Mickaël PANNEQUIN wrote:
> > > >
> > > > >
> > > > > Do you know the limit of the number of users connected at the
> > > > > same
> > > > > time on the wifi? Works fine with 14 connected devices but
> > > > > not more.
> > > > >
> > > > > How to increase it?
> > > >
> > > >
> > > > You can't.
> > > >
> > > > > This limit is hardware?
> > > >
> > > >
> > > > More or less, yes. The HW/FW can support 16 STAs, but needs two
> > > > for
> > > > other bookkeeping.
> > >
> > >
> > > As a general question, is there a standard way to determine this
> > > limit for
> > > any particular hardware?
> >
> >
> > Yes, but there's no easy way. Put it in AP mode and connect clients
> > to
> > it until it starts rejecting new clients or dropping the old ones.
> > Usually while watching it with a sniffer. That's how I've always
> > had
> > to do it.
> >
> > Different chips will have different limits, and there's no reliable
> > way to determine the limit across all chips other than trial and
> > error. It seems a common desire of people to try to use client
> > chips
> > as poor-man APs. While it will work for very limited number of
> > clients, they're not intended as AP chips. If you want something to
> > work as an AP, I recommend you choose an AP chip.
>
> We do have wiphy::max_ap_assoc_sta, but I see only ath10k, qtnfmac and
> rsi_91x setting it. I wish all drivers would use that.
>
> * @max_ap_assoc_sta: maximum number of associated stations supported in AP mode
> * (including P2P GO) or 0 to indicate no such limit is advertised. The
> * driver is allowed to advertise a theoretical limit that it can reach in
> * some cases, but may not always reach.
Cool, I hadn't noticed this before. I'll add a patch to iwlwifi to add
it.
--
Cheers,
Luca.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Max clients on wifi access point with 7265
2018-02-19 9:26 ` Luca Coelho
@ 2018-02-19 11:18 ` Luca Coelho
2018-02-27 8:33 ` Kalle Valo
0 siblings, 1 reply; 11+ messages in thread
From: Luca Coelho @ 2018-02-19 11:18 UTC (permalink / raw)
To: Kalle Valo, Steve deRosier; +Cc: Samuel Sieb, linux-wireless@vger.kernel.org
On Mon, 2018-02-19 at 11:26 +0200, Luca Coelho wrote:
> On Mon, 2018-02-19 at 08:07 +0200, Kalle Valo wrote:
> > Steve deRosier <derosier@gmail.com> writes:
> >
> > > On Wed, Feb 14, 2018 at 2:04 PM, Samuel Sieb <samuel@sieb.net>
> > > wrote:
> > > > On 02/14/2018 03:30 AM, Johannes Berg wrote:
> > > > >
> > > > > On Wed, 2018-02-14 at 10:55 +0000, Mickaël PANNEQUIN wrote:
> > > > >
> > > > > >
> > > > > > Do you know the limit of the number of users connected at
> > > > > > the
> > > > > > same
> > > > > > time on the wifi? Works fine with 14 connected devices but
> > > > > > not more.
> > > > > >
> > > > > > How to increase it?
> > > > >
> > > > >
> > > > > You can't.
> > > > >
> > > > > > This limit is hardware?
> > > > >
> > > > >
> > > > > More or less, yes. The HW/FW can support 16 STAs, but needs
> > > > > two
> > > > > for
> > > > > other bookkeeping.
> > > >
> > > >
> > > > As a general question, is there a standard way to determine
> > > > this
> > > > limit for
> > > > any particular hardware?
> > >
> > >
> > > Yes, but there's no easy way. Put it in AP mode and connect
> > > clients
> > > to
> > > it until it starts rejecting new clients or dropping the old
> > > ones.
> > > Usually while watching it with a sniffer. That's how I've always
> > > had
> > > to do it.
> > >
> > > Different chips will have different limits, and there's no
> > > reliable
> > > way to determine the limit across all chips other than trial and
> > > error. It seems a common desire of people to try to use client
> > > chips
> > > as poor-man APs. While it will work for very limited number of
> > > clients, they're not intended as AP chips. If you want something
> > > to
> > > work as an AP, I recommend you choose an AP chip.
> >
> > We do have wiphy::max_ap_assoc_sta, but I see only ath10k, qtnfmac
> > and
> > rsi_91x setting it. I wish all drivers would use that.
> >
> > * @max_ap_assoc_sta: maximum number of associated stations
> > supported in AP mode
> > * (including P2P GO) or 0 to indicate no such limit is advertised.
> > The
> > * driver is allowed to advertise a theoretical limit that it can
> > reach in
> > * some cases, but may not always reach.
>
> Cool, I hadn't noticed this before. I'll add a patch to iwlwifi to
> add it.
Actually this is not so straightforward, because every time we add a
p2p vif, we lose one more station. So the max_ap_assoc_sta value must
be dynamic (or we can state the theoretical lowest number to start
with, which would not be very nice).
I don't think this feature is worth the trouble, so I'll skip it for
now.
--
Cheers,
Luca.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Max clients on wifi access point with 7265
2018-02-19 11:18 ` Luca Coelho
@ 2018-02-27 8:33 ` Kalle Valo
2018-02-27 17:56 ` Steve deRosier
0 siblings, 1 reply; 11+ messages in thread
From: Kalle Valo @ 2018-02-27 8:33 UTC (permalink / raw)
To: Luca Coelho; +Cc: Steve deRosier, Samuel Sieb, linux-wireless@vger.kernel.org
Luca Coelho <luca@coelho.fi> writes:
>> > We do have wiphy::max_ap_assoc_sta, but I see only ath10k, qtnfmac
>> > and
>> > rsi_91x setting it. I wish all drivers would use that.
>> >
>> > * @max_ap_assoc_sta: maximum number of associated stations
>> > supported in AP mode
>> > * (including P2P GO) or 0 to indicate no such limit is advertised.
>> > The
>> > * driver is allowed to advertise a theoretical limit that it can
>> > reach in
>> > * some cases, but may not always reach.
>>
>> Cool, I hadn't noticed this before. I'll add a patch to iwlwifi to
>> add it.
>
> Actually this is not so straightforward, because every time we add a
> p2p vif, we lose one more station. So the max_ap_assoc_sta value must
> be dynamic (or we can state the theoretical lowest number to start
> with, which would not be very nice).
>
> I don't think this feature is worth the trouble, so I'll skip it for
> now.
I think the documentation answers that part pretty well:
"The driver is allowed to advertise a theoretical limit that it can
reach in some cases, but may not always reach."
So I still thank having the drivers to advertise the theoretical maximum
numbers of client is useful, even if it would not be always 100%
correct. For example, an average user most likely will not have any clue
if the limit is 10, 50 or 100 clients. And besides, very few people use
P2P anyway ;)
But of course this is just nice-to-have category cand we have far more
important things to fix first.
--
Kalle Valo
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Max clients on wifi access point with 7265
2018-02-27 8:33 ` Kalle Valo
@ 2018-02-27 17:56 ` Steve deRosier
2018-02-28 12:14 ` Kalle Valo
0 siblings, 1 reply; 11+ messages in thread
From: Steve deRosier @ 2018-02-27 17:56 UTC (permalink / raw)
To: Kalle Valo; +Cc: Luca Coelho, Samuel Sieb, linux-wireless@vger.kernel.org
On Tue, Feb 27, 2018 at 12:33 AM, Kalle Valo <kvalo@codeaurora.org> wrote:
> Luca Coelho <luca@coelho.fi> writes:
>
>>> > We do have wiphy::max_ap_assoc_sta, but I see only ath10k, qtnfmac
>>> > and
>>> > rsi_91x setting it. I wish all drivers would use that.
>>> >
>>> > * @max_ap_assoc_sta: maximum number of associated stations
>>> > supported in AP mode
>>> > * (including P2P GO) or 0 to indicate no such limit is advertised.
>>> > The
>>> > * driver is allowed to advertise a theoretical limit that it can
>>> > reach in
>>> > * some cases, but may not always reach.
>>>
>>> Cool, I hadn't noticed this before. I'll add a patch to iwlwifi to
>>> add it.
>>
>> Actually this is not so straightforward, because every time we add a
>> p2p vif, we lose one more station. So the max_ap_assoc_sta value must
>> be dynamic (or we can state the theoretical lowest number to start
>> with, which would not be very nice).
>>
>> I don't think this feature is worth the trouble, so I'll skip it for
>> now.
>
> I think the documentation answers that part pretty well:
>
> "The driver is allowed to advertise a theoretical limit that it can
> reach in some cases, but may not always reach."
>
> So I still thank having the drivers to advertise the theoretical maximum
> numbers of client is useful, even if it would not be always 100%
> correct. For example, an average user most likely will not have any clue
> if the limit is 10, 50 or 100 clients. And besides, very few people use
> P2P anyway ;)
>
> But of course this is just nice-to-have category cand we have far more
> important things to fix first.
>
>From a practical point-of-view, many chipsets don't advertise this
information. Luca was able to look the limit up or knew it for his
chip. For example, on the ath6kl chips I most commonly have worked
with, the number is not specified by QCA and was only determined by us
via experimentation. And even on the same chip, it'll change with
firmware version as the necessary resources get consumed by new
features or fixes. If the firmware can send that number up to the
driver (or the driver can reliably know it because it can't change),
then expose it, but otherwise I'd advise publishing a value of 0. I'd
rather see the unknown flag rather than relying on a number that may
or may not be accurate.
- Steve
--
Steve deRosier
Cal-Sierra Consulting LLC
https://www.cal-sierra.com/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Max clients on wifi access point with 7265
2018-02-27 17:56 ` Steve deRosier
@ 2018-02-28 12:14 ` Kalle Valo
0 siblings, 0 replies; 11+ messages in thread
From: Kalle Valo @ 2018-02-28 12:14 UTC (permalink / raw)
To: Steve deRosier; +Cc: Luca Coelho, Samuel Sieb, linux-wireless@vger.kernel.org
Steve deRosier <derosier@gmail.com> writes:
> On Tue, Feb 27, 2018 at 12:33 AM, Kalle Valo <kvalo@codeaurora.org> wrote:
>> Luca Coelho <luca@coelho.fi> writes:
>>
>>>> > We do have wiphy::max_ap_assoc_sta, but I see only ath10k, qtnfmac
>>>> > and
>>>> > rsi_91x setting it. I wish all drivers would use that.
>>>> >
>>>> > * @max_ap_assoc_sta: maximum number of associated stations
>>>> > supported in AP mode
>>>> > * (including P2P GO) or 0 to indicate no such limit is advertised.
>>>> > The
>>>> > * driver is allowed to advertise a theoretical limit that it can
>>>> > reach in
>>>> > * some cases, but may not always reach.
>>>>
>>>> Cool, I hadn't noticed this before. I'll add a patch to iwlwifi to
>>>> add it.
>>>
>>> Actually this is not so straightforward, because every time we add a
>>> p2p vif, we lose one more station. So the max_ap_assoc_sta value must
>>> be dynamic (or we can state the theoretical lowest number to start
>>> with, which would not be very nice).
>>>
>>> I don't think this feature is worth the trouble, so I'll skip it for
>>> now.
>>
>> I think the documentation answers that part pretty well:
>>
>> "The driver is allowed to advertise a theoretical limit that it can
>> reach in some cases, but may not always reach."
>>
>> So I still thank having the drivers to advertise the theoretical maximum
>> numbers of client is useful, even if it would not be always 100%
>> correct. For example, an average user most likely will not have any clue
>> if the limit is 10, 50 or 100 clients. And besides, very few people use
>> P2P anyway ;)
>>
>> But of course this is just nice-to-have category cand we have far more
>> important things to fix first.
>>
>
> From a practical point-of-view, many chipsets don't advertise this
> information. Luca was able to look the limit up or knew it for his
> chip. For example, on the ath6kl chips I most commonly have worked
> with, the number is not specified by QCA and was only determined by us
> via experimentation. And even on the same chip, it'll change with
> firmware version as the necessary resources get consumed by new
> features or fixes. If the firmware can send that number up to the
> driver (or the driver can reliably know it because it can't change),
> then expose it, but otherwise I'd advise publishing a value of 0. I'd
> rather see the unknown flag rather than relying on a number that may
> or may not be accurate.
Yeah, definitely. The value needs to be based on facts, not guesses.
--
Kalle Valo
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2018-02-28 12:14 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-02-14 10:55 Max clients on wifi access point with 7265 Mickaël PANNEQUIN
2018-02-14 11:30 ` Johannes Berg
2018-02-14 22:04 ` Samuel Sieb
2018-02-14 22:36 ` Johannes Berg
2018-02-14 22:38 ` Steve deRosier
2018-02-19 6:07 ` Kalle Valo
2018-02-19 9:26 ` Luca Coelho
2018-02-19 11:18 ` Luca Coelho
2018-02-27 8:33 ` Kalle Valo
2018-02-27 17:56 ` Steve deRosier
2018-02-28 12:14 ` Kalle Valo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).