1

I'm trying to add a Unicode character (https://emojipedia.org/fire/ 🔥) to my WiFi's SSID, as I've seen a lot of people managing to do it. However, this doesn't currently work.

The standard behavior of my router (which I can bypass using Chrome's DevMode) is to allow only ASCII characters. What I get after the bypass is a WiFi named 🔥 (as shown on Ubuntu 16.04 & Android 7.0), corresponding to the HTML decimal entity of my smiley. Note that the smiley displays correctly in the administration panel of the router.

I later also tried to intercept and modify the POST request to change the SSID, which contained the smiley formatted as 🔥, but here too, not much success. Now, I actually doubt that my router supports Unicode characters, but wanted to know your opinion before beginning to search a new funny name for my WiFi.

The router is a CH7485E from TeleColumbus, manufactured by Compal Broadband Networks (http://www.icbn.com.tw/products/product_view_en/8).

Improve this question
1
  • I've added the few informations I could find at the end of the post. I tried running NMAP scans to gather more details, but connecting via command line seems impossible (ports filtered).
    – user775750
    Oct 14, 2017 at 20:00

1 Answer 1

Reset to default
3

Originally IEEE 802.11 defined an SSID as being up to 32 bytes, but didn’t specify how to interpret the string (US ASCII? ISO-8859-1? Some IBM/Windows “code page”? UTF8? UTF16?), nor did it state any limitation on acceptable values.

Different vendors have made different choices over the years on what they let you set and how they interpret the up to 32 byte value. So even if you can set Unicode characters via UTF8, there’s no guarantee that a given piece of client software will interpret it that way when they see it in scans.

It sounds like the web-based admin UI of your AP may be getting in the way of setting UTF8 characters. That’s a shame. Without knowing how the web server on the AP handles that field when it receives it via POST, it’s hard to know how to help.

Oh! Hey. One thing to try is to make sure you’re not setting that emoji as the last character of an SSID that is already almost 32 bytes long. UTF8 encodes most Unicode characters in a way that takes up multiple bytes, and SSID length limits just care about the underlying bytes, not how many characters it makes. So if you were using the “Fire” emoji as, say, the 30th character of your otherwise 7-bit ASCII SSID, and the UTF8 encoding of the fire emoji is 4 bytes (I didn’t look it up), that would make your proposed SSID take up 33 bytes, which is too long.

Improve this answer
1
  • Following your suggestion on the page encoding, I used the "Set Character Encoding" extension for Chrome to force my input SSID as UTF-8. I received the same error as on the admin console, but this time coming from the page where the POST payload was redirected (the form data contains my smiley as 4 UTF8 bytes). Therefore, I suspect that a client-side check is performed, which would be impossible to bypass. I also checked that my SSID was shorter than 32 bytes.
    – user775750
    Oct 15, 2017 at 15:01

You must log in to answer this question.