LANforge 5.4.4 Released

Ben working on LANforge

We are excited to share the new features in 5.4.4:

  • WiFi 6 and 6e client emulation
  • TR398 issue 2 test suites
  • Android WiFi testing app
  • improved python scripting

New Linux Kernel and Intel Wireless support:

Support recent 5.15 kernel for updated drivers and latest features. This includes several updated drivers for Intel AX200 and AX210 radios.

MediaTek Radio Support

  • Support MTK 4×4 AX radios in tr-398 issue 1 (except MU-MIMO test case, which is not currently supported.)
  • Support MTK 4×4 AX radios in tr-398 issue 2 (except MU-MIMO test case, which is not currently supported.)
  • Support tx-overrides on MTK 4×4 AX NIC (ability to specify NSS, MCS, bw, guard-interval for transmitted data frames.

TR398 Testing Suites

  • Update TR398 issue 2 to support latest proposed test revision.
  • Improve report content for TR398 and TR398i2.
  • Add proposed TR398 issue-3 Airtime Fairness (ATF) test case.
  • Add proposed TR398 issue-3 Quality of Service (QoS) test case.
  • Add proposed TR398 issue-3 Latency test case.
  • Add proposed TR398 issue-3 Multicast test case.
  • Add subtest pass/fail counters to TR398 and TR398i2 KPI reports.

Test Updates

  • Add pass/fail option for Dataplane and Rate vs Range test.
  • Add Latency graphs for the AP-Auto multi-station throughput test.
  • Scale test: Add ping support, improve error checking and feedback to user.
  • Improve RvR test report and procedure.

Android App

Initial support for LANforge pure-java resource on Android phones. Includes TCP, UDP, IPv4, IPv6 and HTTP/HTTPS protocol support for traffic generation. This app has been used in campus WiFi testing.

Python Scripting

Improved python scripting support, including:
– auto-generated .py files to support LANforge CLI commands
– cleanup and stability improvements
– various new automated python tests

Regression testing of the scripting library fixed many areas. We are introducing support for Python virtual environments. Python Pypi libraries are now installed in user environment and do not require OS python libraries.

Fedora Support

We continue focusing our product around Fedora, and support python scripting on Fedora 27 and newer. Our latest products are installed using Fedora 34.

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.

Temporarily Changing the Default Gateway to a Virtual Station

When testing a virtual station and you need to verify with a browser that you can reach a captive portal page, or browse the Internet–you want to change the default gateway of the system to the gateway that the virtual station was assigned. This is a manual change, because when the virtual station associates, the default route of the system doesn’t change. If it did, you’d probably lose connection between the LANforge resource and your management station would probably be lost.

After checking your associated station, you can write a script to help set the new default gateway. Here’s an example with some fixed values:

#!/bin/bash
echo "Please do this command in screen"
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - #
# Use this script to modify your routes to allow a station      #
# to become the default route. Should maintain route for your   #
# existing connection to management laptop through eth0.        #
# This script is an example to be modified.                     #
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - #
set -x
ip a show eth0
ip a show sta100
ip route show

# this adds address to station, referred to below
# ip a add 10.45.1.23/24 dev sta100

# make static route to old gateway
ip route add 192.168.45.1 dev eth0

# make static route to mgt laptop
ip route add 192.168.45.2 dev eth0

# now update default route to go out sta100
ip route change default via 10.45.1.23 dev sta100

sleep 1s
ping -nc2 192.168.45.1
ping -nc2 192.168.45.2

# adjust this to your work time window
read -t $((2 * 60)) -p "Press Enter to end and reset"

# and set the route back
ip route change default via 192.168.45.1 dev eth0
ip route show
ping -nc2 192.168.45.1
ping -nc2 192.168.45.2

Notice that the script suggests using screen.  Why use screen? Because if your terminal session disconnects, the script will continue and reset the previous default gateway. If the script is interrupted (by session disconnection or control-c) your default route will remain running across your AP. (We add default link-local routes to our laptop to help mitigate this.)
There is a default .screenrc file in /home/lanforge. You want to run the script as root. This will work: sudo ./change_gw.sh

This is an example script with some logic to help detect the default gateway, your ssh connection, and you tell it what station to use:

#!/bin/bash
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - #
#  Use this script to modify your routes to allow a station     #
#  to become the default route. Should maintain route for your  #
#  existing connection to management laptop through eth0.       #
#  This script is an example to be modified.                    #
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - #

if [ -z "$3" ]; then
   echo "Use this script to assign a station on this system to be the new default gateway."
   echo "Usage: $0   "
   echo ""
   echo "Your manager-ip is the LANforge resource in mode 'manager' or 'both' and might"
   echo "not be the machine hosting the virtual station."
   echo "Example, sta3000 on resource 3, manager is 192.168.1.101:"
   echo ""
   echo "./$0 192.168.1.101 3 sta3000"
   echo ""
   echo "Please do this command in screen"
   exit 1
fi

def_gw_dev=`route -n | awk '/^0.0.0.0 / {print \$NF}'`
def_gw_ip=`ip a show $def_gw_dev | awk '/inet /{print \$2}'`
def_gw_ip=${def_gw_ip%/*}
echo "default gw device: $def_gw_dev $def_gw_ip "
sleep 3
manager_ip=`who | perl -ne '/\(([0-9.]+)\)$/ && print "$1\n";'`
#ip a show $def_gw_dev
echo "This is the station you requested:"
ip a show $3
sleep 3

#  make static route to old gateway
echo "ip route add $def_gw_ip dev $def_gw_dev"
ip route add $def_gw_ip dev $def_gw_dev

#  make static route to mgt laptop
echo "ip route add $manager_ip dev $def_gw_dev"
ip route add $manager_ip dev $def_gw_dev
sleep 3

# now update default route to go out sta100
cd /home/lanforge/scripts
sta_gw=`./lf_portmod.pl --manager $1 --card $2 --port_name $3 \
  --show_port --quiet yes \
  | awk '/ IP:/{print \$6}'`

echo "* Changing default gateway in 3 seconds *"
sleep 3s
echo "ip route change default via $sta_gw dev $3"
sleep 1s
ip route change default via $sta_gw dev $3
sleep 1s
ping -nc2 $def_gw_ip
ping -nc2 $manager_ip

# adjust this to your work time window (in seconds)
#  $(( 2 * 60)) == 120, 2 minutes
read -t $((2 * 60)) -p "Press Enter to end and reset"

# and set the route back
echo "changing route back to previous default gw..."
ip route change default via $def_gw_ip dev $def_gw_dev
ping -nc2 $def_gw_ip
ping -nc2 $manager_ip
echo "...done."
#

To use the script, you would say:

sudo ./change_gw.sh 192.168.100.41 3 sta3000

You are probably going to need to alter the script. If you hit Ctlc in the script you will need to reset the routes by hand.

For actually using Firefox, you need to operate this from the desktop of LANforge resource hosting the virtual station. So if, in this example, sta3000 is on resource 3, you need to get on the virtual desktop of resource 3. Open a terminal from the virtual desktop or ssh to resource 3 and start screen as user LANforge.

Captive Portal Testing

A popular feature of the LANforge WiFIRE feature set is captive portal testing portal-bot. If you’re considering doing captive portal testing, the first thing to know is that you are not going to be automating a bunch of web browsers (that would be madness). You will be writing a perl script. More specifically, a perl .pm extension to our portal-bot.pl script.

Portal testing can be complex because it normally involves re-creating whatever JSON/AJAX/REST call chain the web pages does with a perl script. This process looks like:

  1. Establish laptop with serial connection to LANforge system and with an Ethernet cable
  2. VNC to LANforge and change default gateway and use browser to document login HTTP process
  3. Write a portal-bot extension that mimics that behavior
  4. Incorporate a logout mechanism

It is very useful (and a requirement for long-running capacity testing) to have an API call to the captive portal controller that will log out a session. Otherwise you cannot repeat the test for each station without manually intervening at the captive portal controller to log out one/some/all logged in stations. This logout mechanism could be web-based or could be ssh based, so long as the mechanism can be unattended.

Please review some of our existing portal-testing documentation: