On 8/30/23 13:14, Johannes Berg wrote:
On Wed, 2023-08-30 at 10:43 +0530, Aditya Kumar Singh wrote:
Why do you even need to set *from userspace* the power mode for a
client? That ... doesn't make that much sense?
Oh so you addressed that here, sorry.
Because there are two possibilities? Default client and also connect to
Low Power Indoor AP as well as sub-ordinate client. So to let the kernel
know which mode originally the client is in, the command was introduced.
I do understand the concern here about possible misuse for the command
from the user space, I would re-visit this area and try to cover the
loop holes if any. But don't you think it should be the case? Basically
same like how we tell via user space the SSID, keys/suite info. freq
list and all for a client, in a similar way tell the power mode.
I just don't understand how userspace would possibly know what to do.
You can't really expect the _user_ to select this. So how does
wpa_supplicant know what to do? How does it know better than the driver?
Where does it get the information from?
The power mode selection for client purely depends on how much tx power
the user wants for the client. In short, subordinate mode type client
can operate on more tx-power when compared to Default mode type client.
For example, let's assume they are going to connect to LPI AP. PSD for
Default client should be -1 dBm/MHz or less and for sub-ordinate client
should be 5 dBM/MHz or less (US regulatory). Technically, the power
mode of client affects the PSD which has indirect relation with the
Tx-power.
So if user wants more PSD, in supplicant, it can be configured with
Subordinate or else default type.
Reg your other question:
> Anyway you're tied to what the AP is doing, no?
Yeah since for AP the command was introduced, leveraged the same for
client to. But now since we have option to leverage from update beacon
infra, something similar for client need to explore.
johannes
