On 26 June 2018 at 11:34, Jouke Witteveen <j.witteveen@gmail.com> wrote:
On Tue, Jun 26, 2018 at 12:17 PM Emil Velikov <emil.l.velikov@gmail.com> wrote:
On 23 June 2018 at 12:25, Jouke Witteveen via arch-projects <arch-projects@archlinux.org> wrote:
Strictly speaking, we should check with the SSIDEncoding value sent out by the station, as specified in the 2012 version of 802.11 (page 566), but wpa_supplicant does not (yet) expose this information and stations may not set the field to UTF-8 and still encode their SSID accordingly.
I wonder if iwd (meant to be wpa_supplicant replacement) could help here. Be that by exposing SSIDEncoding or setting it, as it detects UTF-8 in the SSID.
As far as I can tell, only developers of iwd think of iwd as a wpa_supplicant replacement. Currently, it is lacking a CLI and documentation. Moreover, wpa_supplicant is tried and tested. While I try to not tie netctl in too strongly with any specific client, wpa_supplicant will likely be the client of choice for netctl for the foreseeable future.
I've noticed the iwctl and iwmon utils provided, although did not play around with them. You're on point though, sticking with wpa_supplicant for the foreseeable future is fine.
I submitted a patch to wpa_supplicant for exposing the UTF-8 SSID bit: http://lists.infradead.org/pipermail/hostap/2018-June/038658.html However, experimentation showed that it is not really used (yet?).
Vendors may start using it... one day Thanks again for the comprehensive answers! Emil