关于wpa_supplicant是否存在SSID字符类型限制的技术问询

Great question—let’s unpack this because there’s a key distinction between the IEEE 802.11 standard and real-world tooling behavior with wpa_supplicant.

First, to confirm: the IEEE 802.11 standard does allow any 32-octet (byte) sequence for an SSID. There are no restrictions on character types, including non-ASCII characters, control characters, or what can be used as the first/last byte. This part of your research is spot-on.

Now, why are you hitting issues with wpa_cli and connecting to non-ASCII SSIDs? Let’s break down the two main scenarios:

1. Can’t set non-ASCII SSIDs via wpa_cli #

The problem here isn’t wpa_supplicant itself—it’s the wpa_cli tool’s default input handling. When you type non-ASCII characters directly into the terminal, they’re subject to your terminal’s encoding (e.g., UTF-8) and wpa_cli’s parsing logic, which may not properly pass raw byte sequences.

To work around this, you can specify the SSID using its hexadecimal byte representation. For example, if you want an SSID with the Chinese characters "测试" (UTF-8 bytes: E6 B5 8B E8 AF 95), use this command:

wpa_cli set_network 0 ssid "hex:E6B58BE8AF95"

This bypasses terminal encoding issues and sends the exact byte sequence wpa_supplicant expects.

2. Can scan non-ASCII hotspots but can’t connect #

This almost always boils down to encoding mismatches. The SSID is a raw byte sequence—when your device scans and displays it as a string, it’s decoding those bytes using a default encoding (usually UTF-8). If the hotspot’s SSID was encoded with a different charset (e.g., GBK, Shift-JIS), the displayed string won’t match the actual bytes, and your wpa_supplicant configuration (which uses your terminal’s encoding) will send the wrong byte sequence.

To fix this:

• Use wpa_cli scan_results to retrieve the hotspot’s SSID. If the SSID can’t be decoded to a readable string, it will show up as hex:<byte_sequence>. Use that exact hex string in your network configuration.
• If it does show a readable string, verify the encoding used by the hotspot’s device, then convert that string to the correct byte sequence and use the hex format in wpa_cli.

Are there inherent limitations in wpa_supplicant? #

No—wpa_supplicant fully adheres to the IEEE standard and supports any valid 32-octet SSID. The limitations you’re seeing are from:

• The wpa_cli tool’s terminal input handling (easily worked around with hex notation)
• Encoding mismatches between your configuration and the target hotspot
• Third-party device restrictions (many consumer routers/hotspots enforce printable ASCII limits on their end, but that’s not a wpa_supplicant constraint)

内容的提问来源于stack exchange，提问作者Mechi