LANforge 5.4.1 Released

20160722-splitters-anvil-430
We’re happy to announce LANforge 5.4.1, that supports a number of new features:

  • Add TR-398 automated WiFi test support.
  • Support /AC on 2.4Ghz on /b/g/n/AC radios (2.4Ghz /AC)
  • Add support for wired traffic test to the Dataplane scenario test.
  • Support 5.2 kernel for latest drivers and kernel features.
  • Support IPSEC interfaces.
  • Support CT850a 2D attenuator turn-table.
  • Support ComXim MT series turn-table (for instance: MT200RUWL20)
  • Improve performance of creating virtual stations, tested 500 stations per /n radio.

IPTables and conntrack

When you are using LANforge as a virtual router doing NAT, you might need to see how many NAT table entries you’re handling.  This can be important because NAT entries take memory, and if you want to handle 65,000 simultaneous connections, you might be heading for trouble.

If your LANforge is only generating traffic, you won’t see NAT entries…rather you want to use netstat -ntp to see how many open connections there are.

LANforge uses iptables PREROUTING heavily, forcing each port to have it’s own set of tables. When you type iptables -nvL and see nothing…that’s because nothing is in the tables for your default route, which is probably eth0. You get close with the raw table. Try iptables -S -t raw. You will see PREROUTING entries for every interface:

# iptables -S -t raw
-P PREROUTING ACCEPT
-P OUTPUT ACCEPT
-A PREROUTING -i br2000 -j CT --zone 10001
-A PREROUTING -i eth1 -j CT --zone 10001
-A PREROUTING -i vap13 -j CT --zone 10001
-A PREROUTING -i vap14 -j CT --zone 10001
-A PREROUTING -i eth2 -j CT --zone 10001

This shows we have a CT chain and a zone note for that chain.

When you create a virtual router, add NAT to a port in it, you can view the NAT table entries with conntrack.

* conntrack -L will list them all, but that’s probably not super useful
If you’re running TCP-multicon connections, expect thousands of connections.
* conntrack -C will show how many NAT entries are present, so you can avoid doing a conntrack -L | wc -l

Happy networking!

Adding hostnames to dhclient configs

If you have hundreds of stations on your LANforge and want to give them all hostnames, this is certainly possible. Please get the add-dhcp-hostname.pl script from the lanforge-scripts repository.

  1. First bring up your stations with DHCP enabled. This will create your dhclient config files in /home/lanforge/vr_conf.
  2. Admin-down the stations.
  3. With a root shell, go to that vr_conf directory and run this script on the files you want to give hostnames to.
    1. For just one station:
      root# ~lanforge/scripts/add-dhcp-hostname.pl dhclient_sta0000.conf
    2. For all the stations:
      root# ~lanforge/scripts/add-dhcp-hostname.pl dhclient_sta*conf
  4. Admin-up the stations.
    1. If you are sniffing, you will see a DHCP Request packet that has a hostname attribute.
    2. If you are inspecting a LANforge dhcpd server in a virtual router, you would check /home/lanforge/vr_conf/vrcx_eth1_dhcp_lease.db for entries with the setting client-hostname.

That should work.

Java on OS X

Sometimes your Mac has a very old version of Java on it, like 1.6.0_123. This can break running the LANforge client. Let’s learn how to manage this. First, open Terminal and find what version of Java you think you have:

$ java -version

This reports what your JAVA_HOME environment variable (which might not be set) is, so the System will do a /usr/libexec/java_home command for you. You might need to follow these instructions on removing old Java version.

Install a recent version of Java. Then go back to the terminal. You want to make sure that your JAVA_HOME variable is getting set to the version you want. Verify you have a .profile and a .bashrc file in your home directory:

$ ls -l ~/.profile ~/.bashrc

Create them if the don’t exist:

$ touch ~/.profile ~/.bashrc
$ chmod 700 ~/.profile ~/.bashrc
$ echo "source .bashrc" >> ~/.profile

To see the versions of Java installed, use the java_home command:

$ /usr/libexec/java_home -V

The first column of output will be the version number, which is important for running the java_home command. Edit your .bashrc file to export your JAVA_HOME environment variable:

export JAVA_HOME=$(/usr/libexec/java_home -v 1.8.0_122)

Save and open a new terminal. Verify using java -version.

More discussion on setting the version:

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:
ch100-ch116-ht80

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

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

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.
ch100-ch116-spec

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
ch36-ch52-ht80

Test 2 results:
adjacent-channel-tput2

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
ch36-ch100-ht80

Test 3 results:
adjacent-channel-tput3

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

Test 4 results:
adjacent-channel-tput4

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 sales@candelatech.com 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:  http://www.candelatech.com/downloads/ath10k_release_notes.txt

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:  http://www.candelatech.com/downloads/ath10k-10-4/ath10k_release_notes_5.txt

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:  http://www.candelatech.com/ath10k-10.4.php

Please report bugs to the ath10k-ct github project or to greearb@candelatech.com