Introduction Video

We have a new introduction video that explains what Candela Technologies does and where we fit in the technology landscape. It’s on our homepage and it’s on one of our Candelatech YouTube pages.

Lately we’ve been discussing what other videos we could produce. We’ll definitely produce a very short introduction video. And we’ll definitely make more topical videos about testing scenarios. If you have suggestions for videos about network and WiFi testing you’d like to see, please let us know!

Adjacent Wifi Channel Throughput Testing

What is the effect of wifi clients on adjacent channels when performing over-the-air wifi throughput testing?

We decided to investigate this question to help show why it happens and also to determine if the physical proximity of the wifi NICs could also be to blame.

After running the tests described below, we found that co-channel interference happens with Access Points using adjacent channels and with LANforge using physically adjacent wifi NICs. LANforge test results show better on-air throughput performance when the PCI-E NICs are physically separated by different systems rather than having the wifi NICs side by side in a single platform.

The test setup consists of two LANforge systems, a CT523c and a CT523b and two identical test APs. The CT523c, labeled LF1, has two 4×4 wifi NICs with clients wlan0 and wlan2. The CT523b, labeled LF2, has two 4×4 wifi NICs, but only one client, wlan2, is in use. The test APs are each setup with a single unique SSID using open authentication and are physically placed about 1m from each LANforge system. Each AP is also using its specified channel at 80MHz channel width.

Each test iteration is a 30 second download test, then 30 second upload test for each individual wifi client and then again for combinations of clients for download and upload.

First test: AP-A on ch100 and AP-B on ch116 – here is what it looked like on inSSIDer:

The baseline results of each individual client show that the test setup has ideal conditions with all clients reporting similar results:

The combination tests show that the clients’ throughput results suffer from the adjacent channel interference:

If we look at a spectrum analyzer while testing, we can see that the overlap at 5.57GHz between channels 112 and 116 is the reason for the interference.

The next test is a repeat of the first but on channels 36 and 52 which are also adjacent to each other.

Test 2: AP-A on ch36 and AP-B on ch52

Test 2 results:

As we move AP-B over to channels further away from AP-A, the combination tests show that the clients experience less interference and therefore show better throughput results:

Test 3: AP-A on ch36 and AP-B on ch100

Test 3 results:

Test 4: AP-A on ch36 and AP-B on ch149

Test 4 results:

Another important conclusion is that the throughput results for a single active NIC in each LANforge system is better than having both NICs active in a single LANforge system. We can show the difference by comparing the total on-air throughput.

In Test 1, channels 100 and 116:
The all-in-one on-air download throughput is 371Mbps + 674Mbps = 1045Mbps.
The separated on-air download throughput is 467Mbps + 963Mbps = 1430Mbps.
1430/1045 = 1.37 (separating the NICs shows a 37% increase).

In Test 2, channels 36 and 52:
The all-in-one on-air download throughput is 351Mbps + 747Mbps = 1098Mbps.
The separated on-air download throughput is 487Mbps = 974Mbps = 1461Mbps.
1461/1098 = 1.33 (separating the NICs shows a 33% increase).

In Test 3, channels 36 and 100:
The all-in-one on-air download throughput is 948Mbps + 966Mbps = 1914Mbps.
The separated on-air download throughput is 982Mbps + 974Mbps = 1956Mbps.
1956/1914 = 1.02 (separating the NICs shows a 2% increase).

In Test 4, channels 36 and 149:
The all-in-one on-air download throughput is 982Mbps + 980Mbps = 1962Mbps.
The separated on-air download throughput is 981Mbps + 967Mbps = 1948Mbps.
1962/1948 = 1.007 (separating the NICs shows a 0.7% decrease).

We hope that this post helps remind you that wifi is subject to RF interference from a variety of sources including active clients on a neighboring channel as well as the active wifi NIC in the next PCI-E slot.

If you would like more info on using LANforge for wireless testing, please contact us at or call +1-360-380-1618.

ath10k-ct firmware released

I am pleased to announce the latest release of the ath10k-ct firmware for QCA WiFi chips.  The 10.1 (wave-1) firmware has improved survey support, changes to how rate-ctrl retries frames, and includes PMF support.  Full release notes here:

