For most Android Devices there's the Google Play store to install the ByteBlower Wireless Endpoint. This page is intended for those devices that can't find the app there. We'll focus on Android TV, but the same steps also apply others, like those without public internet access.

The steps below use the Android.apk file. This file is available on our setup pages. As found in the section below, it doesn't hurt to just try this file first.

• https://setup.byteblower.com/wirelessendpoints.html

Step 1. Enable Developer access

To install the device needs to be put into developer mode. Default this option is hidden but can enabled with the following actions.

• Go to the settings of the device and search for the "build number".
  You can also navigate to it from "device info" or the "About" sections of the preferences.
• The build number looks like a plaintext value, but it has a hidden feature. After selecting, clicking or tapping the value 7 times, the device notifies you that the developer options are enabled.
• The preferences now have an extra section with the developer options. Just as shown in the picture below.

On Smart TV or Setup boxes it can help to attach a USB mouse.

Step 2. Installing Android Debug Bridge (adb)

This step is done on a laptop or PC. The installation will use the Android Debug Bridge. This tool is part of the official Android SDK. To install it we suggest following the guide for the SDK Manager or just download the tools directly from the link below

• https://developer.android.com/studio/releases/platform-tools

The adb is a command-line program. It is found in the installation folder of the Android SDK, more precisely in the platform-tools folder.

On Linux, adb can also be found in the default package manager of your Linux Distribution. For Ubuntu, this means following:

• apt-get install adb

Step 3. Using the ADB for installation.

In this final step, the new developer options are used with adb to install the Wireless Endpoint app directly.

First, on the device itself enable the USB debugging mode. This option is found in the developer options of step 1.

adb is used in the second step, the actual installation. The example below is from Windows. As written higher up, the same tool is also available for Linux and OSx. On these platforms the command is plain adb.

The commands (bold) and their output are found below. The commands assume the platform tools are installed in C:\Android\platform-tools.

C:\>cd C:\Android\platform-tools

C:\Android\platform-tools>adb.exe usb
* daemon not running; starting now at tcp:5037
* daemon started successfully
restarting in USB mode

C:\Android\platform-tools>adb.exe install ByteBlower.apk
Performing Streamed Install
Success

Take care, depending on Android version the USB debugging is only enabled for the current boot. It's a good idea to check the value again when the next part would fail.

Additional Hints

In this section a couple bit of extra help.

#1 Simple Download and install

The steps above are required for Android Tv and other devices. On other devices, you can start simply start with downloading and running the ByteBlower.apk file. It might just work!

#2 Remove the existing installation

In some case you get the error as shown below. This can happen if the Wireless Endpoint was already installed in the usual way. Simply removing the existing Wireless Endpoint is enough to proceed with the above steps.

adb: failed to install ByteBlower.apk: Failure [INSTALL_FAILED_ALREADY_EXISTS: Attempt to re-install com.excentis.byteblower.wirelessendpoint without first uninstalling.]

#3 Use the Sideload Launcher app to find the Wireless Endpoints back

This hint is in particular for Android TV. The Wireless App won't among the default installed Apps. A work-around is to install the Sideload Launcher app. Here, the Wireless Endpoint will be listed. This makes it easy the use it later on.

#4 USB hub and Mouse

The final hint, the Wireless Endpoint app is built with Mobile phones and Tablets in mind. For navigating the app, it sometimes helps to use a computer mouse. A USB hub can be used as an intermediate to match the different connectors.

Since the ByteBlower Wireless Endpoint app runs on a lot of hardware and operating system configuration, some questions are asked at regular intervals.

The most common questions are listed below.

Wi-Fi statistics availability

Q: The Wi-Fi statistics have strange values in them?

A: The ByteBlower Wireless Endpoint tries to collect as much statistics as it can.  In modern operating systems (like iOS, Android...), the access to some of these statistics is restricted, other statistics are not available at all.  This is usually done to protect the privacy of the end-user.  When the ByteBlower Wireless Endpoint is not able to collect a parameter, it will return a default value.  The defaults are listed below:

• SSID: an empty string
• BSSID: the null-MAC address: 00:00:00:00:00:00
• RSSI: -1
• Channel number: -1
• Tx rate: -1

Q: On Android, the Wi-Fi statistics are missing

A: Android uses a permission system to grant apps access to certain components of the operating system.  Wi-Fi parameters are part of the location permission.  Granting this permission to the ByteBlower Wireless Endpoint app enables it to collect these.  Also location must be enabled.

Q: On iOS, the Wi-Fi statistics are missing

A: iOS does not provide access to the RSSI, Channel number and Tx Rate, so the Wireless Endpoint will always return -1 as value.

Miscellaneous

Q: The Wireless Endpoint announces the wrong IP address

A: The application collects all available IP addresses on the device it is running on.  The first IP address found, is shown in the ByteBlower GUI.

Windows 10 provides the last known IP address of an interface even when the interface is down (e.g. the Ethernet cable was disconnected from the interface).

Wireless Endpoint Performance Statistics

This page lists the performance statistics for the different Wireless Endpoint versions. These values give us confidence that release to release the app is improving.

For the first release we've done an absolute measurement. These results are a good indication on what you can achieve with the app in a well performing Wi-Fi environment. Depending on your setup and local interference you might measure different values.

In subsequent releases the numbers are both absolute and relative: we run the tests on both the old version and immediately after on the new version. So next to the new performance numbers, there is a direct check on performance regression. Changes of up to 5% can be attributed to small environmental changes.

Measurement setup

We tested the devices using the following physical setup:

