Max clients on wifi access point with 7265

Max clients on wifi access point with 7265

[Mickaël PANNEQUIN]

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=

Re: Max clients on wifi access point with 7265

[Johannes Berg]

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

Re: Max clients on wifi access point with 7265

[Samuel Sieb]

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?

Re: Max clients on wifi access point with 7265

[Johannes Berg]

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

Re: Max clients on wifi access point with 7265

[Steve deRosier]

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/

Re: Max clients on wifi access point with 7265

[Kalle Valo]

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

Re: Max clients on wifi access point with 7265

[Luca Coelho]

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.

Re: Max clients on wifi access point with 7265

[Luca Coelho]

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.

Re: Max clients on wifi access point with 7265

[Kalle Valo]

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

Re: Max clients on wifi access point with 7265

[Steve deRosier]

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/

Re: Max clients on wifi access point with 7265

[Kalle Valo]

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