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 !

The TCP congestion avoidance algorithm affects how fast the throughput is able to recover after packet loss. There's no ideal solution, and over time several approaches have been described.

The ByteBlower GUI implementes a couple of the most popular ones, you can choose from following list: “None”, “New Reno”, “New Reno with Cubic”, “SACK” and “SACK with Cubic”.

Regardless of the option, the ByteBlower’s TCP implementation will always perform the basic congestion avoidance measures like exponential backoff and slow start. (See Wikipedia’s article on TCP congestion control for more information.).

The summation below explain each available option:

• When selecting “None” then no fast recovery algorithm will be used. It does, however, implement fast retransmit.
  
  
• “New Reno” is a loss recovery algorithm that improves recovery speed when multiple packets have been dropped.
  
  
• “SACK” (short for “selective ack”) is an even faster recovery algorithm where the receiver can tell the sender which segments are missing . This algorithm can only be used if both sides support it. This is negotiated during connection establishment using the “SACK Permitted” option in the TCP header. If one of the sides does not support SACK then ByteBlower will use New Reno instead.
  
  
• “Cubic” improves the TCP recovery speed on high latency networks while still providing good performance on low-latency networks. It can be combined with SACK and New Reno (by selecting "SACK with cubic" or "New Reno with Cubic")
  
  
• “SACK with cubic” is the option that should provide the best performance in most situations.

This article is a short guide on how to create an RFC-2544 test with the ByteBlower GUI. This test estimates the throughput of your network. The main advantage is that you have proper control over a number of parameters. The drawback is that RFC-2544 test runs tend to take quite some time.

The text begins with a short introduction and ends with a couple pointers on next steps.

Introduction: Creating a first RFC-2544 scenario

RFC-2544 tests are created with the RFC-2544 wizard. As you'll see further on, this wizard will create a couple ports, a flow and a scenario for you to run. This is very similar to any of the other traffic flows (FrameBlasting, TCP).

As the screenshot below shows, the RFC-2544 wizard is found in the menu bar under Wizard-menu at the top of the ByteBlower GUI.


The first 3 screens have an introduction and give you the chance to configure the source and destination of the test. These steps are the same as the other wizards. The result of the steps in the screenshots below are two new ByteBlower ports:

• RFC_2544_SOURCE_1
• RFC_2544_DESTINATION_1

Both are regalar ByteBlower ports.  The config below, they receive their IPv4 address through DHCP. As will be shown further, you can still change the ports afterwards.



Only in the final window you'll find RFC-2544 specific parameters. You'll need to configure following 3 items:

• A list of frame sizes
• The duration of a single iteration/step
• and the acceptable loss level.

As we've said in the intro, the main drawback of RFC-2544 tests is their duration. Only the first two parameters have an impact on the duration. On each change, the total duration shown at the bottom of the window is updated. This total duration is an estimate, in most occasions the test will finish a lot sooner.



The end result of this Wizard is seen at these places:

• Port view: there are 2 new ports.
• Flow view: An extra flow that uses the newly created ports. The details of the template are shown in the info panel next at the left.
• The Scenario view has an extra scenario using the new flow.

All three windows are shown in the screen screen shot below.

Running an RFC-2544 test

The results

Hints and tricks

Testing IPv6

The RFC-2544 flow can handle IPv6 ByteBlower ports. Since the wizard default generates IPv4 ports you'll need to reconfigure your project a bit. You've got two options:

1. Drag the newly generated ports from the IPv4 panel to the IPv6 one.
2. Create new IPv6 ports and use these as source and destination.

Editing fame sizes and loss level

To change the frame sizes and loss level, go tho the Flow-view and right-click on the Flow Template. In the popup-menu select "Jump to Edit..."

Here you now can change the frame sizes and the acceptable frameloss of the RFC2544 flow.

Introduction

Port groups have been added to the ByteBlower GUI in version 2.8. They were added with DOCSIS 3.1 in mind, but you'll notice that they're also very useful with WiFi and other network configurations. This is a short article which won't reveal every possible use-case. The goal is to explain how you create a Port Group, and why you want one. Next we'll make a simple scenario and review its results.

