x86_64 "invalid-key" wi-fi error with special characters in password

    With the imminent demise of W10 support, I loaded LibreELEC last night onto my Intel Compute Stick (STCK1A32WFCR) and was hit by an "invalid-key" error attempting to connect to wi-fi. Today I did some serious troubleshooting, came across several posts on these forums talking about it being a sometimes intermittent issue, but for me, it was 100% of the time. I ultimately found that the issue was caused by my wi-fi password containing these characters

    \z @ < }

    I think the issue is the shell escaping the character after the backslash and causing the password to be interpreted incorrectly. I downloaded https://kernel.googlesource.com/pub/scm/networ…fs/tags/3.9/src but didn't have a lot of luck pinpointing the exact line of code, I didn't examine LibreELEC source code, and I didn't load the password into a config file and present that to connman, so it could well be in how LibreELEC ingests the password and presents it to connman etc.

    Problem: "invalid-key" when attempting to connect with wifi
    OS: LibreELEC (official) 12.2.0 generic_x86_64
    Hardware: Intel Corporation STCK1A32WFCR -> https://www.intel.com/content/www/us…ifications.html (appears to use Realtek RTL8723BS for Wifi/BT - only supports 2.4Ghz)
    Router: ASUS RT-AX88U, firmware Version 3.0.0.4.388_24333
    Tried: protected management frames enabled, disabled, or required; auth set to WPA2-personal
    Repeatable: 100%
    Solved: removed special characters from Wi-Fi password
    Steps to reproduce:

    1. Use a wifii password with these characters \z @ < }

    2. Receive invalid-key error after entering the correct password

    3. Enable debug logging

    Code
        arcstick:~ # mkdir -p /storage/.config/system.d/
    arcstick:~ # cp /usr/lib/systemd/system/iwd.service /storage/.config/system.d/iwd.service
    arcstick:~ # nano /storage/.config/system.d/iwd.service
         <changed to "ExecStart=/usr/bin/iwd --debug">
    arcstick:~ # cp /usr/lib/systemd/system/connman.service /storage/.config/system.d/connman.service
    arcstick:~ # nano /storage/.config/system.d/connman.service
        <changed to "ExecStart=/usr/sbin/connmand -nr --debug">
    arcstick:~ # systemctl daemon-reload
    arcstick:~ # systemctl restart connman
    arcstick:~ # systemctl restart iwd

    4. Retry with debug logging enabled, and again receive the error invalid-key

    A.

    It's interesting that it reports invalid key, because it should report invalid passphrase. Otherwise it's not the eureka moment we are seeking. The \ character is not an allowed character for passphrases and is thus rejected, end of story.

    The 'invalid-key' other folks are seeing is a crypto key being exchanged between client and access-point, and it's deep in the guts of the negotiations needed for some radio features. Weak signals tend to surface it more, which suggests it's related to error handling (or not-handling) code somewhere in the wireless stack. It also shows up with Broadcom WiFi hardware and WPA3 which is not fully supported in current kernel drivers for that hardware; although we've applied mitigations for that now.

    I've removed "[SOLVED]" from the thread title because I don't want the noise of others pointing out that "there's a solution you're not telling us about" and/or that your solution doesn't work for them.