Knowledge base : Knowledge Base > ByteBlower > Wireless Endpoint

Sometimes you have a test running and realise that you want to modify some settings and start all over.
Then you want to cancel your active test:

ByteBlower Endpoints can be canceled remotely since version 2.19.0.

You can now choose if you want the ByteBlower Endpoint to

  • keep contact with its MeetingPoint at regular intervals ("Heartbeating Mode")
  • remain completely silent ("Silent Mode")

Every heartbeat signal is an opportunity to exchange information. This way, a command can be sent to each ByteBlower Endpoint to cancel the running scenario.

Heartbeating Mode

  • In the GUI, you can configure this here, under File>Project Properties>Scenario:

    When enabled, you you can cancel tests from within your GUI. 
  • In the API, you can configure this by using the ScenarioHeartbeatIntervalSet command on a ByteBlower Endpoint.  It has one argument, representing the interval in nanoseconds.

Silent Mode

For some tests, it is crucial that the configured test traffic is the only network traffic. 

  • In the GUI, you can configure this here, under File>Project Properties>Scenario:
  • In the API this is the default behavior.

Old versions

In old ByteBlower Endpoints, with a version before 2.19.0, the app stopped heartbeating to the Meeting Point while a test scenario was running. While running a test, all ByteBlower Endpoints went into "Silent Mode".
This behavior was chosen because it often is undesired to have additional management traffic on top of the actual test traffic.

The downside of this is that you have to wait until the end of the test until the Wireless Endpoint becomes reachable again. So, you can not cancel such a test remotely.
If you want to cancel the test, you have to walk to each Wireless Endpoint, and push the "Abort" button.

Introduction

In this knowledge base article, we describe how to setup your first test using ByteBlower and ByteBlower Wireless Endpoints. We assume the ByteBlower server is already configured and can run wired tests. A simple back to back test is a good start.

The next step  is then testing the wireless network, such as an access point. For the ease of reading, we'll use the situation as shown below:

General topology

The upper left corner shows the host computer running either the ByteBlower GUI or API. This machine is able to connect with the ByteBlower server, running both the server software and Meeting Point. On the right you have a typical wireless setup: a wireless access point or home gateway including a wireless access point and one or more ByteBlower Wireless Endpoints installed on mobile devices or laptops, ….

Before you can use a ByteBlower Wireless Endpoint, you need to register the device at a Meeting Point. This article will give an overview of the possible configurations and solutions to configure a ByteBlower server and the implications for the Meeting Point and Wireless Endpoints.

Before we continue, it is important to understand the purpose of the ByteBlower Meeting Point. The Meeting Point is the glue between the ByteBlower GUI or API and the ByteBlower Wireless Endpoints. The GUI never talks directly to an endpoint, it goes through the Meeting Point. This is a daemon running on a ByteBlower server independent from the ByteBlower server daemon. It keeps a list of the available devices, the state of the devices and translates the command from the user to a device specific scenario. It will also collect the results after a run and present them to the user.

The steps below explain how to lay out the network. They are very conceptual, you might need to work together with IT on how to implement them. Configuring the management address on a ByteBlower server is rather easy. It's explained in the link below.

Connection through the management interface

Depending on your lab IP topology, it is possible to reach the management interface of the ByteBlower server from the Wireless Endpoints. By default, the Wireless Endpoint will also listen for incoming connections on that interface (TCP port 9002). In this case, the connection scheme would look like this:

Connect over the management network.

The GUI or API will communicate with the ByteBlower server and Meeting Point through the management network (green line). The Wireless Endpoints will communicate with the Meeting Point over the WAN interface of the gateway and the management interface of the ByteBlower server. (orange line)

Separate networks

Sometimes, the management network of a lab is completely separated from the networks under test. In that case, the above described solution will not work. The good news is that every ByteBlower server has spare network interfaces. The solution for this issue is to use one of those additional network interfaces on the server and connect it with the test network.

Connect over a separate network.

The GUI and API will communicate with the ByteBlower server and Endpoint through the management network (green line). The Wireless Endpoints will communicate with the Meeting Point over the WAN interface of the gateway and the test network (orange line). This might involve some routers. Be aware that there is no firewall available on the ByteBlower machine. If needed, use a firewall to prevent abuse of ByteBlower. This article  describes how you can configure such an additional management interface.

Lan only

Some cases prevent the use of a Meeting Point in different network segment. E.g. when a device is tested without an upstream link (so testing a gateway between LAN and WLAN, without an upstream path). The only solution then is to connect a secondary management interface to the LAN side of the gateway, as described here:

Connect over the LAN network.

In such a situation, both the management interface on the management network or an upstream interface on the test network are unreachable for the Wireless Endpoints, so the only option is to connect an interface with one of the available LAN ports of the device under test. This ByteBlower management interface should then be either configured to perform DHCP or use a static IP address.

Our ByteBlower GUI from 2.16.2 onwards offers RSSI/BSSID/SSID measurements as standard in the HTML ByteBlower report.

This is great news for our Wireless Endpoint users!

So, how can we take advantage of this new feature? → Roaming tests

As users of wireless devices are often on the move, it is useful to be able to see how this affects the signal strength of the Wifi and how it varies when moving from one access point to another. This is the case when moving around an office for example.

Example Project in the ByteBlower GUI

In this project, we have 3 WEP devices that are connected to the meeting point and will receive downstream UDP traffic.

The WEP's are: 

  • Windows 10 laptop
  • Android mobile device (Galaxy S20)
  • IOS mobile device (Iphone 13)

 

Setting up the Test

 

  • 4 ports are created in the port tab.
  • 1 for a "server"
  • 3 ports corresponding to the 3 WEP devices.

 

 

Create a Frame

  • We use the default frame size for this demonstration.

 

 

Create a Frameblasting Flow

 

  • In this example we have a speed of 0.5 Mbps