The 10.4 wave-2 firmware includes some significant rate-ctrl improvements, PMF support, and various bug fixes and small features.  Full release notes are here:

In addition, I have uploaded a beta 10.4 firmware that is a rebase of all 900+ Candela patches on top of a more recent upstream QCA firmware.  This is easier to bisect for regressions and has some fixes and other improvements from the QCA firmware itself.  See the beta section if you want to try this out:

Please report bugs to the ath10k-ct github project or to

Setting up Xming

You can display Wireshark from your LANforge system onto your Windows desktop. You need to install some kind of X client software, and Xming does a fine job. However, X comes with some access controls. On a Linux system, you disable access controls with the command xhost +. This allows any host to display a window on your desktop.

Xming has a similar setting. After you install Xming and start it. you want to use the XLaunch utility it comes with to configure settings. You have to get to that from the Start Menu.

2018-04-06 15_19_16-Greenshot (2)
Use the Start Menu Applications item

2018-04-06 15_17_15-Start
Search the Start Menu for XLaunch

The XLaunch program allows you to configure multiple ways to displaying X clients. Display 0 (zero) is fine.

2018-04-06 15_36_27-Display settings

You do not need to start a client program on Xming start.

2018-04-06 15_36_39-Session type

You do want to enable clipboard. Select No Access Control.

2018-04-06 15_36_50-Additional parameters

Then go ahead and Save on the next screen, save the configuration to your Documents folder.

If there is a running session of Xming, exit it.

2018-04-06 15_15_26-Action center

Double-click on the config.xlaunch you created.

2018-04-06 15_45_47-Action center

Click on Sniff Packets in LANforge and you should see Wireshark start up.

2018-04-06 15_47_34-StartB

Notice that the IP of your desktop should be displayed right next to the Sniff Packets button. You can type in the exact IP and X display number you need.

Enabling Remote X Connections (updated)

Getting remote X applications displaying on your CentOS desktop used not to be difficult. X11 remote connections are typically governed by the -listen tcp or -nolisten tcp arguments to X or Xorg server running your desktop. It’s not sufficient to just run xhost + from a terminal on your desktop, you have to edit a display manager configuration file and start a new X session (log out, log in again).

First, disable the firewall:

sudo systemctl stop firewalld
sudo systemctl disable firewalld
sudo systemctl mask firewalld
sudo systemctl daemon-reload

The right command to test with

If you ssh from desktop1 to server2, you probably have X11 forwarding happening already. This uses implied port forwarding through ssh for port 5900 to localhost:5010 usually. This is why when you type $ echo $DISPLAY you will likely see localhost:10 as your new display. By default, many X11 based programs take a -d host:display.number argument. Use this to avoid testing out the ssh local X forwarding. You want to use xhost + from your desktop first, of course:

desktop1$ xhost +
access control disabled, clients can connect from any host
desktop1$ ssh server2
server2$ echo $DISPLAY
server2$ xterm -d desktop1:0.0

When running lightdm as your display manager:

Updated: The files you want to edit if you’re running lightdm include:
1) /usr/share/lightdm/lightdm.conf.d/50-xserver-command.conf

xserver-command=X -core -listen tcp

2) /etc/lightdm/lightdm.conf
This file probably won’t exist, you may create it if it is missing.

xserver-command=X -listen tcp

Then run $ sudo systemctl restart lightdm

When you log in again, check that no -nolisten tcp arguments are present in the X command line. Multiple -listen tcp arguments are fine.

$ pgrep X | xargs ps -lfwwwp

When running gdm as your display manager:

Then edit /etc/gdm/custom.conf

You want to add this line to [security] stanza:


And allow a listen tcp argument to the [xdmcp] stanza:

ServerArguments=-listen tcp

A full configuration looks like:

# GDM configuration


ServerArguments=-listen tcp



Log out of your CentOS desktop session, and log in again. Open a terminal and run:

$ xhost +

You can check the efficacy of that by looking at the arguments X was started with:

$ pgrep X | xargs ps -lfwwwp


Other options include TigerVNC:

$ sudo yum install tigervnc
$ vncviewer

Or use Rdestop:

$ sudo yum install freerdp
$ xfreerdp

Remote X connections have been out of fashion for many years, and the default is to not allow connections for security reasons. If you are running equipment in an isolated environment, you should feel safe doing this.