Possible. A good way to check this is with LinSSID - you can install with
sudo pacman -S linssid
and it gives a nice display showing in-range networks, their signal strength and channel/bandwidth for both 2.4 and 5GHz bands.
It’s (been) quite common for routers to set themselves to crowded channels. Mine have done this on at least a couple of occasions, causing issues. It’s possible that signal interference could be messing up the authentication process.
I think everyone’s chasing wild geese here. If you can get 5 GHz access from the live USB, then it’s not your router.
I suspect a configuration file corruption, and given your error message about “secrets” and the fact that you’re on Plasma, I suspect it would be kwallet which has messed up.
Negative. As an unprivileged user, your account has no write access to system-wide configuration files under /etc. Whatever got corrupted is located in your home directory.
Long story short, these solutions didn’t work either, and there isn’t an emoji sad enough to capture this moment.
Thank you, such a good idea this one! But unfortunately after disabling the kwallet, rebooting the computer, etc., it still can’t connect with 5GHz networks.
It didn’t work either, so I tried reinstalling the network manager:
sudo pacman -S networkmanager plasma-nm
Which also didn’t work.
I have no idea what my neighbours are doing in the 5GHz range, or maybe my house is made of lead, but there’s almost zero interference. My wifi must be so lonely.
Fun takeaway from this though: It revealed that my router’s guest network is on 2.4GHz (I totally forgot, even though I set it up that way). It connects just fine! So this rules out (I believe) router rejection of my MAC address too.
However, there is a lot of interference in the 2.4GHz range, heaps of wifi networks (my neighbours have wifi after all)… I really don’t want to ignore the main problem and use this workaround if I can avoid it…
Shall we continue, or should I just take the easy way out and reinstall Manjaro?
Awwww, my Plasma customisations… the thought of reconfiguring it all is like reopening a wound that just finished healing.
That’s what separate home partitions are for, alternatively you can backup your user data and config (and any system wide config files that you’ve modified).
Hmm - I have been around this topic a few times - checking on it from time to time.
I have a similar device - a MacBook Pro 2017 with an i5.
A few years back when Apple announced the support for the device was ending with Ventura, I took another look into running Manjaro on the device and while you can get a reasonably functional device. The annoyances begin when you attempt to get the extras - sound, wifi and touchbar working.
Seriously knowledge not to mention time has been put into reverse engineering those parts with varying success.
I sincerely think it is a serious waste of time because Apple has never released any implementation details of the hardware. Devices such as the Broadcom 43602 SoC can be implemented any number of ways as the system vendor (Apple) chooses to.
This means that even though the device has kernel support - the actual implementation done by Apple may be actively working against the user.
From Broadcom brcmsmac(PCIe) and brcmfmac(SDIO/USB) drivers — Linux Wireless documentation
| BCM43602 | 14e4:43ba | Supported in 3.17+ |
| BCM43602 | 14e4:43bb | Supported in 3.19+, 2 GHz device |
| BCM43602 | 14e4:43bc | Supported in 3.19+, 5 GHz device |
| BCM43602 | 14e4:aa52 | Supported in 4.2+, “raw” device |
Booting my system, using the most recent official ISO, does not provide a working WiFi connection. If your MacBook using the same WiFi chip but a different CPU points to the aforementioned implementation details. It may be by sheer luck and coincidence that you can get the WiFi to connect to your access point.
When you boot the ISO on the system - when the WiFi is in a working state - it would be nice to see the content from
cat /var/log/manjaro-live.log | curl -F 'file=@-' https://0x0.stcat /var/log/mhwd-live.log | curl -F 'file=@-' https://0x0.stPlease provide the urls returned to the prompt
You may inspect the files - but I suspect the kernel driver is used for your WiFi. See Broadcom wireless - ArchWiki
The output from this - would indicate which driver is used - most likely brcmfmac which is the kernel driver.
lsmod | grep brcm
The fact that the system recognise the device but is unable to connect because the passphrase is not provided in the correct format points to implementation rather than driver error.
As we speak - I am experimenting on how to successfully connect to a 5GHz network - using that MacBook Pro 2017 with i5/Iris GPU.
Another thought on the ‘working on live ISO’ - when you boot your MacBook using the option key to select boot media - do you also connect to the wireless network?
If you do - that will explain why the WiFi appear to be working in the installer environement.
As I wrote above - getting the WiFi to work is cumbersome and not worth the effort - the same goes for the touchbar and bluetooth. Unless you have an academic interest in pursuing the goal of getting Apple hardware to play ball with Linux - I strongly suggest you buy some cheap USB device and plug it while booting the device, plugging it on the fly may not work - at least my USB-C ethernet adapter don’t - must be present at boot time to work.
Apple don’t want their devices to run anything but Apple’s own OS and they don’t want their OS to run on anything but Apple devices.
I think it’s not just a matter of disabling it, but rather of deleting its configuration files — after first having made a copy of them — and starting all over again.
Note: You will have to be doing this from a tty while not logged into the GUI.
Reinstalling a software package won’t work, because that will only overwrite system-wide configuration files, and only if they haven’t been modified away from the defaults.
As I said, the corruption is most likely to be found in your home directory.
You don’t need to wipe everything. You only need to find and delete the corrupted files. A full system reinstallation would be overkill.
There are a number of very active groups of users on github to get this done.
Until now, I didn’t have forum privileges to post links, but now I can finally share the gist I published so people can get all of those things―wifi, sound, touchbar (and therefore camera)―working.
Gist: Arch Linux / Manjaro on MacBook Pro 14,3 (2017, Touch Bar)
The wifi, in particular, is the fastest and easiest thing to enable, no internet required! (the research to make the script, on the other hand, was relentless)
So hopefully this will make it easier for people to scrutinise my setup.
Edit: So long as you know your MAC address (and country code), the script is the first thing I do after booting up the LiveUSB.
Please forgive me for implying that the LiveUSB has working wifi out of the box.
Oh that’s brilliant, I’ll get on to doing that.
Although, is associating a fresh OS installation with an existing home directory partition straightforward? For example, would the installation attempt to overwrite my config files?
Or would I install with a dummy account, and somehow hook up the partition account to it?
Ahem, I should probably search the answers to these questions myself 
This make sense, thank you. I’ll try this and report back again!
This is the reassurance I needed, thank you! I’ll keep trying!
Can you exclude a packet filter problem (nftables, iptabes, ip6tables …)?
Note that if you do go down the road of reinstalling and going with btrfs — as you said you would — then you don’t need to create separate partitions, because the installer will create separate subvolumes for… 
/ (subvolume @)/home (subvolume @home)/var/cache (subvolume @cache)/var/log (subvolume @log)The rationale is that timeshift will by default only create snapshots of the @ subvolume, so that you can roll back your system to a previous state without losing any recent changes to the files in your home directory, and while also preserving your system log, so that you can inspect it for what went wrong.
And of course /var/cache is redundant data, which can be recreated, so it doesn’t need to be snapshotted.
Do however bear in mind that snapshots are intended as rollback points — they are not backups — and you should have a separate (and real) backup strategy for anything under /home.
Plasma-related configuration files in your home directory will normally be recreated with the system-default values if you delete them.
But you should only delete them when logged out of Plasma, because as long as Plasma is running, the potentially corrupted data will still be held in memory as buffers, and will be written back to the files upon logging out.
Here’s what I would recommend… Create a new user account alongside of your existing one, and log into that. Then, check whether your WiFi works as desired.
If it does, start comparing the related files between both accounts, and maybe overwrite the ones in your main account by the working ones in the new account.
Just make sure that the overwritten files have the proper ownership and permissions.
I’m so sorry, I don’t understand the question. Are you saying that:
Wow, btrfs is quite advanced, wow! And so tempting to use as a backup mechanism… Hehe, I’m kidding! But thank you for explaining the system.
Ooooh, that buffer is good to be weary of, it explains the need to TTS.
But also, from the sounds of it, after deleting these files… merely logging in to KDE plasma will recreate them? 
That’s convenient!
Yes, it will, but with the default values from upstream, i.e. KDE themselves. It is only upon the creation of a new account and the first login into that one that some of the upstream defaults — e.g. theming and wallpaper — will be overwritten by the ones in /etc/skel/.config/, and those in turn come from the package manjaro-kde-settings.
P.S.: I’ve amended my previous post with some useful advice. 
Genius! It’s so simple, so obvious, I wish we started here first!
And… 
Biscuits 
I’m sorry mates! The fresh user account shares the problem.
I guess this implies that the corruption isn’t from the user config files? Argh.
That is correct. But we needed to be sure of that first.
Back to the drawing table… 
I merely wanted to point out that a firewall or a packet filter security rule might be active and blocking a connection (either unintentionally or because it was forgotten). There is presumably no filter service active in the live system.
This command line can be used to determine whether a common filtering service is enabled:
sudo systemctl status {iptables,ip6tables,nftables,firewalld,ufw}.service |grep enabled
Depending on the enabled type, the active rules can be displayed with one of these commands:
sudo iptables -L -n -v
sudo ipv6tables -L -n -v
sudo nft list ruleset
sudo firewall-cmd --list-all-zones
sudo ufw status
It would appear not so… although, removing grep reveals that everything is disabled. I hope this is a good thing? 
❯ sudo systemctl status {iptables,ip6tables,nftables,firewalld,ufw}.service
Unit firewalld.service could not be found.
Unit ufw.service could not be found.
○ iptables.service - IPv4 Packet Filtering Framework
Loaded: loaded (/usr/lib/systemd/system/iptables.service; disabled; preset: disabled)
Active: inactive (dead)
○ ip6tables.service - IPv6 Packet Filtering Framework
Loaded: loaded (/usr/lib/systemd/system/ip6tables.service; disabled; preset: disabled)
Active: inactive (dead)
○ nftables.service - Netfilter Tables
Loaded: loaded (/usr/lib/systemd/system/nftables.service; disabled; preset: disabled)
Active: inactive (dead)
Docs: man:nft(8)
Actually, you suggested this as a means of comparing corrupted files in the user directory, but could it be possible to compare the working system configuration in the LiveUSB to my configuration on the local installation? 
If so, I would need some community guidance as to what files to pull and compare.
Mod edit: Consecutive posts merged.
That might be more difficult, because the ISO on the USB stick will be older than your installed system, and there may be different packages or package versions, including syntax changes in the configuration files.
Still, you could try that, and then the differences could probably be narrowed down to your network-related stuff, as well as perhaps the systemd-related things — both will be under the /etc hierarchy.
Hmmm, that’s a big deal indeed, especially with the kernel updates.
Will GNU Grub complain if I try to install two Manjaros? I could divide my EXT4 partition, install the LiveUSB, do all the updates, then do the comparison…
No, it should be able to handle that fine. But you may need to enable the os-prober in /etc/default/grub — it’s disabled by default for security reasons — and then run…
sudo update-grub
… in order for grub to detect both installations. The grub you get to see will most likely also be the one of the newer installation, given that it will write its configuration last.
“Good” in the context of the problem you described. Nevertheless, I would recommend enabling the nftables service. The default ruleset provided in /etc/nftables.conf offers basic security (“IPv4/IPv6 Simple & Safe firewall ruleset” - incoming packets are accepted only if they were preceded by an outgoing packet initiated by your computer). It is certainly advisable to take a closer look at “nftables”.