The goal of a port group

When creating a test scenario for a particular high-bandwidth CMTS or access point, you'll often notice that you're repeating yourself. A single CPE/LAN interface isn't sufficient to fully load the modem or Access Point. An example is found on the figure below. To solve it, one would add several LAN interfaces and create several flows to them. The end-result is often much duplication and elaborate bookkeeping to find out how much bandwidth is transmitted. With the Port Groups this becomes much more easy: you can immediately create network traffic to a group of ByteBlower Ports.

How to use them

Creating a new Port Group starts in the Port view. You'll need to configure the individual ByteBlower Ports and dock each to the right interfaces. This hasn't changed. In the figure below we've created 4 Lan ports and docked from trunk-1-20 up till trunk-1-23.  A WAN port is docked to a 10 Gbit/s nontrunk interface. In our scenario, we'll send traffic from this WAN port to all LAN ports. To create the Port Group, we've selected the LAN ports and pick the Group action in the right-click menu.




The result is shown below. For ease of working we've renamed the group to LAN. If you expand the group, you'll find its members. The Group itself has no options, but you are still able to change the config of each member.



From here on, creating your testing scenario is very familiar. Next step is creating a Frame and adding it to a FrameBlasting template.  As shown in the first figure, we'll configure the speed of this template to 3 Gbit/s and use it for our Flow. As you'll see below, this Flow will transmit from the WAN port to the LAN group.

• The WAN port will send out at a rate of 3 Gbit/s.
• In total 3 Gbit/s is received by the LAN group. 

Behind the scenes, the transmitted data is evenly divided across all members of the group.




This flow is used in the scenario of the attached report.  A couple points stand out.

• In IPv4 ByteBlower Ports section, you'll find the the group and its members again. There's a first table with the sole ungrouped ByteBlower Port. Below that, you'll find the listing of the LAN port group.

• All following sections show the combined results.

This article explains the available options for TCP flows.

Name

The Name of the of the TCP flow template. This needs to be unique from the other TCP and FrameBlasting Flow templates.

Duration

The column configures how long or how much data the TCP flow should transmit. There are two options here:

• Payload based: The flow will transmit the configured payload and close the connection. This amount is the total data size. The overhead at the TCP layer and below is not omitted.

• Time based: This is method is similar to FrameBlasting templates, the flow will transmit for a fixed duration. How long it should send is configurable from in the Scenario View.

Rate Limit

This applies an optional rate limit to the TCP flow. Similarly to e.g. video streaming or downloads, this rate limit is applied at the amount of data supplied to the TCP flow.

Unscaled Initial Receive Window

The TCP protocol uses this parameter to initialize the Receive Window. The Maximum Receive Window is 65535 bytes. The TCP Window is the amount of outstanding data (unacknowledged by the recipient) that can remain in the network. After sending that amount of data, the sender stops and waits for acknowledgement back from the receiver that it has gotten some of it. As such, this value together with its scaling factor is probably the single most important setting in tuning broadband internet connections.

Window Scaling

Enable or disable window scaling here. The TCP window scale option is an option to increase the TCP receive window size above its maximum value of 65535 bytes.

Receivers Window Scale Value

Here you can choose which window scale value should be used. Following options are possible:

• 0 (multiply with 1)
• 1 (multiply with 2)
• 2 (multiply with 4)
• 3 (multiply with 8)
• 4 (multiply with 16)
• 5 (multiply with 32)
• 6 (multiply with 64)
• 7 (multiply with 128)
• 8 (multiply with 256)

Slow start threshold

This is a low-level parameter of the TCP algorithm. Throughput grows exponentially until this value, afterwards on speeds increments linearly and thus slow. Increasing this parameter results in steeper, faster throughput gains, but often also more instability. Reverse, a low value results in TCP flow that slowly increases throughput.

HTTP Request Method

Choose which method should be used to get the payload from server to the client. Following options are possible:

