At times you find yourself repetitively tweaking the speed of a Frame Blasting flow: a little bit faster has too much loss, slightly slower results in no loss, slightly faster again...  This is time consuming and a perfect case for the Throughput wizard.

This Throughput wizard creates several Frame Blasting flows. Each flow sends the same frames but a different load. You'll configure the start speed, the final speed and the increment between them. This wizard is an easy way to generated different flows with a different load in a single scenario. The 6 steps below explain how to configure such a traffic pattern.

Creating the traffic Pattern

Next steps

The next pages of the wizard configure the source and destination ByteBlower ports of the flows. You don't need to use the wizard for these port, if you press 'Finish' the remaining config can also do the config in the GUI itself. A useful hint, with right-click and copy-down you can easily copy the same value to all flows below.

Example result

The screenshot zooms in on the Frame Blasting Flows table in the report. It shows the behavior of our NAT device with small frames. As you'll see in the middle column, the number of transmitted packets steadily increases from 15,000,000. At Throughput Flow 19, the NAT is overloaded and sustains a huge loss of traffic.

A final word

The throughput wizard is an easy way to measure the throughput. It's largest advantage is that you have total control over the traffic if you want to you can still tweak the scenario. For instance, why not add a TCP flow to it? The large report on the other hand might be well be a disadvantage. If you're just interested in getting the throughput limit of your device, then it might be worthwhile to look into the RFC-2544 wizard.

This article collects a number of example BPF filters. The filters are grouped by the OSI layer.

These BPF filters are used throughout the ByteBlower API. Both for counting traffic, as for selecting the traffic to save in PCAP capture.

Layer 3 Network: IP, IP6, ARP, ...

Example	Description
ip	Captures all TCP traffic regardless of lower transport layers
ip6	Selects all IP6 traffic. This is not a default filter but has been added to ByteBlower.
arp	Captures only messages from the adress resolution protocol.
icmp	All ICMP traffic of which ping is the most known application.
igmp	IPv4 Multicast traffic

Layer 4 Transport: TCP and UDP

This is the transport layer, ByteBlower supports the two major families: TCP and UDP. Both protocols can be used over IPv4 or IPv6. When  the network layer isn't explicitly mentioned in the filter all traffic from both is captured.

In the examples below we'll use tcp by default, but the last 3 example filters can also be used with udp.

Example	Description
tcp	Captures all TCP traffic regardless of lower layers transport layers
udp	Same as above, but for UDP
ip and tcp	Capture only traffic over IP
ip6 and tcp	Selects for ip6 and TCP. This not a default BPF filter.
(ip or ip6) and tcp	Same behavior as the first filter. This line is only included as an example, prefer to use the first one.

Filter on ports

Both TCP and UDP use ports. In the examples below, the filters are shown for both protocols.

TCP	UDP	Description
tcp port 80	udp port 80	Captures all traffic from or to port 80. Both directions are collected. This mainly useful for TCP.
tcp src port 80	udp src port 80	Capture only traffic transmitted from port 80.
tcp dst port 80	udp dst port 80	The inverse of the one above, captures all traffic with port 80 as destination

Filter on TCP flags

The filters below are TCP specific. They filter on specific flags. This makes the following filters very useful to capture only the start of traffic, the end or any abnormal behavior.

This type of filters use the array operators of BPF. The filter tcp[13:1] fetches a single byte at offset 13; i.e. the fourteenth byte of the TCP header. This can be written even easier using the tcpflags shorthand. That is used most heavily in the filters below.

Other shorthands are those for those to select the individual bits of the tcp-flags: tcp-fin (= 0x01),

• tcp-fin, with value 0x01
• tcp-syn, 0x02
• tcp-rst, 0x04
• tcp-push, 0x08
• tcp-ack, 0x10
• tcp-urg, 0x20

The BPF syntax has no such definitions for the slightly newer TCP flags: ECE (0x40), CWR (0x80) and NS (0x100). These flags are related Congestion Notification (rfc3168, rfc3540). Especially this last one poses a challenge, it's the final example in the list below.

