I'm guessing this has to do with encoding. According to this answer, an SSID may (now) have an explicit UTF-8 or UNSPECIFIED encoding, but the "SSIDEncoding" field is part of a newer standard. Presumably then on networks with equipment older than this, it is effectively "unspecified".
I would like to think that anything which sets an SSID from text input by humans would do it in ASCII or UTF-8. However, the standard specifying the SSIDEncoding field appears to be dated 2012, so previous to that, any encoding at all could be used (and any encoding at all could still be used, as UNSPECIFIED). So there could be some software somewhere that sets them in something else -- e.g., using ASCII but falling back on UTF-16 when a string contains odd characters. Java and I believe Windows both use UTF-16 internally.
The router almost certainly regards the SSID as a sequence of bytes and does not care about any potential encoding at all, so it will accept whatever it was passed when the SSID is set. To determine this, you'd have to look at the actual byte sequence as broadcast.
both systems can see the network, if it's not hidden.
It's possible to recognize a UTF-16 string for what it is, so when not hidden, that may happen and the SSID translated into local encoding for display. But when you try to enter it manually, the system can't know what encoding to use in the broadcast; it will only work if it matches the methodology of the software that set it in the first place. The new SSIDEncoding field does potentially resolve this, but A) it also allows for the UNSPECIFIED loophole, and B) older equipment won't care. Since linux and android generally use UTF-8, if the SSID is actually a UTF-16 string, it may end up looking the same on the screen, but not match up when entered manually and searched for.
IW
The command iw is generally used to configure the wifi devices , it can be used to connect to an open wifi network or to an access point protected by a WEP key.
The limitation : It is not possible to connect to a wifi network protected by a WPA* key.
nmcli
It is a network-manager command line tool to configure the NetworkManager and connecting to a all wifi network , it is a NetworkManger dependency . It is a powerful command line tool but you can connect without it.
wpa_cli
It is a command line tool to interact with the wpa_supplicant allowing you to write the configuration file used by wpa_supplicant (under /etc/wpa_supplicant directory) and connecting to wifi notwork (and more...).
It is a complete tool to manage your wifi connection.
but it doesn't seem to work when NetworkManager is installed.
Right , when the NetworkManager is installed it will start at boot , it will launch the wpa_supplicant.service to connect using the saved networkmanger configuration file, the wpa_cli will try to modify the wpa_supplicant configuration file and connect again which cause the command to fail.
To successfully connect through wpa_cli you should stop the NetworkManager.service.
Best Answer
$ wpa_cli