• AUTO: The GUI will choose the appropriate method (GET or PUT). When the source ByteBlower Port of a TCP Flow is natted, a HTTP PUT command will be used, otherwise, a HTTP GET command will be used.

• PUT: The source ByteBlower Port will initiate the data transfer by executing a HTTP PUT command. The data will be ”uploaded” from the source to the destination.

• GET: The destination ByteBlower Port will initiate the data transfer by executing a HTTP GET command. The data will be ”downloaded” from the source to the destination.

Congestion Algorithm

The algorithm used by the TCP flow to deal with congestion.

Client and Server Ports

The TCP-ports used by the flow template. When left to automatic, the ByteBlower will pick an available port to setup the flow. In general this is the preferred option.

When you start running a test Scenario, the ByteBlower GUI/CLT tries to detect colliding Frames.
In this article, I'll explain what colliding Frames are, how they can corrupt your test results, and of course, how you can prevent or resolve these.

What are Colliding Frames ?

Each ByteBlower Port that is used as destination of a Flow, will contain filters to count the arriving frames, belonging to that specific Flow.
When your test involves multiple Flows, the filters will automatically be optimized, to make each one of them unique.
This way, we can be certain that only the Frames belonging to one specific Flow will be filtered out.
But when the frames used in different flows are identical or very similar, it is sometimes impossible to create unique filters.

At that point, it is no longer possible to determine which received Frame belongs to which Flow. 

As a result, the Frames belonging to multiple flows will be filtered by multiple destinations !
This typically results in negative loss. This means that you receive more packets than you have sent.

During the Scenario initialization, colliding Frames are detected, and a warning is generated.
Typically, a message will pop up to draw your attention, unless you switched this off in the Preferences.
In any case, the warning will be added at the bottom of the reports.

Possible solutions

The solution to make the Colliding Frames warning go away is to make all involved Frames unique.
There are several options to do this :

• By enabling the Unique Frame Modifier on Layer 4 of the Frames.  This option will make all Frames uniquely identifiable at all destinations.
• By changing the length of one of the Frames
• By changing one byte in the payload of one of the Frames
• For UDP frames without NAT discovery one can pick different UDP ports.

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.

All traffic in a ByteBlower is transmitted and received through ByteBlower Ports. Conceptually these Ports can be seen as small, virtual EndPoints in your network. As any other endpoint they need various network settings to communicate with the outside world. Physically they're docked (or attached) to a specific ByteBlower interface. This article explains the configuration options of a IPv6 ByteBlower Port.  We start from the screenshot below.

Name

The name given to a ByteBlower port. This name is used solely within the ByteBlower GUI, it's not send out over the network. To avoid confusion, all ports in the same project have different names.

MAC Address

As any other network device, a ByteBlower port requires a MAC address. Default this address is used for all traffic in and out of the Port. Often it's a good idea to for this address to be unique, but this not required (e.g. dual-stack IPv4 and IPv6). For IPv6 ByteBlower ports, the MAC address is used to generate the link-local address.

Configuration

The method used to obtain a global IPv6 address for the ByteBlower Port. This can either be:

• Fixed, or user-supplied: The ByteBlower Port will use the values of the IPv6 Address, Router Address and Prefix Length column. Even in this mode, the ByteBlower port will still send out Neighbourhood solicitations and join the required Multicast groups.

• Stateless Auto Configuration: The ByteBlower Port obtains its global address from the IPv6 router in the network. This method doesn't really have an analogue in IPv4. It's described in RFC 2462 or in http://ipv6.com/articles/general/Stateless-Auto-Configuration.htm

• DHCPv6: A DHCPv6 server offers an address to the ByteBlower port. From a high-level perspective this is very similar to DHCP in IPv4. In ByteBlower GUI you reuse the same DHCP-settings object between IPv4 and IPv6.

The IPv6 Address and Router Address and Prefix length columns are solely are solely available for Fixed configurations. In the other configurations they are obtained from the network. More info on these fields is found in https://tools.ietf.org/html/rfc3513 .

