Suponho que isso tenha a ver com codificação. De acordo com esta resposta , um SSID pode (agora) ter uma codificação explícita UTF-8 ou UNSPECIFIED, mas o campo "SSIDEncoding" faz parte de um padrão mais novo. Presumivelmente, então, em redes com equipamentos mais antigos que isso, é efetivamente "não especificado".
Eu gostaria de pensar que qualquer coisa que defina um SSID de entrada de texto por humanos faria em ASCII ou UTF-8. No entanto, o padrão que especifica o campo SSIDEncoding parece ser datado de 2012, portanto, antes disso, qualquer codificação poderia ser usada (e qualquer codificação poderia ainda ser usada, como UNSPECIFIED). Assim, pode haver algum software em algum lugar que os configure em outra coisa - por exemplo, usando ASCII, mas voltando ao UTF-16 quando uma string contém caracteres ímpares. Java e eu acreditamos que o Windows usa UTF-16 internamente.
O roteador quase certamente considera o SSID como uma seqüência de bytes e não se importa com nenhuma codificação em potencial, então ele aceitará o que foi passado quando o SSID estiver configurado. Para determinar isso, você teria que ver a sequência de bytes atual como transmissão.
both systems can see the network, if it's not hidden.
É possível reconhecer uma string UTF-16 pelo que ela é, portanto, quando não oculta, isso pode acontecer e o SSID é convertido em codificação local para exibição. Mas quando você tenta inseri-lo manualmente, o sistema não pode saber qual codificação usar na transmissão; Ele só funcionará se corresponder à metodologia do software que o definiu em primeiro lugar. O novo campo SSIDEncoding potencialmente resolve isso, mas A) também permite a lacuna UNSPECIFIED, e B) equipamentos mais antigos não se importam. Como o linux e o android geralmente usam UTF-8, se o SSID é na verdade uma string UTF-16, ele pode ter a mesma aparência na tela, mas não combina quando é digitado manualmente e pesquisado.