TCP	Description
tcp[tcpflags] == tcp-syn	Selects the initial  SYN packet. This is the initiation of the session by the TCP client.
tcp[tcpflags] == (tcp-syn + tcp-ack)	This SYN+ACK response from the TCP server.
(tcp[tcpflags] & tcp-syn) > 0	All packets with the SYN flag enabled. This filter matches the traffic of the above two. This filter uses the bitwise and operator ('&') to select the the Syn bit out of the TCP flags.
(tcp[tcpflags] & tcp-fin) > 0	All packets with a Fin flag. Similar to the filter directly above, this also selects packets with Fin + Ack.
tcp[tcpflags] == tcp-rst	Selects all TCP Resets
(tcp[tcpflags] & tcp-fin) > 0	All packets with a Fin flag.
(tcp[tcpflags] & 0x40)  > 0	This filters captures all packets with the ECE flag enabled. Both the initial negation is thus captured, as well as a TCP session echoing congestion on the network.
(tcp[tcpflags] & (0x40 + tcp-syn))  == (0x40 + tcp-syn)	Like the above, this filter selects packets with ECE flag enabled. Extra in this filter is to only select the initial handshake. This is done by adding the tcp-syn value. In other words, this filters all session that capable to react to Explicit Congestion Notifications.
(tcp[tcpflags] & (0x40 + tcp-syn))  == 0x40	The filter is the inverse of the above. It also packets with the ECE flags but also requires for these packets to have the tcp-syn flag disabled. This filters thus on actual cases where the session reactes to an explicit congestion notification.
(tcp[12:2] & 0x100) > 0	As promised, in the last filter the NS flag, or ECN-nonce is used. This flags is experimental, and makes the filter much complex. The NS flag has value 0x100, this larger the usual single byte for the TCP flags. As a result, 12:2 is used instead of tcpflags. This expression selects 2 bytes at an offset of 12 bytes in the TCP header. The remainder of this BPF filter is similar to the above.

This article is a brief introduction to the ByteBlower CLT. This tool is strongly tied to the ByteBlower GUI. With the Command-Line-Tool (CLT) you can run your *.bbp project files from Windows CMD (Microsoft) or Terminal (MacOS and Linux). This is a fast way to start using your ByteBlower for automated testing.

The installer for the ByteBlower CLT is found in the setup pages. This requires is a stand-alone application, next the ByteBlower GUI. It adds the CLT to the local path, it can thus be started immediately from the Command Line. To run the ByteBlower CLT, the GUI doesn't need to be installed.

We start this text with an example on the ByteBlower CLT. We will do a test run and store our reports in a specific folder. Next the article briefly lists the command line arguments to the CLT. This article comes with a number of attachments, these are found at the bottom the text.

Some familiarity with the ByteBlower GUI is assumed.

Example

The project file was created earlier in the ByteBlower GUI. These project files are stand-alone, they can be created everywhere. The file used is also attached to this article: it can be found at the bottom of the text.