VLAN Stack

A ByteBlower port can be configured with a VLAN tag or even a VLAN stack (QiQ). These tags are known as Layer2.5 configurations. They are used to create virtual networks within a physical network. The ByteBlower GUI will automatically add these tags to all outgoing traffic. Similarly all arriving traffic at a ByteBlower Ports needs the same Layer2.5 configuration.

MTU

This columns configures the maximum size of the frames transmitted from a ByteBlower port. TCP traffic from this port will respect this size, similarly one can't transmit FrameBlasting frames larger than this size. This limit doesn't apply to received frames.

The MTU is expressed in bytes. It counts the size of a

Docked

As mentioned in the introduction, a ByteBlower port emulates an Endpoint in the network. For it to be useful it needs needs to be physically docked to a ByteBlower interface. All incoming and outgoing traffic of this ByteBlower Port goes through this interface.

On this page you find the latency noise floor of the ByteBlower systems. This provides the lower bound of what can be reliably measured.

Better performing systems are found on the left side.

Running Big Scenarios

Since version 2.18, the ByteBlower GUI contains some new features that make it easier to run big test scenarios.
Such tests are often called "stability tests", "stab tests" or "endurance tests".
You may have gotten here after clicking on a help button in the GUI.

New Features

• Real time metrics are now exported by the GUI so they can be processed externally.
  In another article, we explain how to use the exported metrics: Getting started with Prometheus
• For big scenarios with more than 100 flows, the GUI will no longer store the results over time. The reports will no longer contain graphs.
  These scenarios will be marked with an exclamation mark:
  
• In the Solution tab, you can see why:
  
  Double-clicking on the warning will open this help page.
• If you run a big scenario, the following warning will pop up:
  
  Clicking on the Help button opens this page.
• In the Project Properties, you can now even disable graphs with results over time entirely.
  Have a look under the menu File > Project Properties > Report.
  
  This means that you can disable results over time even for small scenarios if you like.
  When disabled, the warning icon will disappear from all big scenarios. 

What was the problem?

We added these features because we experienced that the machine running the ByteBlower GUI was sometimes not capable of storing all realtime results quickly enough.
While running a long test with lots of flows, the GUI became less responsive and some results could get lost.

Questions?

If you have any questions, don't hesitate to contact us at support.byteblower@excentis.com
Thank you!

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.

ByteBlower Ports are actually logical ports, that need to be created on a physical location before they can be used.
In the Configuration View, you can link, or "dock" as we call it, each ByteBlower Port to a physical location on a ByteBlower Server.

On the left side of this view, all available ByteBlower Servers are displayed.
After refreshing a server, you can see the available interfaces : Trunking interfaces, which are connected to a switch, and Non-Trunking interfaces.
ByteBlower ports can only be docked to Non-Trunking interfaces, and on the ports of a switch, behind a Trunking interface.

On the right side of the Configuration View, you get an overview of all ByteBlower Ports in the current project.

By default, the "Hide docked ByteBlower Ports" option is enabled. This means that only ByteBlower Ports that still need docking will be visible here.

Docking can be done in several ways:
 * Using the Docking buttons : Use the arrow to the left to dock, and the arrow to the right to undock.
    Select a physical location on a ByteBlower Server
    Select the ByteBlower Port that you want to dock on it
    Then click on the "<-" arrow to dock the ByteBlower Port on the selected location.
    When the "Hide docked ByteBlower Ports" option is enabled, the ByteBlower Port will disappear from the list at the right side.
    The ByteBlower port will appear at the left side, as a sub-item under the selected location
    Also, in the Port View, you will see that the "Docked" status becomes "OK"
    The ByteBlower Port is now ready to be used in a test Scenario
 * Drag - Dropping
    Drag the ByteBlower Port that you want to dock to a Physical location, and drop it there.
    When the "Hide docked ByteBlower Ports" option is enabled, the ByteBlower Port will disappear from the list at the right side.
    The ByteBlower port will appear at the left side, as a sub-item under the selected location
    Also, in the Port View, you will see that the "Docked" status becomes "OK"
    The ByteBlower Port is now ready to be used in a test Scenario

