Search Linux Wireless

Re: [PATCH] wifi: brcmfmac: cfg80211: Use WSEC to set SAE password

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/20/2023 7:14 PM, Hector Martin wrote:


On 2023/12/20 19:20, Kalle Valo wrote:
Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:

Just recently a patch was posted to remove the Infineon list from
MAINTAINERS because that company cares so little they have literally
stopped accepting emails from us. Meanwhile they are telling their
customers that they do not recommend upstream brcmfmac and they should
use their downstream driver [1].

Unquestionably broadcom is not helping maintain things, and I think it
should matter.

As Hector says, they point to their random driver dumps on their site
that you can't even download unless you are a "Broadcom community
member" or whatever, and hey - any company that works that way should
be seen as pretty much hostile to any actual maintenance and proper
development.

Sadly this is the normal in the wireless world. All vendors focus on the
latest generation, currently it's Wi-Fi 7, and lose interest on older
generations. And vendors lose focus on the upstream drivers even faster,
usually after a customer project ends.

So in practise what we try to do is keep the drivers working somehow on
our own, even after the vendors are long gone. If we would deliberately
allow breaking drivers because vendor/corporations don't support us, I
suspect we would have sevaral broken drivers in upstream.

If Daniel and Hector are responsive to actual problem reports for the
changes they cause, I do think that should count a lot.

Sure, but they could also respect to the review comments. I find Arend's
proposal is reasonable and that's what I would implement in v2. We
(linux-wireless) make abstractions to workaround firmware problems or
interface conflicts all the time, just look at ath10k for example. I
would not be surprised if we need to add even more abstractions to
brcmfmac in the future. And Arend is the expert here, he has best
knowledge of Broadcom devices and I trust him.

Has anyone even investigated what it would need to implement Arend's
proposal? At least I don't see any indication of that.

Of course we can implement it (and we will as we actually got a report
of this patch breaking Cypress now, finally).

The question was never whether it could be done, we're already doing a
bunch of abstractions to deal with just the Broadcom-only side of things
too. The point I was trying to make is that we need to *know* what
firmware abstractions we need and *why* they are needed. We can't just
say, for every change, "well, nobody knows if the existing code works or
not, so let's just add an abstraction just in case the change breaks
something". As far as anyone involved in the discussions until now could
tell, this code was just something some Cypress person dumped upstream,
and nobody involved was being responsive to any of our inquiries, so
there was no way to be certain it worked at all, whether it was
supported in public firmware, or anything else.

*Now* that we know the existing code is actually functional and not just
dead/broken, and that the WSEC approach is conversely not functional on
the Cypress firmwares, it makes sense to introduce an abstraction.

Just a quick look in the git history could have told you that it was not just dumped upstream and at least one person was using it and extended it for 802.11r support (fast-roaming):


author	Paweł Drewniak <czajernia@xxxxxxxxx>	2021-08-24 23:13:30 +0100
committer	Kalle Valo <kvalo@xxxxxxxxxxxxxx>	2021-08-29 11:33:07 +0300
commit	4b51de063d5310f1fb297388b7955926e63e45c9 (patch)
tree ba2ccb5cbd055d482a8daa263f5e53531c07667f /drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
parent	81f9ebd43659320a88cae8ed5124c50b4d47ab66 (diff)
download	wireless-4b51de063d5310f1fb297388b7955926e63e45c9.tar.gz
brcmfmac: Add WPA3 Personal with FT to supported cipher suites
This allows the driver to connect to BSSIDs supporting SAE with 802.11r.
Tested on Raspberry Pi 4 Model B (STA) and UniFi 6LR/OpenWRT 21.02.0-rc2.
AP was set to 'sae-mixed' (WPA2/3 Personal).

Signed-off-by: Paweł Drewniak <czajernia@xxxxxxxxx>
Signed-off-by: Kalle Valo <kvalo@xxxxxxxxxxxxxx>
Link: https://lore.kernel.org/r/20210824221330.3847139-1-czajernia@xxxxxxxxx

Here's an example of the case where an abstraction was *not* needed: I
switched over WPA PSK configuration from hex-encoded to binary. That was
needed to make more recent Apple firmwares work. My evidence at the time
that that change *was* at least fairly backwards compatible was that the
OpenBSD driver had been doing it that way all along. Had we introduced
an abstraction/conditional for that case "just in case", it would have
generated superfluous technical debt for no reason.

Fully agreeing here and you already given the argument for that in the commit message. Hence there was no discussion whatsoever about that.

Regards,
Arend

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux