Este SO Q & A intitulado: Existe um padrão que define o que é um SSID válido e senha? responde algumas de suas perguntas.
trecho
Section 7.3.2.1 of the 802.11-2007 specification (http://standards.ieee.org/getieee802/download/802.11-2007.pdf) defines SSIDs.
A valid SSID is 0-32 octets with arbitrary contents. A 0-length SSID indicates the wildcard SSID (in probe request frames for instance).
There's no character set associated with the SSID - a 32-byte string of NUL-bytes is a valid SSID.
This implies:
- you should never use normal string functions when manipulating generic SSIDs (strcpy() and friends).
- you should not assume that the SSID is printable when, for instance, logging it to disk
Há também este comentário sobre a resposta à pergunta da SO:
There's updated version of standard (http://standards.ieee.org/getieee802/download/802.11-2012.pdf ), which defines SSIDEncoding field. It can be UNSPECIFIED (for arbitrary data) or UTF8.
Por isso, gostaria de ver o último padrão de orientação e garantir que você possa lidar com o que é legal com base nisso.
O que mais?
Além disso, posso estar inclinado a me proteger normalizando a entrada de um usuário usando alguma forma de função de codificação de URL (algo que funcionaria com SSIDs obviamente) ou simplesmente removendo caracteres ilegais e simplesmente não permitindo que eles gravem essas seqüências de caracteres. para este arquivo.
Personagens estranhos?
Os únicos problemas que encontrei com caracteres estranhos / especiais relacionados ao arquivo interfaces foram esses tipos de erros que foram colocados no debian-installer.
debian-installer asked for my wireless networking information and
successfully used it to connect wirelessly to the network. It also
wrote my wireless networking information to /etc/network/interfaces.
However, the WPA key that I entered contained at least one special
character, and debian-installer did not escape or quote the special
character(s) in /etc/network/interfaces. The result was that, on
reboot, the system hung for a very long time during the boot process
as it tried (unsuccessfully) to re-connect to the wireless network. I
fixed the problem by simply quoting the WPA key listed in
/etc/network/interfaces. This should happen automatically if the key
contains special characters.
Também havia esses bugs, um relacionado a espaços dentro do SSID, os outros relacionados à frase secreta:
Em ambos os casos, parece que envolver as strings com aspas duplas é suficiente para proteger os valores de ambos.
Exemplos adicionais
Documentos oficiais
Pesquisando a documentação oficial, encontrei este trecho aqui:
Os documentos oficiais mostram este exemplo:
ap_scan=2
network={
ssid="test adhoc"
mode=1
frequency=2412
proto=WPA
key_mgmt=WPA-NONE
pairwise=NONE
group=TKIP
psk="passphrase"
}
Assim, parece que espaços são permitidos, desde que sejam citados corretamente. Além disso, há este exemplo explicando como fornecer um SSID com espaços para a ferramenta iwconfig :
Add the name (ssid) for the network you want to create/join. Use single quotes if there is a space in the name.
$ sudo iwconfig eth1 essid 'name'
Webconverger
Eu encontrei este exemplo que parece ser Debian sob o capô, então o exemplo pode ser apropriado para a sua situação, mas é difícil dizer com certeza. Eu a mostro apenas porque mostra um exemplo de como eu esperava que um método de codificação de URI fosse exposto para proteger contra caracteres ilegais.
trecho
Example 4 "Spaces in the ESSID", broadcasting essid 'Hopstock Gjestenett', with WPA key uiopzxcv
Please avoid spaces in ESSIDs. In this case we workaround with a encodeURI('Hopstock Gjestenett'), to get the following boot recipe:
wpa-ssid=Hopstock%20Gjestenett wpa-psk=uiopzxcv
Assim, você poderá codificar os espaços que aparecem em SSIDs usando %20 .
SSIDs
Indo ainda mais fundo, encontrei este comentário da página da Wikipedia em Conjunto de serviços (rede 802.11) .
Each BSS or ESS is identified by a service set identifier (SSID) - a 1 to 32 byte string. This is normally a human-readable string and thus commonly called the "network name".6 In an IBSS, the SSID is chosen by the client device that starts the network, and broadcasting of the SSID is performed in a pseudo-random order by all devices that are members of the network.
Este comentário é apoiado por esta apresentação do Blackhat EU 2013, intitulado: Exploração Prática Usando um Identificador de Conjunto de Serviço Mal-intencionado (SSID) .
trecho
- No defined restrictions as to what characters can be used within an SSID (IEEE Std 802.11™-2012)
- Some limitation based on products
- Some character limitation (ascii only)
- Unicode
Portanto, tecnicamente qualquer caractere é permitido em um SSID, diferentes implementações como o Windows XP, o Windows 7, e várias versões do Linux permitem / não permitem subconjuntos de caracteres dentro de SSIDs.
Referências