Tips 'n Tricks
 * Only while a test Scenario is running, are ByteBlower Ports "alive" on the specified Physical Ports.
 * ByteBlower Ports can not be docked directly on a ByteBlower Server or on a Trunking Interface.
 * ByteBlower Ports can only be docked on a Non-Trunking Interface or on the Physical Ports of a switch behind a Trunking Interface.
 * When you dock ByteBlower Ports directly on a ByteBlower Server, they will be docked on the physical locations found in the sub-tree.

This is demonstrated here:

 * Multiple ByteBlower Ports can be docked in one action !
    Use the <Shift> and <Ctrl> keys to select multiple ByteBlower Ports.
    You can also use <Ctrl-A> to select all ByteBlower Ports
    Then select a Physical location at the left side, and click on the "Dock"-button
 * Multiple ByteBlower Ports can also be drag-dropped together !
 * Typically, you don't want all ByteBlower Ports to be docked on the same Physical location. Instead, most of the time, you want each ByteBlower Port to be docked on the next available Physical Port.
    This can be done by selecting multiple objects, both at the right and at the left side.

This is demonstrated here:

Hint: Enable or disable Quick select

The quick select button (green, fiigure) in the menubar is an aid to quickly find the network interface a ByteBlower port has been docked to. This very useful when you want to undock a ByteBlower port or dock a new one close an existing docked port.

The gif below shows it's behavior when enabled.

This option is can be very useful when working with multiple ports, but for single ports you might want to disable it. We have a couple hints below, but of course do experiment and see what works best for you.

Quickly Undock all ports

• Enable the quick select
• Select all ports
• Press the right arrow ( )

Quickly Dock to a nearby interface

• Enable the quick select
• Select port you'd like to use as template
  • The associated ByteBlower interface is now focused. The left part of the ServerView jumps at the docked interface
• Select the interface you wish to dock the ByteBlower Port to and use the arrow pointing left ()

Cherry-picking the interface

A disadvantage of the quick select is that can change your selection by accident. This can be especially annyoing when you wish to redock a single port,  in thi case you might want to disable the quick select.

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.

How to Install and Run a Simple Test on the Wireless Endpoint App

The purpose of this article is to help you get started with the 'Wireless Endpoint' app easily and efficiently and run your first test!

The  app is a very convenient and useful tool which helps the user test a wireless device or a range of devices and compare their performances. In this article we will create a simple test example that sends traffic from a 'server' to a device connected to WIFI. 

We will cover  ⇒ 

                                  1) Downloading the app and connecting your device(s) to the ByteBlower server

                                  2) Creating and connecting ports

                                  3) Setting up test parameters

                                  4) Running the test

                                  5) Troubleshooting

 

 ⇒    Let's go!

 

Step 1 - Setting Up the Wireless Endpoint App

 

1.1 Downloading the App

 

Go to https://setup.byteblower.com/wirelessendpoints.html and scroll down to the relevant operating system for your device(s).

You will see a list of options to download the wireless endpoint app. These are either from an app store or direct downloads. 

 

App Store Downloads

• If you are using a mobile Android device → Click on 'Google Play'   → Click 'Install'          
• If you are using a mobile IOS device → Click on the 'App Store'     → Click 'Install'

  

Direct Downloads

  

• If you are using a Windows PC or a Mac → Click on     

• If you are using Linux → Follow the appropriate instructions in the Linux section (either Debian/Ubuntu or Fedora)

                                                            

        

          ⇒  Download the app to your device

 

1.2 Connect the App to the ByteBlower GUI

 

Once you have successfully downloaded the wireless endpoint app, you will see the meeting point software (see below). 

 

Here you have two choices ⇒

 

                                                1) Enter the IPv4 address of your ByteBlower server.

                                                2) Enter the name of your server if it has a fully qualified domain name (FQDN).

 

                         

 

A laptop with Windows 10 is the device under test (DUT) in this demonstration.