In brief, the test project contains a single scenario called 'latency_under_load'. For this example, one might imagine running this scenario (and others!) as part of standard modem test.
The scenario has several actions, but our main interest is running the scenario from a script. This scenario is ready to run, all ByteBlower ports are docked at the correct location. If you just downloaded the example, you will still need to perform this docking step ( how: Open the project in the GUI and dock the ports. Don't forget to save the project).

By default the CLT will store the results of a test-runs together with those of the ByteBlower GUI. As an added advantage, this allows you to access your CLT test runs from the GUI. Now, for the purpose of our example, we also wish to store all test-reports immediately at a convenient location. To this end we've created the folder latency_reports/ locally.

We're ready to start our test-run. The ByteBlower GUI is closed (remember same database-file) and we use following the command below. The explanation of the arguments is found lower. While the test-run is ongoing, the CLT will continuously output text. As we've preferred above, after the test run we will find the generated reports in the requested folder.

[Linux/MacOS]
$ByteBlower-CLT -project <path_to>/clt_demo.bbp -scenario 'latency_under_load' -output latency_reports/

[Windows cmd]
C:\User\wouter.d\>ByteBlower-CLT -project <path_to>\clt_demo.bbp -scenario "latency_under_load" -output latency_reports\

[Python 3.6 (and higher)]

import os
import tempfile

with tempfile.TemporaryDirectory() as tmpdirname:
  os.system(f"ByteBlower-CLT -project clt_demo.bbp -scenario latency_under_load -output report -store {tmpdirname}")

NOTE:
Projects created with the GUI are saved by default at following location:

• WINDOWS : C:\Users\<username>\byteblower\workspace_v2\Projects\
  
• MacOS : /Users/<username>/byteblower/workspace_v2/Projects/
  
• Linux : /home/<username>/byteblower/workspace_v2/Projects/
  

This concludes our example. As mentioned above, the example project is attached to this article. In addition, you'll also find a zip-file with the generated reports. A next step from here is to include this scenario into a larger test-run. Different scenarios in several project files can be started one after the other.

Further steps include processing the generated reports in the JSON or CSV format. An example of such a report is included in the zip at the bottom of this article.

 

Of course, the ByteBlower CLT is limited to the capabilities of the GUI. Even more scripting is possible with the ByteBlower API.

Command line arguments

To conclude, a bit more detail on the ByteBlower CLT. The output below shows the available arguments. This list is also printed to the console on systems with a native shell.

$ ByteBlower-CLT -h
> usage: ByteBlower-CLT [-project] <project-file> (-scenario <scenario>|-batch <batch>)
> Runs the specified scenario or batch of the specified project and generates a report
>   -batch <batch-name> name of the batch to execute
>   -h,--help show this help
>   -help show this help
>   -output <output-dir-path> path to the output directory; defaults to archive dir
>   -project <project-file-path> path to project file to open
>   -regenerate <report-formats> Generates the report of the last testrun.
          This argument is very useful for tests stopped by CTRL-C.
          By default all report formats are generated (html pdf csv xls xlsx json docx).
          You can also supply a selection of these formats as a list (e.g. 'html pdf csv'). 
          This argument makes the CLT ignore arguments -project, -scenario, -batch, -title
>   -scenario <scenario-name> name of the scenario to execute
>   -store <test-dir-path> path to the directory where to store the raw test data; defaults to test dir
>   -title <run-title> run title

Exit Codes

After the CLT finishes, it returns a numeric value. This value can be used to verify that the test scenario finished successfully.
On Windows, the return value is stored in the $LastExitCode variable.
Example: 


Here is a list of possible return codes:

• 0 (EX_OK)
  • Normal program exit.
• 64 (EX_USAGE)
  • The command was used incorrectly. Most likely bad user arguments.
    The user will be provided with a hint for correction.
• 65 (EX_DATAERR)
  • The supplied project file is not readable.
    It might be corrupted, but most likely project is created by a newer GUI version.
    Updating the CLT will fix this last issue.
• 66 (EX_NOINPUT)
  • The requested input did not exist.
    This code will be used for following situations:
    the project file itself does not exist, or scenario or batch do not exist in the supplied project file.
• 70 (EX_SOFTWARE)
  • The CLT encountered an internal problem.
    This should not happen, a bug report should be filed.
• 75 (EX_TEMPFAIL)
  • Temporary failure, indicating something that is not really an error.
    For example, ARP failed.
    The test setup should be verified and the scenario run should be reattempted.

The window size in a TCP connection is a very important parameter. It has a huge influence on the performance, because the receive is the amount of data a host can accept without acknowledging the sender. If the sender has not received acknowledgement for the first packet it sent, it will stop and wait and if this wait exceeds a certain limit, it may even retransmit. If the receive window is too small, a server will wait too often. If a window is too big, chances are higher that a server will send too fast and packet loss will happen.

The optimal value for the receive window is often called the bandwidth-delay product. It is the amount of data which can be sent over a link during the time the server sends the first packet and the time the server receives an acknowledgement for this packet.

So:

Bandwidth-delay product = RTT x BandWidth

Now, to optimize the TCP performance, the calculated optimal receive window should be at least this size and a multiple of the MTU of the link. But, there is also a third important parameter: or TCP, the receive window is announced by two parameters: the windows size in the TCP header, and if supported, the windows scale factor.  This means the ideal receive window must be a value which can be expressed by a window size and scale value.

To calculate the optimized value for a TCP connection, we have created an spreadsheet where you can just enter the different parameters, and you will get the optimal values for both the announced windowsize and windows scale.

[[SecureDownload:ByteBlower/Tools/tcp/TCPWindowScaling.xlsx:Download Spreadsheet.]]

Introduction

Differentiated services or DiffServ is an architecture that specifies a scalable mechanism for classifying network traffic an providing quality of service. It's an evolution of previous technologies such as the TOS-bits in the IPv4 header.

Test Setup

Test Configuration

Testing the result of DiffServ in your network can be done easily using ByteBlower. Once your network devices such as routers and L3 switches, you can verify the result by sending traffic with the appropriate DiffServ flags.

ByteBlower implementation

ByteBlower GUI project

Download

The ByteBlower project file can be found here.

Creation

The ByteBlower GUI allows you to create different frames with different configurations. We use this feature to create the different frames with different DiffServ classes. We use these frames in different flow templates we can then apply between different ports. Depending on your specific network setup and configuration, the flow template can be adjusted ( speeds, …. ) to fit your needs.

Our flows will measure both the packet loss and latency to compare all QoS parameters.

Running a test will produce where you can compare the results with the expected outcome.

 

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.

Since lots of our customers were asking for it.  Here it is: our experimental Python API.

The Python API allows users to script tests just like our TCL API does.  Even more, the syntax is almost the same:  Remove the dot from the TCL function names and you'll have the Python function!  Isn't that easy?
It is not all puppies and sunshine.  Because Python isn't TCL and the release is experimental, there are some warnings and caveats!  Those warnings and caveats are listed later in this article.

Installation

After installing Python, you can download the Python API from here.  After following the installation wizard, everything should be ready to go!

Basic usage

After installation, you can open a terminal and import the ByteBlower package.

from byteblowerll.byteblower import ByteBlower

This imports the ByteBlower module into the current Python space.  Now we can connect to a server and create a port:

# Create a ByteBlower instance first.  In TCL we should write [ ByteBlower Instance.Get ]
byteblower_instance = ByteBlower.InstanceGet()

# Connect to a server (TCL: [ $byteblower_instance Server.Add "byteblower-tutorial..."])
server = byteblower_instance.ServerAdd("byteblower-tutorial-1300.lab.byteblower.excentis.com")

# Create a port (TCL: [ $server Port.Create "trunk-1-1" ])
port = server.PortCreate("trunk-1-1")

# print the current configuration
print port.DescriptionGet()

Python has a neat build-in help function. This works on all API objects. As of now returns a list of methods you can call on the object.

help(port)

which gives following text.

Help on ByteBlowerPort in module byteblower object:

class ByteBlowerPort(AbstractObject)
 |  Method resolution order:
 |      ByteBlowerPort
 |      AbstractObject
 |      __builtin__.object
 |  
 |  Methods defined here:
 |  
 |  CapabilityGetByName(self, name)
 |  
 |  CapabilityIsSupported(self, name)
 |  
 |  CapabilityListGet(self)
 |  
 |  GetByteBlowerInterface(self)
 |  
 |  InterfaceGet(self)
 |  
 |  InterfaceNameGet(self)
 |  
 |  InterfaceSpeedGet(self)
 |  
 |  Layer2EthIIGet(self)
 |  
 |  Layer2EthIISet(self)
 |  
 |  Layer3IPv4Get(self)
...

The complete TCL documentation can be found on api.byteblower.com. Remove the dots (.) in the function names to get the Python name.

Examples

We are creating a library of examples that you can use as a reference for your own development. These examples can be found on our github account: https://github.com/excentis/ByteBlower_python_examples 
Feel free to use it. Are you missing an example, don't hesitate to ask us at support.byteblower@excentis.com

Warnings and caveats

The above Python API is a  public beta version. It's fully functional and used both in- and outside Excentis. But a couple points are worth mentioning:

• There is not yet a complete documentation available.  Since the API is almost the same as the TCL API, the TCL documentation is a good starting point.
• All time configuration items are in nanoseconds and integer values.  There is no support for the shorted syntax as we have in TCL (e.g. "5ms" should be configured as 5000000)

Introduction

When you are testing your device with ByteBlower, you sometimes like to have a pcap-capture of the data for debugging purpose. With the ByteBlower API we can easly capture that network traffic and present it to you as a pcap-file. This feature will help you to debug quickly the problem with your device.

Let me explain how to do this.

Using the ByteBlower GUI

This is the simplest way of capturing traffic. Available since GUI v2.11, and server v2.9. Here you can see how it works :

Options to keep the file size manageable

With the default settings all network traffic is captured from the selected interface. Often this results in very large PCAP files. Since version 2.13 of the ByteBlower GUI, two options are open to reduce filesize:

• Configure a BPF filter.  This filter is applied by the ByteBlower server, only traffic matching the filter is forwarded to the ByteBlower GUI.
• Truncate individual frames. Only the first number are kept in the PCAP and the remainder is dropped.

The default settings for both is capture all traffic.

These two options are available in the advanced config part of the capture dialog. They are configured before the capture starts. Did the capture already begin? The options become editable again in dialog after stopping the capture.

Using the Remote Capture Tool

This was the easiest way of capturing traffic on your port, until we brought the capture functionality to the GUI. It's a command-line tool that can be downloaded from the setup pages. It can be used on Windows, Mac and Linux.

Note:

This tool only works on ByteBlower Server running 2.1 and higher

Using the ByteBlower lower-layer API

When you are using our TCL API to transmit your traffic you can use the Rx.Capture of a ByteBlower Port to create a capture. Using our API allows you to automate when to create a capture. Let your script determine when you need to create a capture.

All you need is the Rx.Capture.Add call on your ByteBlower Port.

Rx.Capture.Add

Just like you add a Trigger to a ByteBlower port you can add a Capture. On this capture-object you can set a capture filter and thus define which frames you would like to see captured. After that just start the capture and you are all set. Now lets put these simple words into a working script.

For this post, we assume we have created a back-to-back scenario with:

• Two configured ByteBlower ports srcPort and dstPort
• a stream Stream configured to flow between srcPort and dstPort

 Create a capture on the dstPort and configure it

set dstPortCapture [ $dstPort Rx.Capture.Add ]

Now you have a capture Object. Using the Tk command you can visualize it to see what you can do with this object.

It is important to set a capture filter on this capture. This will allow you to capture only the packets you are interested in.

$capture Filter.Set "dst port 513"

The filter must be a BPF filter. On http://biot.com/capstats/bpf.html you can find more info on the syntax of these filters and some day-to-day examples.

Start the capture

You can start the capture now.

$capture Start

Now start your traffic and every frame that matches your filter will be captured. You can see how many frames have been captured with the in the result capture object

set captureResult [ $capture Result.Get ]

$captureResult Refresh

$captureResult PacketCount.Get

Stop the capture and get the PCAP-file

Like the start-method there is a stop method the capturing.

$capture Stop

To retrieve your pcap-file use the Pcap.Save method.

$captureResult Refresh

$captureResult Pcap.Save "C:/Users/Excentis/Sniffs/DeviceX.pcap"

On your disk you will find DeviceX.pcap containing the packets that matched your filter that arrived on your ByteBlower destination port (destPort). If you want, you can use Frames.Get to retrieve a TCL-list containing the packets represented in hex-encoding. This way you could use TCL to parse your retrieved packets...

API

You can find the api documentation of the RxCapture here: https://api.byteblower.com/tcl/classRx_8Capture_8RawPacket.html

NOTE:

Why does my capture sometimes contain packets with invalid checksums?

When creating a packet capture (.pcap file) using the ByteBlower GUI, then it's possible that some packets will have an incorrect checksum in the capture. Wireshark typically marks those in red with the hint: "maybe caused by UDP checksum offload?".

That hint is actually correct. In some cases the ByteBlower makes use of checksum offloading. This means that the checksumming is done by the NIC hardware. Because the packets are stored in the capture before sending them to the NIC they still have the invalid checksum in the capture.

Currently checksum offloading is only used for Frame Blasting flows that have one of the following features enabled: latency, out-of-sequence, random size modifier, growing size modifier or field modifier. In all other cases the ByteBlower will perform the checksumming in software.

Remember that the actual packet sent on the network will have the correct checksum! You can verify this by capturing on the receiving interface. The incoming packets will should have a correct checksum. Unless, of course, something bad happened like packet corruption.

The ByteBlower Wireless Endpoint is software that turns your mobile devices into ByteBlower Ports.
With minimal effort, you can integrate iPhones, iPads, Windows phones, Android devices, but also Linux machines, MacBooks, Windows PCs, ... into your network test scenarios.

Requirements

The Wireless Endpoint runs on your SmartPhone, tablet or Laptop; it's the software that generates the testing traffic. You need to install the Wireless Endpoint on all devices you want to test. This Wireless Endpoint software is available for free on all major app stores. You can find the download links collected in the website below.

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

Tests are organized from the ByteBlower chassis. For the Wireless Endpoint to become active it needs to reach the management connection of the ByteBlower. When possible, we suggest connecting the second management interface into the Access Point. This is the Lan only option explained in the the link below:

• https://support.excentis.com/index.php?/Knowledgebase/Article/View/134/51/physical-connection-with-a-meeting-point

On the ByteBlower chassis, it's the Meeting Point software that does the interaction with the Wireless Endpoint. It can be installed on any ByteBlower server when you have a valid license for it.

Basic Workflow

Setting up a Wireless Endpoint is identical on all supported devices.

Start the Wireless Endpoint

Enter the IP address of your Meeting Point. This is required the first time only. Next time, the app will fill in the previously used address by default.

Push the button to go to the next page to connect with the Meeting Point.
The Wireless Endpoint connects with the Meeting Point, and reaches the "Registered" state.

States

On top of the screen, the Wireless Endpoint displays its current state. There are five possible states

• Ready - waiting until you enter the IP address of the Meeting Point.
• Contacting - establishing a connection with the Meeting Point.
• Registered - initial handshake with the Meeting Point succeeded. From now on, the Wireless Endpoint can be controlled using your GUI. The Wireless Endpoint starts sending heartbeat messages to the Meeting Point, to signal that it is still alive.
• Armed - when you run a test scenario using the GUI, the entire set of instructions for this device is transmitted at the beginning. When all instructions are received, the device goes into the Armed state. Now, the Wireless Endpoint becomes quiet, and will no longer send heartbeat messages, so that the test traffic is not disturbed.
• Running - when the start time has come, the Wireless Endpoint will begin sending/receiving network traffic.

At the bottom of the screen, there is an Abort button. When you push this button, the Wireless Endpoint will go back from the Registered to the Ready state. When in the Armed or Running, the Abort button is disabled.

For more information, have a look at this article: Wireless Endpoint States

GUI

From now on, you can sit back and control the entire test process using your GUI.
All you need to do is adding the Meeting Point in the Server View.


All connected Wireless Endpoints become visible.


Now you can dock ByteBlower Ports on your Wireless Endpoints to integrate them into your test scenarios.

Running Test Scenarios

When you start a test scenario using Wireless Endpoints, the Meeting Point will automatically initialize all Wireless Endpoints.
All Wireless Endpoints go into the "Armed" State.


While the actual test is running, there is complete radio silence between the Meeting Point and the Wireless Endpoints.
This way, the network test traffic itself is not influenced by any unwanted signals.
When you look at the Wireless Endpoint while a test is running, you can see the Current Speed.


After the test finishes, the Meeting Point gathers all results from the Wireless Endpoints.
And then the report is generated.

Have a great time using our Wireless Endpoints !

Introduction

An internet stream isn't always a perfect flow of bits at a constant rate. So for your tests you want to create such a burst flow. This article describes how you can simulate a UDP flow with burst using our GUI.

How

To create a multiburst UDP flow we start with the basic components : A source port and a destination port. We provide them a correct mac and IP setting and dock the ports on our server. 

Next we create a frame we want to transmit. We give this frame our desired size and if needed the wanted UDP source/destination port numbers. In our example we will use a frame of 128 bytes.

It is now in the frameblasting template that we will define the speed and the burstiness of our flow.

Create a new template and add the frame (our frame of 128 bytes created in previous step). With the edit button in the middle plane we can configure the speed and add a timing modifier. It is this timing modifier that creates the burst profile.

Under the tab Speed we configure the speed of the flow. Lets configure this to a UDP flow of 2Mbit/s. The Timing Modifier tab allows us to add a time modifier to the flow to create a burst profile. Here we can configure 2 parameters.

Interburst Gap: this is the time between 2 burst. During this period no frames will be transmitted

Frames per Burst: How many frames need to be transmitted during a burst

In the Flow view we connect the source,destination and the flowtemplate together to create our flow. We can use this Flow now in our scenario and provide here the duration wanted for the flow. You can also define the number of frames you want to transmit. The GUI will then calculate the duration.

Now we are ready to run the project. Below you see the result report showing the bursts.

Example project

Attached on this KB you will find the project created during this article. Download and modify it to fit your needs.

The ByteBlower GUI supports several different report file-types.

• PDF
• HTML
• JSON
• CSV
• XLS

In the preferences you can select which reports you want to generate after a test. Or you can even disable them if you aren't interested in the results.
This animated GIF shows you how you can change this.

Basic Use Cases - Measuring Throughput

 

Having installed your ByteBlower system and checking that it works (quick self-test), you might be wondering what else you can do with it! There are endless possibilities so we will look at some basic use cases for the ByteBlower GUI to answer typical questions that testers have. One such example is:

 

• What is the maximum throughput of my system? 

 

This is a common question that a system user has and so in this article, we will guide you through a series of basic tests that can help you learn information about a system's throughput capabilities.  

 

This article will cover →

1) UDP frame blasting approach

