Using UTF-8 in Your SSIDs

The LANforge server process is not multi-byte character aware, and pasting hanzi or other logograms into the GUI will get mangled. What is displayed is an byte escape sequence, like what this script shows:

 > ./ 小猫

This is the C-language byte encoding for those UTF-8 characters. This is what wpa_supplicant and hostapd rely on in their configuration files. (That script is pasted below.)

If you paste hanzi into the hostapd.conf file “ssid=” property, (you have to specify a custom file) you can get a virtual AP to come up. It will NOT associate with a station. The wrong way:

If you paste the byte sequence into the ssid property, a station WILL associate. Make sure to specify utf8_ssid=1. The right way:

The display scan window will display the SSID as a byte sequence.

The SSID picker in the Port Modify will show the byte sequence after you click the DISPLAY SCAN button.

Watch your Wireless Events log window for of station association messages. A station that continues to scan even if the SSID is shown in the scan windows is one that is not connecting.


This is the right way to write the wpa_supplicant file, with the SSID escape sequence. Use the utf8hex script to get this byte sequence.

Here is the script:

#!/usr/bin/perl -w
use utf8;

for my $u (@ARGV) {

   foreach my $ch (split('', $u)) {
      my $b = ord($ch);
      if ($b >= 20 && $b <= 126) {
         print $ch;
      else {
         printf("\\x%x", $b);
   print "\n";

Pack a Gateworks Full of Radios

Candelatech strives to provide products that are flexible and quiet. The Gateworks Ventana platform provides a great opportunity to provide a high density virtual access point emulation platform. With a bit of shrewd of modification, this GW5400 model can provide 30 or more virtual WiFi access points.

Keeping that many radios cool is what is important. A bit of aluminium plate and heat conductive tape worked wonders for this platform. We’ve seen it run for a month straight without heat related issues. This is effectively a sealed system. It was warm to the touch, but nowhere near hot.



LANforge 5.3.1 Released with WiFi Testing Emphasis

LANforge 5.3.1 has been a serious piece of work to put out. We were dogged by lots of troubles with the QCA firmware for the 802.11ac chipset. Ben put in countless hours combing through stack traces and kernel archives looking for fixes to DMA errors. Amazingly he fixed so many we are able to keep Layer-3 connections alive indefinitely now.

This was also an interesting development period because we got our first pair of Octobox anechoic chambers. These are RF-isolating boxes with RF impeding power and network interfaces at their margins. This was the first time we saw ideal 802.11n throughput in 5Ghz. Like…theoretical ideal. Checked off the list. Ben picked his jaw up off the floor when he saw Isaac’s graphs. Asked him to “do that again!”

Jed spent much time doing 802.11x station roaming experiments. The trick to roaming effectively is to shuffle the roaming requests between radios, not to send sequential roaming (stampeding) requests from a single radio. It would make sense from a CSMCA point of view that a WiFi environment wants to actively listen for activity instead of constantly broadcast. Jed was able to get 30 wifi roaming events a second between two LANforge CT523’s running 164 virtual stations.

This lead us to a great LANforge 5.3.1 release. Lot of work. More planned. Stay tuned.