This is perhaps a question that you already asked yourself. Let’s look at the IEEE 802.11-1999 standard what the initial intent was:
7.3.2.1 Service Set Identity (SSID) element
…
The length of the SSID information field is between 0 and 32 octets. A 0 length information field indicates the broadcast SSID.
…
Nothing there about Emojis, but back then, they were quite uncommon, and it took until 2010 to include Emojis into the Unicode 6.0 specification to make them vendor-agnostic.
So, what is defined in IEEE 802.11-2012, the next published standard after 2010?
8.4.2.2 SSID element
…
The length of the SSID field is between 0 and 32 octets.
…
When the UTF-8 SSID subfield of the Extended Capabilities element is equal to 1 in the frame that includes the SSID element, the SSID is interpreted using UTF-8 encoding.
…
Here, the magic starts as Unicode is typically encoded in UTF-8. How does a Unicode SSID appear in a packet capture for my Meraki-SSID?
Wireshark knows that this SSID uses Emojis and displays them properly:
This is the Hex-Block:
And this can be looked up in the Unicode reference:
| e29895 | Emoji “Hot Beverage” |
| efb88f | Variation Selector-16 (VS16) |
| f09f9b9c | Emoji “Wireless” |
| 20 | Space |
| 2d | Hyphen |
| 20 | Space |
| 466c6174 | Text “Flat” |
| 20 | Space |
| 5768697465 | Text “White” |
| 20 | Space |
| 576972656c657373 | Text”Wireless” |
Based on Wikipedia, the Variation Selector 16 defines that the previous symbol has to be displayed in color. That makes sense for symbols that are both known in colored and black & white.
How does Wireshark, or a wireless client know that the SSID-name is based on Unicolde and the previous is not the String “e29895efb88f202d20…”?
For this, the standard defines a field (Bit 48) in the Extended Capabilities Element:
For my Emoji-SSID this Bit is set:
I think that Wireshark uses a bad wording here, as it’s not only that it’s supported, but it’s actually used. Wi-Fi Explorer Pro has a better wording, similar to the IEEE definition:
For an SSID where the SSID is sent as ASCII, this Bit is not set:
And while I write this, I realize that all my SSIDs are encoded in UTF-8, and not only the one that actually needs it. And for most of my neighbors (also a Meraki based SSID), it’s plain ASCII.
This needs some more investigation for the Meraki behavior, and also which platforms allow us to configure Emojis and which don’t.
Have fun with Emoji-based SSIDs, but please, no, not that Emoji!