2) TCP approach

                                        

          ⇒ The LAN and WAN ports will be connected to different trunk ports on the ByteBlower server which will enable different scenarios to be tested.

 

 

STEP 1 - UDP Frame Blasting Test

We will start with a UDP test. Frame blasting allows us to focus on the amount of data that is received. This approach doesn't require any limitation on the transmission rate of the data. 

 

• This type of test allows us to get results quickly.
• It is easy to control and debug

However,

• It takes time to setup
• Results vary depending on how good your initial estimate is.

 

1.1 Setting Up a First UDP Test

 

• Download the project from https://github.com/excentis/ByteBlower_GUI_examples/tree/master/basic_usecases. 
• Open the .bbp file 'measure throughput' 
• You will see a file that has two ports created → LAN & WAN
• The ports have been configured for DHCP
• The LAN and WAN ports need to be docked onto the trunk ports on interface 1
• The trunk ports that are chosen must be able to work with DHCP

 

1.1.1 Dock the Ports

Here you will see that two ports have been created for you and they have been named LAN and WAN. You will also notice that they have small red crosses next to them. This means that they aren't docked yet. 

 

                 

 

 

• In this demonstration, the LAN and WAN ports are docked onto two trunk ports that are on the SAME subnet and that are DHCP capable.

 

            

 

