On Thu, Dec 20, 2018 at 7:30 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Thu, Dec 20, 2018 at 12:47:07PM +0100, Stanislaw Gruszka wrote:
> > commit 0ae976a11b4fb5704b597e103b5189237641c1a1 upstream.
> >
> > This is one line hw feature backport from 0ae976a11b4f ("mt76x0: init
> > hw capabilities"), which add also other different features, however
> > those are not supported in 4.19.
> >
> > 802.11w is supported by mac80211 and mt76x0u driver in 4.19 correctly
> > fall-back to software encryption when 802.11w ciphers are used.
> >
> > Without the patch we fail to associate with WPA3 APs, so this is
> > considered as fix.
> >
> > Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@xxxxxxxxxx>
> > Signed-off-by: Felix Fietkau <nbd@xxxxxxxx>
> > [remove marking non-working features on 4.19, make topic correspond the change]
> > Signed-off-by: Stanislaw Gruszka <sgruszka@xxxxxxxxxx>
> > ---
> > drivers/net/wireless/mediatek/mt76/mt76x0/init.c | 1 +
> > 1 file changed, 1 insertion(+)
>
> What bug is this fixing? This never worked before, so this feels like
> it is adding a new feature.
It is easy to see how this walks the line between "new feature" and
"bug". From a user's perspective, it presents obviously as a bug:
wlan0: WPA: Failed to configure IGTK to the driver
wlan0: RSN: Failed to configure IGTK
When I cannot connect to an AP and wpa_supplicant is throwing
failures, it sure feels like a bug. The line for acceptance shouldn't
be "never worked before" or only regressions would be fixed in stable.
Instead the line should be closer to "this doesn't work and was
expected to work". In 4.19.5 a patch was merged to fix monitor mode
on this driver, which is a far less critical bug than not supporting
802.11w and WPA3. For me I would define "bug" as unexpected failure,
and no where in the wpa_supplicant output does it say this is
unsupported, instead it just plain fails, and failure is a bug.
Again, I agree that it can be seen both ways, but I'm arguing that it's a bug.
Thanks,
Zero
>
> thanks,
>
> greg k-h