• A ByteBlower 1300 running the latest available ByteBlower software
• An ASUS GT-AX11000 access point
• The Wireless Endpoints are placed next to each other on a distance of 1.5m (5ft) of the Access Point
• The ByteBlower server was connected using an NBASE-T enabled port of the access point.

ByteBlower setup and test parameters

• 1 Flow for the TCP downstream
• 1 Flow for the TCP upstream
• Every flow has a duration of 2 minutes
• Flow parameters are the defaults of the ByteBlower GUI.

Statistics

The performance statistics below are collected for several Wireless Endpoint versions. The version under test is found in each title.
The setup-pages and the App stores only show latest release but older versions can be requested through ByteBlower support.

Version 2.10.2

ByteBlower server version: 2.10.2

This is the first test-run, reported values are absolute.

Device	Operating System	WiFi / Wired	TCP Throughput Download (Mbps)	TCP Throughput Upload (Mbps)
Apple iPadAir2	iOS 12	WiFi	512,04	573,24
Apple iPhone 7	iOS 12	WiFi	571,60	584,38
Apple macBook Pro (2017)	macOSX 10.14 (Mojave)	WiFi	656,78	646,99
Dell Latitude E5570 laptop	Windows 10	WiFi	948,71	907,95
Samsung Galaxy S8	Android 8	WiFi	713,71	580,17
Samsung Galaxy S10	Android 9	WiFi	668,48	609,57
Samsung Galaxy Tab2	Android 7	WiFi	340,83	382,16

Version 2.10.4

ByteBlower server version: 2.10.8

This test-run we compared to version 2.10.4 to the previous one (2.10.2). The reported values are the relative. There was no regression. Significant improvements are colored green.

Device	Operating System	WiFi / Wired	TCP Throughput download (mbps)	TCP Throughput download (%)	TCP Throughtput upload (mbps)	TCP Throughput upload (%)
Apple iPadAir2	iOS 12	WiFi	580,88	+13.0%	540,95	+1.6%
Apple iPhone 7	iOS 12	WiFi	587,56	-0.7%	554,52	+0.4%
Apple macBook Pro (2017)	macOSX 10.14 (Mojave)	WiFi	672,18	+16.9%	649,60	+0.2%
Dell Latitude E5570 laptop	Windows 10	WiFi	1309,89	-1.0%	361,18 (*)	+20.2%
Samsung Galaxy S8	Android 8	WiFi	798,90	+4.1%	562,28	+44.5%
Samsung Galaxy S10	Android 9	WiFi	659,37	-0.4%	561,51	-1.4%
Samsung Galaxy Tab2	Android 7	WiFi	331,52	-0.3%	361,74	33.0%

(*) Windows installed updates of the network card drivers compared to the 2.10.2 version. In our opinion, these drivers are still in beta state, causing differences with each update.

More questions about the setup? Don't hesitate to contact us at support.byteblower@excentis.com

How to: Run the ByteBlower Wireless Endpoint using the command line

Background

The ByteBlower Wireless Endpoint used to run only using a graphical user interface.  This is nice, but what about headless servers?
Since 1.1.22, the ByteBlower Wireless Endpoint supports a basic command line interface. This is of course only applicable to those running the app in Windows, Linux or Mac.

This article will guide you through the options and behaviour.

Command line

A single executable runs both the graphical and Command line interface. Which one starts depends on the program arguments.

Linux

• Use no program arguments to start the graphical view
  

  # byteblower-wireless-endpoint

• Add a MeetingPoint address for the command line mode
  

  # byteblower-wireless-endpoint 10.5.5.144

More help is available with the -h or --help arguments. You'll receive the text below:

MacOS

• Use no program arguments to start the graphical view
  

  # /Applications/ByteBlower Wireless Endpoint.app/Contents/MacOS/byteblower-wireless-endpoint

  or dubble click on the application
• Add a MeetingPoint address for the command line mode
  

  #  /Applications/ByteBlower Wireless Endpoint.app/Contents/MacOS/byteblower-wireless-endpoint 10.5.5.144

More help is available with the -h or --help arguments. You'll receive the text below:

Windows

• Use no program arguments to start the graphical view
  

  #  ByteBlowerWirelessEndpoint.exe

  or dubble click on the application
• Add a MeetingPoint address for the command line mode
  

  #  ByteBlowerWirelessEndpoint.exe 10.5.5.144

More help is available with the -h or --help arguments. You'll receive the text below:

# byteblower-wireless-endpoint --help
Usage: byteblower-wireless-endpoint [options] meetingpoint
Connect the wireless endpoint to the Byteblower MeetingPoint and it will serve as a traffic generator and monitor

Options:
 -h, --help Displays this help.
 -v, --version Displays version information.

Arguments:
 meetingpoint The IP address or resolving domain name of the meetingpoint

The output

When the app is connected to a meetingpoint, the output will be updated with periodically

# byteblower-wireless-endpoint byteblower-tp-1300.lab.byteblower.excentis.com
 • Status: Registered || Rx: 0.00 Mbps | Tx: 0.00 Mbps

What can be seen on this output?

• The dot in the beginning of the line:
  The dot will blink with every heartbeat.  This is the application trying to communicate with the ByteBlower Meetingpoint.
• Status:
  The status field shows the status of the application. 
  • Contacting: it tries to connect to the meetingpoint.
  • Registered: the application is idle and is waiting to receive a command from the ByteBlower
  • Armed: the application has received a command to run a scenario, it is waiting to start the actual traffic.
  • Running: Traffic is ongoing
• Rx and Tx: 
  This is the throughput the app is receiving (Rx) and transmitting (Tx).

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:

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.

• https://support.excentis.com/index.php?/Knowledgebase/Article/View/140/52/how-to-configure-the-management-ip

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:

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.

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:

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.