1.1.2 Frame

When you open the 'Frame' tab, you can see that a frame has already been created. The frame is small (60 bits). Large frames tend to mainly load the network. Smaller frames allow for the checking of packet processing bottlenecks.

                   

 

1.1.3 Frame Blasting

• Frame blasting flows create a repeating flow of frames with a size determined in the previous step (60)
• This frame blasting flow (UDP) is an easy way to simulate traffic.
• The physical load is the speed of the throughput. 
• The frame rate and interval are automatically calculated based on your choice of the physical load.

In this demonstration we are using a 1 Gbps port so the maximum speed is 0.95 Gbps. 

                       

 

1.1.4 Flow

The flow tab is used to finalize the traffic flow by choosing which port is the source and which is the destination.

When you open the 'Flow' tab, you will see that 2 flows have already been created → 1 UDP and 1 TCP.

The flow runs from the LAN to the WAN and for now, no latency measurement is being made. This flow will be used to run the first test.

                               

 

1.1.5 Scenario - Running a Test

Up to this point, there has been no real communication or connection with the ByteBlower server. Once we run the test, the server comes into the picture

Go to the 'Scenario' tab and select the correct scenario from the two that have been created (Max_frame_blasting).

The flow is the one from the previous section. The test duration has been set at 30 seconds though this can be changed as wishes.