Per a conversation with Lorenzo, it seems that 802.11w for mt76x[02]u
has only been fixed in 4.20. As 4.19 is a LTS kernel, I'd like to
request that work be backported. While the improvements in 4.20 and
4.21 are already fairly obvious, a lot of people will be running 4.19
for years to come. This is good hardware, with a working driver
(thanks team) but in the next few months excitement is going to turn
toward WPA3 which requires working 802.11w.
Pretty please backport 802.11w support to 4.19
Thanks,
Zero
> Per a conversation with Lorenzo, it seems that 802.11w for mt76x[02]u
> has only been fixed in 4.20. As 4.19 is a LTS kernel, I'd like to
> request that work be backported. While the improvements in 4.20 and
> 4.21 are already fairly obvious, a lot of people will be running 4.19
> for years to come. This is good hardware, with a working driver
> (thanks team) but in the next few months excitement is going to turn
> toward WPA3 which requires working 802.11w.
>
> Pretty please backport 802.11w support to 4.19
IIRC the isse is just on mt76x0u, mt76x2u should work
Regards,
Lorenzo
>
> Thanks,
> Zero
On Thu, Dec 13, 2018 at 9:39 AM Lorenzo Bianconi
<[email protected]> wrote:
>
> > Per a conversation with Lorenzo, it seems that 802.11w for mt76x[02]u
> > has only been fixed in 4.20. As 4.19 is a LTS kernel, I'd like to
> > request that work be backported. While the improvements in 4.20 and
> > 4.21 are already fairly obvious, a lot of people will be running 4.19
> > for years to come. This is good hardware, with a working driver
> > (thanks team) but in the next few months excitement is going to turn
> > toward WPA3 which requires working 802.11w.
> >
> > Pretty please backport 802.11w support to 4.19
>
> IIRC the isse is just on mt76x0u, mt76x2u should work
I can confirm that it does work on mt76x2u on 4.19.5; so my request is
to backport 802.11w (software crypto I believe) support for mt76x0u to
4.19 LTS. Pretty please :-)
Just in case it helps to confirm what is needed, here is the error
from wpa_supplicant when trying to connect to an 802.11w AP
wlan0: WPA: Failed to configure IGTK to the driver
wlan0: RSN: Failed to configure IGTK
thanks,
Zero
>
> Regards,
> Lorenzo
>
> >
> > Thanks,
> > Zero
On 15/12/2018 04:43, Sid Hayn wrote:
> On Thu, Dec 13, 2018 at 9:39 AM Lorenzo Bianconi
> <[email protected]> wrote:
>>
>>> Per a conversation with Lorenzo, it seems that 802.11w for mt76x[02]u
>>> has only been fixed in 4.20. As 4.19 is a LTS kernel, I'd like to
>>> request that work be backported. While the improvements in 4.20 and
>>> 4.21 are already fairly obvious, a lot of people will be running 4.19
>>> for years to come. This is good hardware, with a working driver
>>> (thanks team) but in the next few months excitement is going to turn
>>> toward WPA3 which requires working 802.11w.
>>>
>>> Pretty please backport 802.11w support to 4.19
>>
>> IIRC the isse is just on mt76x0u, mt76x2u should work
>
> I can confirm that it does work on mt76x2u on 4.19.5; so my request is
> to backport 802.11w (software crypto I believe) support for mt76x0u to
> 4.19 LTS. Pretty please :-)
>
Stable kernel are not used to do feature backports but just bug fixes. Please
reach out to your favorite Linux distribution to backport this driver into their
kernel. That's the value add a distro has :)
Regards,
Matthias
> Just in case it helps to confirm what is needed, here is the error
> from wpa_supplicant when trying to connect to an 802.11w AP
> wlan0: WPA: Failed to configure IGTK to the driver
> wlan0: RSN: Failed to configure IGTK
>
> thanks,
> Zero
>
>>
>> Regards,
>> Lorenzo
>>
>>>
>>> Thanks,
>>> Zero
>
> _______________________________________________
> Linux-mediatek mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
>
On Sun, Dec 16, 2018 at 5:39 AM Matthias Brugger <[email protected]> wrote:
>
>
>
> On 15/12/2018 04:43, Sid Hayn wrote:
> > On Thu, Dec 13, 2018 at 9:39 AM Lorenzo Bianconi
> > <[email protected]> wrote:
> >>
> >>> Per a conversation with Lorenzo, it seems that 802.11w for mt76x[02]u
> >>> has only been fixed in 4.20. As 4.19 is a LTS kernel, I'd like to
> >>> request that work be backported. While the improvements in 4.20 and
> >>> 4.21 are already fairly obvious, a lot of people will be running 4.19
> >>> for years to come. This is good hardware, with a working driver
> >>> (thanks team) but in the next few months excitement is going to turn
> >>> toward WPA3 which requires working 802.11w.
> >>>
> >>> Pretty please backport 802.11w support to 4.19
> >>
> >> IIRC the isse is just on mt76x0u, mt76x2u should work
> >
> > I can confirm that it does work on mt76x2u on 4.19.5; so my request is
> > to backport 802.11w (software crypto I believe) support for mt76x0u to
> > 4.19 LTS. Pretty please :-)
> >
>
> Stable kernel are not used to do feature backports but just bug fixes. Please
> reach out to your favorite Linux distribution to backport this driver into their
> kernel. That's the value add a distro has :)
>
That is a valid fact, however, fixing broken 802.11w, a required part
of the standard, feels like a valid bug fix to me. Especially since
in 4.19.5 a patch to fix monitor mode was added for the same driver.
Interestingly when I asked for the monitor mode patch to be ported it
was initially refused and then just kind of happened a few weeks
later. In this case I have a much stronger case, a required feature
of the wifi driver is broken, and this is an LTS kernel.
I also feel compelled to point out that this doesn't matter at all to
me personally. I will be on 4.20 ten seconds after it comes out, but
many many people use distros which run LTS kernels like 4.19 for
years. Those people will be missing a required feature for wpa3, and
APs with support (and certification) are already appearing. So I
close by politely requesting that this bug gets fixed :-)
-Zero
> Regards,
> Matthias
>
> > Just in case it helps to confirm what is needed, here is the error
> > from wpa_supplicant when trying to connect to an 802.11w AP
> > wlan0: WPA: Failed to configure IGTK to the driver
> > wlan0: RSN: Failed to configure IGTK
> >
> > thanks,
> > Zero
> >
> >>
> >> Regards,
> >> Lorenzo
> >>
> >>>
> >>> Thanks,
> >>> Zero
> >
> > _______________________________________________
> > Linux-mediatek mailing list
> > [email protected]
> > http://lists.infradead.org/mailman/listinfo/linux-mediatek
> >
On Mon, Dec 17, 2018 at 10:07:43AM -0500, Sid Hayn wrote:
> Interestingly when I asked for the monitor mode patch to be ported it
> was initially refused and then just kind of happened a few weeks
> later.
It was not quite like that. It was refused to apply on 4.19-rcX due to
-next merge -rc conflict that it will cause. And it was promised
that fixes will be backported thought -stable.
Regarding this case, there is no single commit that add 802.11w support
we could request to add to -stable. It was added together with other
features in:
commit 0ae976a11b4fb5704b597e103b5189237641c1a1
Author: Lorenzo Bianconi <[email protected]>
Date: Thu Sep 6 11:18:41 2018 +0200
mt76x0: init hw capabilities
which depend on switching mt76x0u to mt76-usb layer.
So I'm not sure how this request should be satisfied.
Regards
Stanislaw
On Mon, Dec 17, 2018 at 04:46:28PM +0100, Stanislaw Gruszka wrote:
> On Mon, Dec 17, 2018 at 10:07:43AM -0500, Sid Hayn wrote:
> > Interestingly when I asked for the monitor mode patch to be ported it
> > was initially refused and then just kind of happened a few weeks
> > later.
>
> It was not quite like that. It was refused to apply on 4.19-rcX due to
> -next merge -rc conflict that it will cause. And it was promised
> that fixes will be backported thought -stable.
>
> Regarding this case, there is no single commit that add 802.11w support
> we could request to add to -stable. It was added together with other
> features in:
>
> commit 0ae976a11b4fb5704b597e103b5189237641c1a1
> Author: Lorenzo Bianconi <[email protected]>
> Date: Thu Sep 6 11:18:41 2018 +0200
>
> mt76x0: init hw capabilities
>
> which depend on switching mt76x0u to mt76-usb layer.
>
> So I'm not sure how this request should be satisfied.
Can you check if adding
ieee80211_hw_set(rt2x00dev->hw, MFP_CAPABLE);
is sufficient to add support for 802.11w ?
Most likely it is, since in 4.19 mt76x0_set_key() do not allow to
set unsupported ciphers. However it returns -EINVAL instead of
-EOPNOTSUPP, so I want to be sure.
Thanks
Stanislaw
On Tue, Dec 18, 2018 at 3:09 AM Stanislaw Gruszka <[email protected]> wrote:
>
> On Mon, Dec 17, 2018 at 04:46:28PM +0100, Stanislaw Gruszka wrote:
> > On Mon, Dec 17, 2018 at 10:07:43AM -0500, Sid Hayn wrote:
> > > Interestingly when I asked for the monitor mode patch to be ported it
> > > was initially refused and then just kind of happened a few weeks
> > > later.
> >
> > It was not quite like that. It was refused to apply on 4.19-rcX due to
> > -next merge -rc conflict that it will cause. And it was promised
> > that fixes will be backported thought -stable.
> >
> > Regarding this case, there is no single commit that add 802.11w support
> > we could request to add to -stable. It was added together with other
> > features in:
> >
> > commit 0ae976a11b4fb5704b597e103b5189237641c1a1
> > Author: Lorenzo Bianconi <[email protected]>
> > Date: Thu Sep 6 11:18:41 2018 +0200
> >
> > mt76x0: init hw capabilities
> >
> > which depend on switching mt76x0u to mt76-usb layer.
> >
> > So I'm not sure how this request should be satisfied.
>
> Can you check if adding
>
> ieee80211_hw_set(rt2x00dev->hw, MFP_CAPABLE);
In this case I inferred from cotext that it should be
ieee80211_hw_set(hw, MFP_CAPABLE); hopefully that is correct.
>
> is sufficient to add support for 802.11w ?
As a matter of fact it was sufficient. I can now connect to my AP
with 802.11w required and prior to this one line change I could not.
Thanks for taking the time to suggest this, it seems to work well
enough to connect. I don't much have a means to test to see if deauth
frames are properly handled, do you have any test cases you want to
suggest or are you comfortable enough that it should work properly?
Thanks,
Zero
>
> Most likely it is, since in 4.19 mt76x0_set_key() do not allow to
> set unsupported ciphers. However it returns -EINVAL instead of
> -EOPNOTSUPP, so I want to be sure.
>
> Thanks
> Stanislaw
On Tue, Dec 18, 2018 at 01:38:54PM -0500, Sid Hayn wrote:
> > > Regarding this case, there is no single commit that add 802.11w support
> > > we could request to add to -stable. It was added together with other
> > > features in:
> > >
> > > commit 0ae976a11b4fb5704b597e103b5189237641c1a1
> > > Author: Lorenzo Bianconi <[email protected]>
> > > Date: Thu Sep 6 11:18:41 2018 +0200
> > >
> > > mt76x0: init hw capabilities
> > >
> > > which depend on switching mt76x0u to mt76-usb layer.
> > >
> > > So I'm not sure how this request should be satisfied.
> >
> > Can you check if adding
> >
> > ieee80211_hw_set(rt2x00dev->hw, MFP_CAPABLE);
> In this case I inferred from cotext that it should be
> ieee80211_hw_set(hw, MFP_CAPABLE); hopefully that is correct.
Yeah it is. I copied the line from wrong driver :-)
> > is sufficient to add support for 802.11w ?
> As a matter of fact it was sufficient. I can now connect to my AP
> with 802.11w required and prior to this one line change I could not.
> Thanks for taking the time to suggest this, it seems to work well
> enough to connect. I don't much have a means to test to see if deauth
> frames are properly handled, do you have any test cases you want to
> suggest or are you comfortable enough that it should work properly?
If you using wpa_supplicant, 'wpa_cli disconnect' should
trigger deauth exchange.
Are there errors in dmesg ? If there are many errors, I think
we will need to change EINVAL to EOPNOTSUPP as well.
Thanks
Stanislaw
On Wed, Dec 19, 2018 at 2:47 AM Stanislaw Gruszka <[email protected]> wrote:
>
> On Tue, Dec 18, 2018 at 01:38:54PM -0500, Sid Hayn wrote:
> > > > Regarding this case, there is no single commit that add 802.11w support
> > > > we could request to add to -stable. It was added together with other
> > > > features in:
> > > >
> > > > commit 0ae976a11b4fb5704b597e103b5189237641c1a1
> > > > Author: Lorenzo Bianconi <[email protected]>
> > > > Date: Thu Sep 6 11:18:41 2018 +0200
> > > >
> > > > mt76x0: init hw capabilities
> > > >
> > > > which depend on switching mt76x0u to mt76-usb layer.
> > > >
> > > > So I'm not sure how this request should be satisfied.
> > >
> > > Can you check if adding
> > >
> > > ieee80211_hw_set(rt2x00dev->hw, MFP_CAPABLE);
> > In this case I inferred from cotext that it should be
> > ieee80211_hw_set(hw, MFP_CAPABLE); hopefully that is correct.
>
> Yeah it is. I copied the line from wrong driver :-)
>
> > > is sufficient to add support for 802.11w ?
> > As a matter of fact it was sufficient. I can now connect to my AP
> > with 802.11w required and prior to this one line change I could not.
> > Thanks for taking the time to suggest this, it seems to work well
> > enough to connect. I don't much have a means to test to see if deauth
> > frames are properly handled, do you have any test cases you want to
> > suggest or are you comfortable enough that it should work properly?
>
> If you using wpa_supplicant, 'wpa_cli disconnect' should
> trigger deauth exchange.
politely killing wpa_supplicant also triggers deauth. it didn't error
when it did so, so I'll assume it was happy.
>
> Are there errors in dmesg ? If there are many errors, I think
> we will need to change EINVAL to EOPNOTSUPP as well.
dmesg appears clean.
Thanks,
Zero
>
> Thanks
> Stanislaw