This article is a brief tutorial on frame blasting flows with the Wireless Endpoints. We will use the ByteBlower server and MeetingPoint to test a computer connected through a Wi-Fi network. We will assume for the the app to be already running on the computer.

The ByteBlower project file and generated reports are available here.

This tutorial starts with a look at the server view. The project is created from scratch and no server has yet been added.The ByteBlower server and MeetingPoint run on the same physical machine. Both caneasily be added to our list of servers.

Servers and ByteBlower ports

The GUI isn't the source of the network traffic, this task is delegated to several servers. These provide network interfaces to load the network with. In this section we detail adding these servers and configuring the network ports.

We start with adding the ByteBlower server. In the screen-shot below we clicked on the 'new' button and entered the address of the server. For this tutorial, we kept the default name. Of course, one can always change the name of ByteBlower server and MeetingPoint later on.

When pressing the OK button, the GUI will search for all server types at the listed address. Almost immediately it will find the ByteBlower server and MeetingPoint at this physical machine. The image below shows our updated server view. Each server was expanded to show a more detailed overview. The first item is a ByteBlower server with a Trunking and NonTrunking interface. The second item is a Meeting Point. We look closer to this type in the next paragraph.

The MeetingPoint provides a central contact point to any device running the wireless app (computer, laptop, mobile phone). Through this application, the endpoint can be used for network testing. In our example we have two devices: a Linux and a macOS machine. They can be used in very familiar way, just like a regular ByteBlower server interface.

The next screenshot zooms in on the MeetingPoint itself. Hovering the mouse pointer over a wireless endpoint shows additional information. In our example, it lists the OS and its version. On mobile phones one can find the remaining charge of the battery.

ByteBlower ports can be easily docked to these devices. In our scenario we will use two of them: one called WAN and one named Mac Mini. The first, WAN, is used for traffic outside our local network. The second is used to verify the local network from the Mac Mini.

The two screenshots below show the result before and after docking the ByteBlower ports. The first is taken before docking any of the ByteBlower ports. In this image, both the WAN port and Mac mini ports were already configured.
Since we will dock the WAN port on a regular ByteBlower interface, we had to fill almost all the configuration details. The configuration of the Mac Mini is easier. It will be docked to a WirelessEndpoint and there is little configuration necessary. The name was changed for ease of use, and we enabled NAT discovery on this port. As the second screen-shot shows, the configuration details are filled in immediately when docking.

UDP Frame Blasting

In the next steps we will use our ByteBlower ports to generate traffic. Nothing has changed here compared to traffic between regular ByteBlower ports, the same steps could be also used for traffic between regular ByteBlower interfaces.

As a first step we start adding frame templates. Unlike the ByteBlower server, the mobile app has no dedicated hardware. Thus, as any other application, a few minor limitations apply. As a first we can only create IPv4 UDP frames. In addition all UDP ports need to be unique. The screen-shots below show our three frames called SIP, X11 and RTP. In addition to naming their port numbers were changed to set them apart from each other.

Using these frames, we've created three frame blasting flows. For our testing purposes, we've change changed the intended load of each flow. No limit is placed on the maximum load, this depends significantly on the hardware of the app and the network it connects to. In essence it is the main reason for performing these type of tests. A single restriction applies here, flows from a Mobile device must only contain a single frame. This maximizes the performance of the app. The screen-shot below shows our configuration.

Creating test scenario

Finally, the last two steps before running the tests are creating the flows and adding them to the scenario. For ease of remembering we've called them up- and downstream. One can choose any of our previously created ports. While adding them to the scenario, we can easily change the duration and start-time. Each Wireless Endpoint in our scenario supports up to four flows! A slight restriction applies, one is not able to create flows where both source and destination are wireless endpoints. In addition, latency and out of sequence measurements are not yet supported for mobile devices.

Pressing the Run Scenario button starts the test. Scenarios using Wireless Endpoints tend to take bit more time to configure. This is in part due to the added robust necessary for wireless networks. At the end of the test run a summary is created in the report.

