Physical connection with a Meeting point

In this knowledge-based article, we describe how to set up your first test using ByteBlower and ByteBlower 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, etc.

Before you can use a ByteBlower 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 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 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, 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.

Depending on your lab IP topology, it is possible to reach the management interface of the ByteBlower server from the ByteBlower Endpoints. By default, the 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 ByteBlower Endpoints will communicate with the Meeting Point over the WAN interface of the gateway and the management interface of the ByteBlower server. (orange line)

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 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.

Some cases prevent the use of a Meeting Point in different network segments. 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 and the upstream interface on the test network are unreachable for the ByteBlower 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.