Message-ID: <8512c5c275dbbb9f3f9d5e946905c3a3fc35457b.camel@sipsolutions.net>
Subject: Re: [PATCH v2] wifi: mac80211: support poll sta for ML clients
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Sriram R <quic_srirrama@quicinc.com>
Cc:     linux-wireless@vger.kernel.org
Date:   Tue, 14 Feb 2023 13:48:01 +0100
In-Reply-To: <20230119221240.24441-1-quic_srirrama@quicinc.com>
References: <20230119221240.24441-1-quic_srirrama@quicinc.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.3 (3.46.3-1.fc37) 
MIME-Version: 1.0
Precedence: bulk

On Fri, 2023-01-20 at 03:42 +0530, Sriram R wrote:
> Update the client probe handling which sends Null data
> frames to check inactivity to support ML Stations as well.
>=20
> Replace the use of default bss conf with the link specific
> conf and use the stations default link to send the probe
> frame. Non ML Stations associated to the ML AP would use
> its default link as well which is one of the active links.
>=20
> For Non ML AP, the default link id is 0 and it is taken care
> as well.

This seems very wrong.

It seems like if we have a link here then userspace should pick it.

But! The station could have disabled that link, for example, after
having used it for association. The station always has the deflink used
(unlike vif) but there's nothing that says that it must actually be
active at any given time.

However that obviously means userspace _cannot_ pick it.

And then really it means we should address this frame to the MLD and let
driver/firmware pick the right link, and do address translation on it,
etc.

After all, we want to know the MLD is still there, not a specific STA,
right?

johannes