[PATCH] CSA MBSS: CHAN_SWITCH is always failing.

[Benjamin Berg]

Hi,

On Fri, 2023-10-13 at 12:33 +0200, Baligh GASMI wrote:
> > > [SNIP]
> > 
> > I was talking about the internal hostapd state. i.e.:
> > 
> > int hostapd_switch_channel(struct hostapd_data *hapd,
> >                            struct csa_settings *settings)
> > {
> >         int ret;
> > ...
> >         ret = hostapd_drv_switch_channel(hapd, settings);
> >         free_beacon_data(&settings->beacon_csa);
> >         free_beacon_data(&settings->beacon_after);
> > 
> >         if (ret) {
> >                 /* if we failed, clean cs parameters */
> >                 hostapd_cleanup_cs_params(hapd);
> >                 return ret;
> >         }
> > 
> >         hapd->csa_in_progress = 1;
> >         return 0;
> > }
> > 
> > If hostapd_drv_switch_channel fails (which you expect to happen), then
> > csa_in_progress is not set to 1 and hostapd_cleanup_cs_params is
> > called.
> 
> csa_in_progress is per BSS, so if the driver fails on one BSS, it will
> not impact other.
> right?

Yes, csa_in_progress would be set for the first BSS and not the others.
I guess hapd_csa_in_progress actually checks all BSSs, so things might
work fine for the most part?

It may be acceptable to ignore the error on the other BSSs (at least if
they are non-transmitting ones, otherwise we might need to update the
beacon?). I don't want to comment on whether that is right or not.

It just doesn't sit quite right to me to ignore the error in this way.
If simply ignoring it is what you want to do, then wouldn't it be
possible to do so inside the driver code?

Benjamin

> > 
> > 
> > Both of this seem like an undesired side-effect.
> > 
> > Benjamin
> > 
> > > 
> > > I can think about adding CHAN_SWITCH argument, according to which
> > > we
> > > use all BSSes or only the main BSS, but still not global solution
> > > I
> > > think, since we will have to detect driver behaviour to
> > > add/remove
> > > new
> > > arg.
> > > 
> > > Baligh
> > > 
> > 
>