RE: [PATCH v8 4/5] wifi: mac80211: start and finalize channel switch on link basis

[Ping-Ke Shih <pkshih@realtek.com>]

> -----Original Message-----
> From: Johannes Berg <johannes@sipsolutions.net>
> Sent: Wednesday, February 21, 2024 4:35 PM
> To: Ping-Ke Shih <pkshih@realtek.com>; 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>; Ryder Lee <ryder.lee@mediatek.com>; Arend van Spriel
> <arend.vanspriel@broadcom.com>; Felix Fietkau <nbd@nbd.name>
> Subject: Re: [PATCH v8 4/5] wifi: mac80211: start and finalize channel switch on link basis
> 
> On Wed, 2024-02-21 at 08:28 +0000, Ping-Ke Shih wrote:
> >
> > > -----Original Message-----
> > > From: Johannes Berg <johannes@sipsolutions.net>
> > > Sent: Wednesday, February 21, 2024 4:20 PM
> > > To: Ping-Ke Shih <pkshih@realtek.com>; 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>; Ryder Lee <ryder.lee@mediatek.com>; Arend van Spriel
> > > <arend.vanspriel@broadcom.com>; Felix Fietkau <nbd@openwrt.org>
> > > Subject: Re: [PATCH v8 4/5] wifi: mac80211: start and finalize channel switch on link basis
> > >
> > > On Wed, 2024-02-21 at 08:19 +0000, Ping-Ke Shih wrote:
> > > > > -----Original Message-----
> > > > > From: Johannes Berg <johannes@sipsolutions.net>
> > > > > Sent: Wednesday, February 21, 2024 4:10 PM
> > > > > To: Ping-Ke Shih <pkshih@realtek.com>; 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>; Ryder Lee <ryder.lee@mediatek.com>; Arend van Spriel
> > > > > <arend.vanspriel@broadcom.com>; Felix Fietkau <nbd@openwrt.org>
> > > > > Subject: Re: [PATCH v8 4/5] wifi: mac80211: start and finalize channel switch on link basis
> > > > >
> > > > > I guess that'd also apply to probe responses? Or does it not send those
> > > > > at all? But we discussed before that maybe we don't have to be perfect
> > > > > there, so I guess we can find some solution to that.
> > > >
> > > > Unfortunately, Realtek firmware doesn't send probe responses at all. Still
> > > > need hostapd to reply those.
> > > >
> > >
> > > Right, but filling in the CSA counters?
> > >
> >
> > No, firmware doesn't modify content of probe response frame.
> >
> 
> Can you get that fixed? ;-)
> 
> With differing beacon intervals etc., I don't know there's a good way to
> keep the counters even with a semblance of correctness, especially if we
> don't know when the beacon was transmitted?
> 
> Or maybe just fill it in the driver since you probably have some beacon
> timing data more easily accessible?

If driver can get CSA or ECSA offset simply, I probably can fill a reasonable
CSA counter (not sure if I can get 100% accurate counter for now), but
seemingly neither ieee80211_tx_control nor ieee80211_tx_info (SKB_CB) doesn't
have these offsets. Any suggestions?

I wonder our out-of-tree driver generates probe response itself. Let's me
check how it does.

Ping-Ke