Received-SPF: pass (google.com: domain of linux-wireless+bounces-3458-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <f7174207668cac149246cafa0e4b4749ee3289f0.camel@sipsolutions.net>
Subject: Re: [PATCH v8 4/5] wifi: mac80211: start and finalize channel
 switch on link basis
From: Johannes Berg <johannes@sipsolutions.net>
To: Aditya Kumar Singh <quic_adisi@quicinc.com>
Cc: linux-wireless@vger.kernel.org, Jeff Johnson
 <quic_jjohnson@quicinc.com>,  Ilan Peer <ilan.peer@intel.com>, Jouni
 Malinen <j@w1.fi>, Ping-Ke Shih <pkshih@realtek.com>, Ryder Lee
 <ryder.lee@mediatek.com>
Date: Mon, 12 Feb 2024 15:46:25 +0100
In-Reply-To: <b2cf5c1d-7842-4e59-b25a-904a6879fa9c@quicinc.com>
References: <20240130140918.1172387-1-quic_adisi@quicinc.com>
	 <20240130140918.1172387-5-quic_adisi@quicinc.com>
	 <b73dd1f9c23c164179c38e2109aa1550d87e87ed.camel@sipsolutions.net>
	 <646d1e3e404a437f4c99c80996eb4f194ac242b8.camel@sipsolutions.net>
	 <26df9aa6-e497-4040-ad5c-c647454acca6@quicinc.com>
	 <b2cf5c1d-7842-4e59-b25a-904a6879fa9c@quicinc.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.3 (3.50.3-1.fc39) 
Precedence: bulk
MIME-Version: 1.0

On Mon, 2024-02-12 at 12:48 +0530, Aditya Kumar Singh wrote:

> My bad! I see you have applied the changes. Thanks :)

Right, sorry that wasn't clear.

> Looks good to me.

OK, thanks for checking.

> Let me see on the hwsim test cases and if possible=20
> send it soon for review to Jouni.

So ... I'm looking at the client side, and thinking about that.
According to the spec, multi-link element should be present in beacons
of APs affiliated with the same MLD if one of the (other) links is doing
CSA, and then have also the CSA counters of course, relative to the
target link's TBTT (of course.)

Theoretically, both mac80211 and hostapd today support different beacon
interval on different links, I believe.

This makes the whole thing of including CSA for link A on beacons/probe
responses transmitted on link B very tricky, because you have to know
the timing, etc.

For the CSA counter of a link _itself_ we have counter_offsets_beacon
and counter_offsets_presp (for probe response offload) in struct
cfg80211_csa_settings, and also counter offsets in struct
cfg80211_mgmt_tx_params for sending probe responses.

But ... for the cross-link information in the MLE this gets way more
tricky? Especially if the beacon interval is different - we couldn't
just count down, we'd have to fill in the information when we know where
the frame is transmitted. For probe responses maybe we can afford to not
be perfect, but for beacons it better be right - so we have to calculate
the right counter value(s) for (all of) the switching link(s) according
to the current TSF, TSF offset and TBTT - not all of which we even have
in the driver?

I can see a few ways of implementing this:

 a) Punt to firmware and it parses the multi-link element etc. to
    find the places to update. But that's awful, it requires parsing
    possibly fragmented MLE with fragmented subelements containing the
    CSA elements inside ...

 b) Punt to firmware and give it a (possibly long) list of offsets K_N
    where to put the N'th counter for link K when transmitting the
    frame.

 c) Require the get_tsf operation and add an operation to retrieve TSF
    offset (**), and then calculate the TBTT for each link when
    beacon_get is called with the per-link beacon intervals and update
    the values correctly if CSA is in progress on any link ... requires
    against parsing like in (a) or offset information like in (b), but
    at least now it's in software?
    For probe responses this could be a bit off I guess, but maybe that
    doesn't matter as much - probe responses are not authenticated so a
    client probably shouldn't use them for real CSA anyway.

    (**) which I guess we need anyway for hostapd to put it into beacons
    etc.?

 d) Require beacon intervals to be the same, and then just count down?
    Still requires the offset information etc., but that's also not
    great because if the configuration happens during a TBTT on any of
    the links (some before, some after), it'll be very wrong. So not
    very inclined to do this one ...


Do you have any plans for any of this?

I'm mostly asking right now because I want a reliable way to test the
work I'm trying to do on the client side though, so I could also live
with some hacks (inject through debugfs?), but having it for real would
be nice.

johannes