This article is a brief tutorial on frame blasting flows with the Wireless Endpoints. We will use the ByteBlower server and MeetingPoint to test a computer connected through a Wi-Fi network. We will assume for the the app to be already running on the computer.

The ByteBlower project file and generated reports are available here.

This tutorial starts with a look at the server view. The project is created from scratch and no server has yet been added.The ByteBlower server and MeetingPoint run on the same physical machine. Both can easily be added to our list of servers.

Servers and ByteBlower ports

The GUI isn't the source of the network traffic, this task is delegated to several servers. These provide network interfaces to load the network with. In this section we detail adding these servers and configuring the network ports.

We start with adding the ByteBlower server. In the screen-shot below we clicked on the 'new' button and entered the address of the server. For this tutorial, we kept the default name. Of course, one can always change the name of ByteBlower server and MeetingPoint later on.

When pressing the OK button, the GUI will search for all server types at the listed address. Almost immediately it will find the ByteBlower server and MeetingPoint at this physical machine. The image below shows our updated server view. Each server was expanded to show a more detailed overview. The first item is a ByteBlower server with a Trunking and NonTrunking interface. The second item is a Meeting Point. We look closer to this type in the next paragraph.

The MeetingPoint provides a central contact point to any device running the wireless app (computer, laptop, mobile phone). Through this application, the endpoint can be used for network testing. In our example we have two devices: a Linux and a macOS machine. They can be used in very familiar way, just like a regular ByteBlower server interface.

The next screenshot zooms in on the MeetingPoint itself. Hovering the mouse pointer over a wireless endpoint shows additional information. In our example, it lists the OS and its version. On mobile phones one can find the remaining charge of the battery.

ByteBlower ports can be easily docked to these devices. In our scenario we will use two of them: one called WAN and one named Mac Mini. The first, WAN, is used for traffic outside our local network. The second is used to verify the local network from the Mac Mini.

The two screenshots below show the result before and after docking the ByteBlower ports. The first is taken before docking any of the ByteBlower ports. In this image, both the WAN port and Mac mini ports were already configured.
Since we will dock the WAN port on a regular ByteBlower interface, we had to fill almost all the configuration details. The configuration of the Mac Mini is easier. It will be docked to a WirelessEndpoint and there is little configuration necessary. The name was changed for ease of use, and we enabled NAT discovery on this port. As the second screen-shot shows, the configuration details are filled in immediately when docking.

UDP Frame Blasting

In the next steps we will use our ByteBlower ports to generate traffic. Nothing has changed here compared to traffic between regular ByteBlower ports, the same steps could be also used for traffic between regular ByteBlower interfaces.

As a first step we start adding frame templates. Unlike the ByteBlower server, the mobile app has no dedicated hardware. Thus, as any other application, a few minor limitations apply. As a first we can only create IPv4 UDP frames. In addition all UDP ports need to be unique. The screen-shots below show our three frames called SIP, X11 and RTP. In addition to naming their port numbers were changed to set them apart from each other.

Using these frames, we've created three frame blasting flows. For our testing purposes, we've change changed the intended load of each flow. No limit is placed on the maximum load, this depends significantly on the hardware of the app and the network it connects to. In essence it is the main reason for performing these type of tests. A single restriction applies here, flows from a Mobile device must only contain a single frame. This maximizes the performance of the app. The screen-shot below shows our configuration.

Creating test scenario

Finally, the last two steps before running the tests are creating the flows and adding them to the scenario. For ease of remembering we've called them up- and downstream. One can choose any of our previously created ports. While adding them to the scenario, we can easily change the duration and start-time. Each Wireless Endpoint in our scenario supports up to four flows! A slight restriction applies, one is not able to create flows where both source and destination are wireless endpoints. In addition, latency and out of sequence measurements are not yet supported for mobile devices.

Pressing the Run Scenario button starts the test. Scenarios using Wireless Endpoints tend to take bit more time to configure. This is in part due to the added robust necessary for wireless networks. At the end of the test run a summary is created in the report.