The Pull Request was merged, you can grab a next nightly and check. 
Posts by kszaq
-
-
It is a command that disables advertising SAE offload feature by kernel driver. You do not need to replace firmware as described in previous posts, but simply run it and you should be able to run latest nightly. On the other hand, if the issue with WPA3 is solved in the future, you will need to delete this file manually.
I have also made a PR to disable SAE offload for RPi, so if you wait a few days and the PR is accepted, you will be able to simply update the nightly and make no manual changes. I recommended this way, because when the WPA3 issue is solved eventually, the extra parameter will be removed from nigtlies.
My recommendation is to simply wait until the PR is merged or a better way to handle the issue is found.
https://github.com/LibreELEC/LibreELEC.tv/pull/9477 -
I borrowed RPi4 to check a few things. My instructions to replace the firmware were not complete - you also need to create a symlink pointing to the firmware, depending on whether you're using RPi4 or RPi5.
A workaround for the latest nightlies is:
Codeecho options brcmfmac feature_disable=0x400000 > brcmfmac.confThis disables "External auth" feature. Note that WPA3-only network will not work but you should be able to connect to a WPA2/WPA3-mixed network.
-
Thank you for testing. Please remember to remove the firmware overlay, so that in case this issue is solved by any update, your RPi loads a correct one from system image:
Coderm -rf /storage/.config/firmware -
In LibreELEC Settings enable SSH, don't disable password. Default password is 'libreelec'. You should be then able to connect with PuTTy by entering Pi's IP address, login is 'root'.
-
Can you guys check this older firmware that I mentioned earlier? It's quite easy to do but please make sure that you are able to connect to your RPi over ethernet in case this firmware does not work at all!
First, run the nightly with working WiFi, connect over SSH and execute this:
Codemkdir -p /storage/.config/firmware/cypress wget https://github.com/RPi-Distro/firmware-nonfree/raw/ad23f33a29fb7f8bc344d80d0eb40abe1953d145/debian/config/brcm80211/cypress/cyfmac43455-sdio-standard.bin -O /storage/.config/firmware/cypress/cyfmac43455-sdio.binReboot. Check WiFi. If working, update to latest nightly and check WiFi. Please report your result.
In case this firmware breaks WiFi even on older builds, delete it:
Coderm /storage/.config/firmware/cypress/cyfmac43455-sdio.bin -
I wonder if you try an older firmware that does not advertise WPA3 offload, would it work? (sorry, don't know where to put it to work)
brcm80211: cypress: Use a generic CYW43455 firmware · RPi-Distro/firmware-nonfree@ad23f33Cypress/Infineon have recommended switching to their standard firmware releases henceforth. This firmware (version [1]) has the advantage of supporting WPA3…github.com -
I meant revert iwd from 3.0 to 2.22. Or try if previous firmware works better with iwd. I do have WPA3-enabled network but no RPi to check it.
-
It would perhaps be best to revert iwd until this is solved. I suspect you're not the only one using RPi in a WPA3-enabled network.
-
External Auth was merged in iwd 3.0 but it does not work with RPi kernel > 6.6 according to this message:
-
To me it looks like iwd is trying to offload SAE but the firmware only supports doing this with wpa_supplicant, iwd fails to authenticate and does not fallback to WPA2.
Edit: These 2 threads seem to confirm that WPA3 does not work with iwd (yet):
Wi-Fi Protected Access 3 (WPA3) support · Issue #4718 · raspberrypi/linuxI bought a Raspberry Pi Zero 2 W and apparently it does not support my home wifi which uses WPA3. I excepted that to be the case, since on Debian usually works…github.comWPA3 broken on Pi 3 with 6.6 (and works with 6.1) · Issue #6130 · raspberrypi/linuxDescribe the bug When I run a 6.1 kernel on a Pi 3, using IWD, WPA3 works as expected. However, simply switching to the 6.6 kernel breaks this: the interface…github.com -
In the non-working log, the authentication fails:
CodeOct 08 17:42:56.714116 LibreELEC kernel: ieee80211 phy0: brcmf_cfg80211_external_auth: auth_status iovar failed: ret=-52I am scratching my head how this could be related to IPV6_MULTIPLE_TABLES option as it is enabled in many other distros and there are no issues.
One more thing: 56c531c is the first non-working build? If it stopped working in 4b9746e, it would be much easier to blame the iwd update.
-
Do you have Firewall turned on in LE Settings? Please try to turn it off and report if network is back. Thanks.
Edit: Even with previous nightlies, I am unable to see the IPv6 address if network is set to IPv6-only... I'll try to investigate with my limited knowledge.
-
All this VIM3 tom foolery is going to add to the fun of software support especially when they dump it on the market with just the standard Android. A bit of a mess really.
Shoog
It shouldn't be that bad since both S922X and A311 are "G12B".
-
Shoog AFAIK afl1 ported his driver to mainline and balbes150 includes it in his builds. I also prepared packaging for this driver to be included in the future: TEST: add media_tree_aml for out-of-tree DVB drivers · kszaq/LibreELEC.tv@4230427 · GitHub
-
is there a developer here to help and answer questions?
If someone knows an answer, they reply. I guess you are referring to DVB-related questions and I'm afraid there are no many people here who can answer them.
-
How far are we from a working panfrost image for s912?
Hopefully in a few months: Joining Collabora for a summer of Panfrost
-
LE has been working on a release for the VIM3, but I cannot say how ready for prime time it is.
Mainline-based LE also works on Odroid-N2 and it was ready earlier than for VIM3 simply because the Odroid was ready earlier.
It is a work in progress but support for both boards should be almost equal in mainline-based builds. I also think that CE support is a matter of creating a device tree for VIM3 and like you said: most of work for S922X was already done for N2 and every S922X can reuse it.
