Welcome to the Excentis support portal. The requested article is not yet available to you. Please login with your credentials. If you don't have login credentials yet, please click here or contact us at support@excentis.com
Knowledge base

A ByteBlower has 2 or more traffic interfaces on the Server. They are located on the back of the server and marked with a (Trunking) or a NT (non-trunking). When you receive your system, it is pre-configured.

This article explains how to configure your ByteBlower Server traffic interfaces. These are the addresses shown when logging into the server. They are updated about once every hour.

Connect to your ByteBlower over ssh or through a keyboard and screen. Login into the system until you have the root-prompt. Start the ByteBlower-configurator tool.

Continue the intro text ( by pressing enter ) to go to the main menu

Select the 2nd option to configure the Change the ByteBlower Server Configuration.

Select the 1ste option as we want to (re)configure the ports

Select the interface you want to configure or change

Select the type of interface
- Trunking : Behind this interface you have a ByteBlower switch connected
- Non-trunking: This interface is connected directly to your network or dut

In case of Trunking select the configuration behind this interface
If you have a NBASE-T add-on switch attached in daisy chain, select option 4
More advanced setups can be configured in the under Custom... option

Once your config is done select Back until the main menu

Save and Exit will store your configuration and reload ByteBlower.

Your new configuration is ready to use

This is a general troubleshooting guide. The focus is on large, mainly hardware problems where the ByteBlower stopped working. The goal of this guide is giving you a head-start. We are reachable at support.byteblower@excentis.com even in cause of doubt don’t hesitate to mail. 

ByteBlower server has no power. 


  • Power is plugged in but no indication lights are lit 

There are number of indication lights. Which one to find depends from model to model. You can search for the following: 

  • The main power LED on the front panel.
  • The LEDs on the power supply.
  • The Link Lights on the Management interfaces.
  • The link lights on the IPMI interface .


  • Most ByteBlower severs have a second power-supply, do try this one.
  • Remove power connection to the ByteBlower for 5 minutes and try to booting the system again. 
  • Check the power connection with another system or check the power outlet directly. 

Diagnosis & treatment: 

  • In case of a broken power supply we can ship you one directly.
  • When the power supply isn't the root-cause, then it's often necessary to replace the while motherboard.

ByteBlower server frozen in the BIOS screen 


  • While starting up, the ByteBlower server doesn’t get further than the SuperMicro Bios Screen 


  • If you have one, unplug the external USB security key and try booting the system again 
  • If this doesn't work or isn't feasible, we can help you best with the following information: 
    • The status-code at the left bottom 
    • The Model of the ByteBlower server (4100,3100,2100 or 1300) 
    • If possible, the license number. When needed we can look up this info. 

Diagnosis & treatment 

  • Depending on the error code, it’s possible hardware failure of the USB dongle. This dongle can be shipped directly to you. 
  • Hardware failure of the memory in the system. This tends to require replacing the unit. We’ll work with you for the best solution. 

ByteBlower server doesn’t find a hard-disk at startup 


  •  At start-up of the ByteBlower server, the BIOS complains that no hard-disk is installed. 


  • If you have one, remove the external USB security dongle and try booting again. 
  • Contact us with the ByteBlower server model and if license number 

Diagnosis & treatment 

  • We can replace a broken security dongle. This can be shipped directly you 
  • In case of a broken hard disk we can provide a new disk image or ship a freshly installed hard-disk.

ByteBlower process doesn’t start 


  • The ByteBlower server is reachable. You can ping the system. You are able to login 
  • The ByteBlower GUI or API can’t connect to the ByteBlower server 
    • The API throws a ServerUnreachable Exception 
    • The GUI can’t refresh the ByteBlower server, and can’t start tests on the system 


  • Logged in on the ByteBlower server, run the command byteblower-get-license. 
    This should print out the available license information 
  • Update the ByteBlower server to the latest version. 
  • Run the byteblower-support-tool. This tool collects the server logs and forwards them to ByteBlower support. 
    • This can be started from the ByteBlower GUI from the Server View. 
      Right click on the server icon and choose the Run Support Tool option 
    • When the ByteBlower server has internet access, you can also start if from the ByteBlower server itself.  

Diagnosis & treatment 

  • In case of a broken Security dongle, we’ll replace it and ship directly to you. 
  • Critical Software bugs are fixed with the highest priority. We’ll try to reproduce the error in our lab, but through the support-tool we can check crashes on your system. 

Not able to transmit traffic 


  • In the ByteBlower GUI the interfaces are crossed out 
  • Fails to start tests 


  • Refresh the ByteBlower server in the ByteBlower GUI 
  • Check whether the Link lights are lid at the ByteBlower server or on the ByteBlower switch. When easily possible do check both sides of the connection.  
  • Start a capture on the ByteBlower port. Do you receive any network traffic? 

Diagnosis & treatment 

When you can’t send traffic with the ByteBlower it’s important to diagnose first whether 

  • It’s a hardware issue.
    No lit Link lights on the ByteBlower server are very good indication.
  • or it’s a network issue elsewhere in the network. Is the modem online? Are other systems reachable?

Signal quality has a large impact on Wi-Fi performance. Since 2.11.0 of the ByteBlower Server, ByteBlower API and the Wireless Endpoint, it is now possible to map the RSSI, WiFi channel and the BSSID on your throughput!

Watch it here in action!


The downloads for windows/macOS/Linux are found at following location: https://setup.byteblower.com/wirelessendpoints.html .For Android and iOS you will find the apps in the app stores.

Changelog 2.11.4 (2019-09-18)

(Linux, macOS X and Windows only)

  • [Linux] Added support for Debian 10 and Ubuntu 20.04
  • [Windows] Fixing GUI initialization, resolving the attribute warning in the console.

Changelog 2.11.2 (2019-03-05)

  • [Windows] On some systems an unknown battery level was reported as 100%. This affected mostly Windows.
  • [Android] We now support from Android 7 till Android 11. To enable logging ESSID/BSSID/RSSI we had to drop Android 6 support.
  • [All] We’ve revised the FrameBlasting transmit approach. The new algorithm is better able to match the configured duration and rate, especially when the configured rate exceeds the available bandwidth. This occurs regularly in low bandwidth Wi-Fi environments, the excess bandwidth is dropped in these moments.
  • [macOS] Matching Apple guidelines we only use the essential capability set. Where possible we only use coarse Location to be able to monitor ESSID/BSSID.
  • [all] Fixed an issue where the device was marked as Booting Device when the device type contained a quote

Changelog 2.11.0 (2019-12-04)

  • Added support to collect the WiFi interface parameters over time: SSID/BSSID/Channel/RSSI/TxRate on supported devices.

You can find the detailed installation instructions in our How to: Install the Wireless Endpoint on your device.

This article explain shortly how implement NAT discovery with the ByteBlower API. We'll focus on the basic use-case and provide pointers for more in-depth info. Some experience with FrameBlasting using the ByteBlower API is assumed. Throughout the text we'll use Python but the same principles also apply to the Tcl version of our API.

NAT discovery in the ByteBlower GUI is enabled in the Port View. No such method is available in the API reference for the ByteBlower. Luckily implementing NAT discovery is very easy.

Before we start let's briefly make the setup clear. We'll use the terms upstream and downstream. In this text we'll use them as followed:

  • upstream is all traffic out of the LAN and into the public network. This traffic is never blocked but its addressed are modified when leaving the local network
  • downstream traffic is all traffic from the public network into the local one. It's the reverse direction of upstream. This traffic not modified but tends to be blocked when attempting to enter the LAN. Through NAT discovery we attempt to create a gate for the traffic to pass through.

A good starting point for NAT discovery is first sending traffic between two interfaces in the local network.This is the basic example shown on our GitHub page. You can do this by connecting both interfaces to the same modem or access Point.

Next is creating Upstream FrameBlasting UDP traffic.  This requires one ByteBlower interface in the private network and one outside. As mentioned above, although the addresses are translated, the upstream traffic isn't blocked, at the wan_port is will received with a different source IP address and different source UDP port. The easiest way is to count all this traffic is by leaving the BPF filter empty. Keep in mind this counts all traffic now, including test-runs from other users.

     trigger = wan_port.RxTriggerBasicAdd()

The RxTriggerBasic is a traffic that only counts traffic. The next step is capturing the raw frame-data, very similar to how you'd use Wireshark. This is possible with the ByteBlower API using a different kind of filter: RxCaptureBasic. The example code below shows how to add this filter. Unlike the previous trigger, this type needs to be started explicitly. This filter has a performance impact, but on most systems receiving multiple Mbits/s is no issue.

    captureRaw = wan_port.RxCaptureBasicAdd()

The final step in the NAT discovery is dissecting the received packets to learn the translated addresses. The ByteBlower API offers you the raw Ethernet frame as it was received. With an external library, SCAPY, you can convert these bytes something easier to inspect in Python.

from scapy.all import *

# Process the response: retrieve all packets.
for f in sniffed.FramesGet():
    data = bytearray(f.BufferGet())
    raw = Ether(data)
    if IP in raw and UDP in raw:
        discovered_ip = raw['IP'].getfieldval('src')
        discovered_udp_port = raw['UDP'].getfieldval('sport')
        print('Discovered IP: %s' % discovered_ip)
        print('Discovered UDP port: %s' % discovered_udp_port)

Finally the discovered public IP and UDP port now have a NAT-entry. You can use them as destination for downstream traffic. Without any upstream traffic, this typically remains saved for about 5 minutes.

More info, beyond the basic NAT use-case can be found in the following article:

This page contains the changelog for version 2.11 of the ByteBlower. How to update your ByteBlower server is explained in following article:

2.11.8 (2020-06-25)


  • Fixed an issue where the performance of a 3x00 server dropped significantly on v2.11.6
  • Adding timestamps to the standard output / error logs for the ByteBlower and MeetingPoint
  • DHCP protocol implements the elapsed time value. DHCP servers which rely on this field for high availability will now work as expected.

2.11.6 (2020-04-15)


  • Improve the transmit time accuracy of Frame Blasting flows.
  • The "Port.Create" method now works again on the ByteBlower 1200 series.
  • The ByteBlowerPort's result history counters can now be consumed by multiple ByteBlowerPort objects (each ByteBlowerPort contains its own copy of the result history.)
  • Configurator: IPv4 address validation failed when configuring static IP addresses on a management interface

2.11.4 (2020-02-20)


  • Fixed a bug which used unicast addresses in the DHCP requests. This could confuse some bridging devices which dropped the requests.


  • To help our support engineers, we now add the server and meetingpoint version to the logs.

2.11.2 (2020-02-11)

This release primarily focusses on bugfixes.

One of the fixes changes the default behaviour of the DHCP client running on a ByteBlower Port.  The DHCP Client used the broadcast DHCP-technique to obtain its IPv4 address.  As some customers noticed, some devices flagged this DHCP traffic as a broadcast storm when performing DHCP on multiple ByteBlower Ports.  This change in the ByteBlower DHCP client changes the default DHCP technique to the unicast technique, working around the limitation imposed by these devices.  The DHCP technique (broadcast/unicast) can be configured using the ByteBlower API.


  • Server: Added the possibility for the DHCP client to disable the BROADCAST bit in the DHCP flags.  The ByteBlowerPort will then use unicast packets when possible.
    Please note that this is now the default behaviour.  Using our API it is possible to revert to the older broadcast technique when needed.
  • Server: Added extra DHCP timing statistics (timestamps when the DHCP discover/offer/request/ack, DHCPv6 solicit, advertise, request, reply are sent or received)
  • MeetingPoint: Android 10 is now added to the list of supported operating systems.


  • Server: Fixed a crash when a ByteBlowerPort was being destroyed and the IGMP or MLD protocols needed to transmit messages.
  • Server: Fixes for IGMPv1 and IGMPv2 where an incorrect back-off interval was used.
  • Server: Fixed an issue where IGMPv1 did check the group address too much.
  • Configurator: Fixed a crash when the network configuration reached an inconsistent state.
  • MeetingPoint: Fixed a crash when the process got an interrupt signal

2.11.0 (2019-12-04)


  • The meetingpoint is aware of SSID, BSSID, RSSI, WiFi Channel and WiFi transmit rate on supported devices. To use these features you will also need to update the Wireless Endpoint on the device and the ByteBlower API installed  on your computer
  • The 24 port NBASE-T swtich for ByteBlower has been added to the byteblower-configurator. This makes it much easier tconfigure it.
  • Unsupported Operating Systems and devices can be registered at the MeetingPoint. This makes them available for test-runs. To make it clear that we've not yet tuned our code for the system we do add the 'unsupported' to the name of the device.


  • When requesting the result history on a Wireless Endpoint, all results were returned instead of only the new ones.  This resulted in growing histories (and thus memory usage) over time.
  • Improve TCP performance for flows that have a high number of packets in flight.
  • Fix packet duplication in Streams that have a small number of frames configured.


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 :

Using the Remote Capture Tool

This used to be the simplest way of capturing traffic on your port, until we brought the capture functionality to the GUI. You just need to download and execute the tool. It can be used on Windows, Mac and Linux. Follow this link ( https://setup.byteblower.com/software.html#Tools ) to download the tool.


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.


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.

Tk screenshot of Rx.Capture 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...


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

09:01 A.M., Work is done! 

Easy automation with the new JSON report. 


The ByteBlower GUI and CLT now have a new type of report: JSON. Just like CSV, this format is intended for machines rather than us humans. Actually, JSON is a huge improvement over CSV. 

As an example, check out the Python code below. 15 lines to check whether our network device did or did not lose traffic in your overnight test. 

Opening the JSON Report 

JSON files can be read in easily in many languages. Check out the Python example below.

def open_json_report(report_filename):
        Opens the report for further processing  
    with open(report_filename, "r") as f:
        return json.load(f)


Processing a testrun 

Once the report is loaded, you have access to same information as in the other reports. Labor-intensive questions can easily  beanswered in a short script.  

Does your project have many FrameBlasting flows?  
Do you want count how traffic much was lost in total?  
Did you check out the script below? 

    def count_received_traffic(report_data):
            Lost traffic is bad news. How much did we receive?
            Returns the value as percentage: 100 is nothing lost.
        total_expected = 0
        total_received = 0
        for fb_flow in report_data["frameBlastingFlows"]:
            for a_destination in fb_flow["destinations"]:
                total_expected += fb_flow["source"]["sent"]["packets"]
                total_received += a_destination["received"]["packets"]
        if total_expected == 0:
            return 0
            return 100. * total_received / total_expected

    Making work easier 

    But in the end our goal is to make life easier. Just that is possible with the JSON format. Rather than going over single test-run, why not let the computer do it? 

      def test_a_report(report_filename):
              Pass or Fail? Did this nights test succeed?
          report_data = open_json_report(report_filename)
          received = count_received_traffic(report_data)
          assert received < 99.9, "FAIL, too much traffic lost in " + report_filename
          print("PASS: We had good testrun")

      This article gives explains the status area at the top of the Wireless Endpoint. This is open area in the screenshot below. Most of the elements we'll discuss will familiar to those who have already used the Wireless Endpoint. Still some debug elements might be new.

      All devices use the same UI and nearly the same back-end code. The top area indicates the state of the app.  In the same order as on the UI, there are following statuses

      • Ready
      • Contacting
      • Registered
      • Armed
      • Running

      Ready state

      This is an uncommon state of the app. You can get here by pressing the red "Unregister" button. In this state the app is doesn't initiate network traffic, but is it's ready to start registering with the MeetingPoint. To go to this next state requires manual action, you need to click the blue 'Register' button. The app will then try to register at the MeetingPoint.

      This state is mostly used for debugging an Access Point. As we'll explain later, normally the App continuously contacts the MeetingPoint. During debugging, it can help to just stop traffic for a moment to understand what is going on.

      Contacting state

      In this state the app tries to contact it MeetingPoint. For as long as it fails to register, the Wireless Endpoint will remain in this state. The does keep trying once every second. An example of the contacting state is shown below.

      In good circumstances, the app moves on the next state (Registered) very quickly. When the App fails to do so, this can be due to following reasons:

      • The MeetingPoint isn't reachable. The client device itself might have no network, or the issue can be further in the network.
      • No MeetingPoint is running at the contacted to address.
        Not every ByteBlower has the MeetingPoint add-on. You can always ask for a demo at your sales contact or through support.byteblower@excentis.com .

      From this state you can go to the Ready stay by pressing the 'Unregister' button. The itself will automatically move to the Registered state as soon it successfully contacts its MeetingPoint,

      Registered state

      The is the idle state of Wireless Endpoint: it has registered with the MeetingPoint is and is waiting for order to start a test. Like the contacting state, the device will contact the MeetingPoint at regular intervals. This is shown in the little heartbeat.

      If this heartbeat fails several times in a row, the device returns to the contacting state.

      If the user requests to start a scenario, the device will go to the armed state. In this state the deivce ready to go but waits a small moment to allow other devices (other clients, but also the ByteBlower) to start.

      Armed state

      The armed state is an intermittent state right before starting the Wireless Endpoint test.

      Running state

      The running state is where the Wireless Endpoint executes its tests. In this state the Wireless Endpoint doesn't communicate with the MeetingPoint.

      At the end of its test, the Wireless Endpoint returns back to the registered state and searches contact again with its MeetingPoint.

      Aborting a test early is a manual action. You need to press the cancel button at the bottom of the Wireless Endpoint screen.

      ByteBlower API 2.11.6 (2020-04-15)


      You can download the latest version at https://setup.byteblower.com/software.html.


      • Added support for python 3.7 and Windows 64 bits.


      • The red 'evaluation license' message has been fixed. Due to a build error the (TCL) installers were created with an evaluation version of BitRock.

      ByteBlower API 2.11.4

      This API version was not released, this is a ByteBlower Server release only.

      ByteBlower API 2.11.2 (2020-02-11)


      You can download the latest version at https://setup.byteblower.com/software.html.


      • Added the possibility to configure the BROADCAST/UNICAST DHCP flag.  The ByteBlower Port will use this in the DHCP Process
      • Added extra DHCP timing statistics (timestamps when the DHCP discover/offer/request/ack, DHCPv6 solicit, advertise, request, reply are sent or received)


      • When Refresh was called on an OutOfSequence trigger, the result information was invalidated.  Accessing this information caused a crash of the API.
      • When the DHCPv6 Session Information was requested, the actual information was not requested on the server, thus needing an extra Refresh call.  This inconsistency with the other parts of the API is fixed.

      ByteBlower API 2.11.0 (2019-12-04)


      You can download the latest version at https://setup.byteblower.com/software.html.


      • Added support for the Wireless Endpoint to collect network information over time.


      • TCL: The signature for the deprecated method Pcap.Save on our Rx.Capture.Basic was wrong and resulted in an error.
      • TCL: The NetworkInfo object on a Wireless Endpoint can now be Refreshed.
      • Fixed an issue where it was impossible to fetch the Result History for a Frame configured on a Wireless Endpoint.


      • Our Python API (beta) is now available as a Python wheel instead of using a custom installer.  This gives us the possibility to release them later using PyPi

      Did you know you can ping a ByteBlower Port?  This requires no extra configuration on your end, the port will respond to Ping requests as soon as it has an IP address.

      Pinging a ByteBlower Port is especially helpful when debugging connectivity issues, this allows you to check where the ByteBlower Port is still reachable and from which link connectivity  is lost.

      In the examples below we use IPv4, this is of course also works in IPv6.

      ByteBlower GUI

      A ByteBlower Port is reachable with Ping as soon as the port has valid address in the Realtime View. This will becomes available very early in the configuration phase and remains so throughout the whole test run.

      To increase the time for debugging, you can enable a pause between scenario configuration and test-run. Right before the test traffic starts, you'll receive the pop-up below.

      When the issue is easily solved, you can still continue the test-run. From ByteBlower 2.11.4 on, the NAT entries will be kept alive until the test starts.


      This pop-up is shown by default. To disable you can use checkbox. It can later be enabled again from the Preferences.


      Finally to make debugging even easier It tends to help having a very minimal scenario: only enough to configure the ByteBlower Ports. To this end we suggest to disable NAT (Port View) and to use only TCP flows.

      ByteBlower API

      Pinging works just the same for the ByteBlower API: a ByteBlower Port pingable as soon as it has a proper IP address. As the example below shows, this the default behavior and requires no extra configuration.

      More examples can be found via https://api.byteblower.com/

      import byteblowerll.byteblower as byteblower
      api = byteblower.ByteBlower.InstanceGet()
      bb_server = api.ServerAdd('')
      bb_port = bb_server.PortCreate('nontrunk-1')
      l2 = bb_port.Layer2EthIISet()
      l3 = bb_port.Layer3IPv4Set()
      dhcp = l3.ProtocolDhcpGet()
      print('ByteBlower Port is pingable on %s' % (l3.IpGet()))

      By default the XRA-31 system will use DHCP to get its management IP. In some lab-environments this is not wanted. This page explains you how you can configure a fixed IP on the management interface.

      All this configuration is done by using the Wicd tool on the system.

      Start the Wicd graphical UI from either the main menu

      or via the network configuration icon on the bottom right on your screen

      The main status and configuration window will open.
      Click on "Properties" to change the configuration of the wired connection:

      Select "Use Static IPs"
      Configure the IPv4 address, netmask and gateway.

      Configure DNS settings:

      • DNS domain: your domain name
      • (optional) Search domain: domains to search in when looking for a host name
      • DNS server: One or more DNS servers

      Press "OK" to save the changes.

      Disconnect + re-connect to apply the changes immediately.
      Please note that existing network connections will be closed.

      The connection will be established now with the new configuration:

      Known issue

      Up to XRA-31 version 3.1, there is a bug in Wicd Network Manager that causes connection problems for a static IP address (leading to "Not connected" status after clicking "Connect").

      As a temporary workaround, please configure the static IP address settings as detailed above and perform the following additional steps after each system reboot.

      1. Close the Wicd Network Manager. Right click on the network configuration icon on the bottom right on your screen and click Quit.
      2. From the main menu, open a command line (LXTerminal) and execute   wicd-cli --wired -c
      3. Run the command  ip address show  to verify the network settings have been successfully applied.

      A permanent patch will be included in XRA-31 version 4.0 and higher to make these steps unnecessary.

      There are three methods to obtain the management IP address of an XRA-31 system: Either using the graphical UI of Wicd, using wicd-cli or using the ip command line tool.

      Are you looking to configure a fixed IP address or change the network configuration? Please take a look at this page.

      Log in to you system

      Using screen and keyboard, you can log in at the graphical desktop.

      See also How to: Log in at the XRA-31 system for more details.

      Check management IP address

      Using the Wicd graphical UI

      At the bottom right on the screen, you can find the network connections icon.
      When hovering, the current connection IP address is shown.

      For more details, you can click on the icon.
      This will pop up the Wicd Network Manager.

      Using the Wicd command line

      From the main menu, open a command line (LXTerminal)

      Use the ip command to obtain the current IPv4 and IPv6 addresses

      wicd-cli --status

      You can find all assigned IP addresses in the output

      Using the IP command line

      From the main menu, open a command line (LXTerminal)

      Use the ip command to obtain the current IPv4 and IPv6 addresses

      ip address show

      You can find all assigned IP addresses in the output

      If you have a big project to run but one of the devices under test isn't connected or will fail to initialize (DHCP,ARP,etc.. ) then we have an option to let the test continue. With this option you will not be forced to either fix the device nor edit your project.

      You can find this option "Ignore initialization errors" in the Window->preferences under the Scenario tab.

      Once this action is activated ByteBlower will disable each flow that fails to initialize. Your Scenario will then run with all the flows that are fully functional. The report will contain logs explaining which flows failed during the initialization phase.

      On new devices you might encounter something like the screenshot below: your new Wireless Endpoint is not supported yet.

      What can you do with those devices?

      With caution, almost everything; the disclaimer is only text.

      The disclaimer means we didn't have time to verify the Wireless Endpoint for this new OS. We didn't verify the functionality and haven't yet verified the performance. Since most OS versions are backwards compatible, there's a good chance that everything works just fine.

      Can I do something to fix the disclaimer?

      Updating to the last MeetingPoint and Wireless Endpoint helps.

      Which devices are supported depends on software running the on the ByteBlower system and on the device itself. Your new phone might already be supported by a newly released update.

      Should you notify us?

      Yes please, especially when the disclaimer remains after updating. Sending a mail to support.byteblower@excentis.com or contacting your account manager is sufficient.

      Reaching out helps us determining priorities. And truth to be told, on occasion we might have missed the release.

      What devices are supported?

      Follow the link below

      Latency is the time a packet takes to travel from source to destination. Hence, seeing negative latency values in the report is always a surprise, it's as if packets arrived even before they were sent! The figure below is one such an example. This article explains how this is possible and what actions can be taken to prevent it.

      Intro: Measuring latency with ByteBlower

      This section explains how ByteBlower performs the latency measurement. This helps to understand the cause of negative latency values.

      The picture below shows two FrameBlasting flows. The one at the top is a regular flow with packets going from PORT_1 to PORT_2, the one at the bottom is a latency flow.

      Contrary to the regular flow, the ByteBlower server will modify traffic for the latency flow! Part of the payload content is replaced with a realtime timestamp. This value represents the moment the packet leaves the ByteBlower, so the current local time at the source ByteBlower port.

      The receiving ByteBlower port only needs to inspect the packet and compare the timestamp in the packet to its current time. The difference (local time at the destination/receiver ByteBlower port minus the timestamp value in the packet) represents how long the packet was in transit, i.e. the latency of the packet.

      The advantage of this approach is that the only communication between PORT_1 and PORT_2 is through the test traffic itself, no other protocols are needed. The ports don't have to be on the same interface, same server or even in the same lab.

      The above approach is used both by ByteBlower servers and Wireless Endpoints. All information is available in the traffic itself. This makes it very flexible to measure the latency between ports docked to the same server, between a server and Wireless Endpoint or between different ByteBlower servers.

      Since we rely on local clocks on the ports to generate and compare the timestamps, and since the timestamps are carried in the packet payload, there are two major reasons for problems with measuring latency:

      • The sending and receiving side measure the local time differently (clocks not synchronized)
      • The packets have been corrupted

      We'll have a look at both problems in more detail.

      Synchronized clocks

      In the section above we've explained how the transmitting side adds a timestamp to the frames The receiving end compares this value to its local time. We expect to measure a difference between the value in the frame and the time at the receiving end, this is how long the packet was under way. Hence the clocks need to be synchronized, otherwise we're just measuring the difference in clocks rather than the packet transit time. Clock differences where the receiver port's clock is trailing the sender port's clock is the major cause of negative latency values!

      Within the same ByteBlower

      Not a problem here, since source and destination port use the same clock!

      If the setup allows you to, using a single ByteBlower server is the preferred way to measure latency!

      ByteBlower to ByteBlower

      As mentioned above both ByteBlowers needs to be time-synced. The article below offers more info on how to configure this:


      Note that for latency measures, it is important to keep the clocks of the different ByteBlower servers in sync (using NTP or PTP), since otherwise they can drift away from each other. If you only sync them once, the first measurement can give good latency results, but repeating that same test a couple of months later could provide wrong results.

      Wireless Endpoint to ByteBlower

      Measuring latency using a Wireless Endpoint is a challenge. Contrary to regular ByteBlower traffic, here it is not a ByteBlower server port that sends or receives traffic, but it's the Wireless Endpoint (your phone e.g.). Key question: which timestamp to use?

      When registering with a Meeting Point, the Wireless Endpoint tries and synchronizes its local time to the time of the Meeting Point (the latter taking the time of the ByteBlower server it is connected to). Important to note that this time synchronization is not as good as two ByteBlower servers using the same NTP server! Whereas the ByteBlower servers can use a (typically stable) management network to synchronize, the Wireless Endpoint uses the same connection as the traffic itself.

      Furthermore, there is no update of time synchronization during a test, so a Wireless Endpoint moving from one AP to another AP during a test could experience a severe time drift without its clock being updated.

      Bottom line: latency measures for a Wireless Endpoint are provided as a best effort service. Be careful when interpreting these results!

      Packet corruption

      Since the timestamps are carried in the packet payload, there is another reason why latency measurements can go wrong: corrupted packets.

      Most likely to happen in case of a corrupted packet is:

      1. packet is dropped due to CRC failure
      2. CRC is valid, but timestamp was altered, packet is counted as invalid (no latency) because the calculated time offset is too large (>1 minute)
      3. CRC is valid, but timestamp was altered, latency shows unexpected peaks (multiple seconds, but less than 1 minute)

      Below is an example of such a latency measurement (simulated through an impairment node).

      Next to the obvious spikes in latency, you can have a look at the packet loss measurements to know whether or not the negative latency was caused by packet corruption.

      To solve these problems, you will need to solve the packet corruption itself (network or device).

      Another case?

      If your tests matches none of the above cases,then it's a good idea to contact us at support.byteblower@excentis.com . We'll help you further from there.

      The Wireless Endpoint is available for several operating systems. Not all of them expose the same Wi-Fi statics. The table below lists which value is available on the system.

      Operating System SSID BSSID RSSI Channel number Tx Rate
      Android 10 (*) Available (***) Available (***) Available Available Available
      Android 9 (*) Available Available Available Available Available
      Android 8 (*) Available Available Available Available Available
      Android 7 and lower (*) Available Available Available Available Available
      Windows Available Available Available Available Available
      iOS Available Available Not available Not available Not available
      macOS(*) Available Available Available Available Available
      Linux (**) Available Available Available Available Available

      (*) Enable location permission

      (**) Ubuntu 18.04

      (***) Enable Location

      Unavailable statistics

      When a value is not available we offer following default values:

      • SSID: empty string
      • BSSID: 00:00:00:00:00:00
      • RSSI: -1
      • Channel number: -1
      • Tx Rate: -1


      New Features:

      • Support for MacOS Catalina
      • Cheat mode is no longer required to open config files with eSafe TLVs


        • Fixed an issue where negative MIB value numbers were converted to their 2-complement positive number
        • Fixed erroneous constraint check for Guaranteed Grant Rate TLV


        New Features:

        •  added Low Latency DOCSIS support:
          • 70/71: new Aggregate Service Flow Subencodings, including
          • [70/71].42: Low Latency Aggregate Service Flow Encodings
          • 24: new Subencodings for Proactive Grant Service
          • [24/25].40: new Subencodings for AQM (including ImmediateAQM)


        • Fixed issue where Activity Detection parameters could not be added in Energy Management DLS mode



        • Removed frequency limitation checks that are not valid anymore for DOCSIS 3.1


        New Features:

        • new TLVs added:
          • 83: DTP Mode Configuration
          • 84: Diplexer Band Edge
          • 74.4: Energy Management DOCSIS Light Sleep Mode Encodings
          • 41: added channel type subtlvs for 3.1 (4.1.3 and 4.2.5)
          • Added generics for L2VPN encoding and DUT filtering
        • tooltip improvements
        • filename is displayed in titlebar


        • Encoding of CVC Chain is now a degenerate PKCS#7 structure
        • Refresh button caused saved check to fail
        • Extended CMTS MIC calculation is corrected
        • Service Flow traffic rates were limited to 2Gbps
        • wrong TLV number was displayed in case of parsing error
        • CMIM classifier was not recognized as valid classifier


        New Features:

        • new TLVs added (includes all 3.1 TLVs!):
          • 70: Upstream Aggregate Service Flow
          • 71: Downstream Aggregate Service Flow
          • 72: Metro Ethernet Service Profile
          • 73: Network Timing Profile
          • 76: CM Upstream AQM Disable
          • 79: UNI Control Encoding
          • 81: Manufacturer CVC Chain
          • 82: Co-signer CVC Chain
        • new service flow SubTLVs added:
          • 36: Aggregate Service Flow reference
          • 37: MESP reference
          • 39: Service Flow to IATC Profile Name Reference
          • 40: AQM Encodings
          • 41: Data Rate Unit Setting
        • added eSTB encodings
        • added cheat mode in CLI
        • updated installer with improved OSx JRE detection


        • Fixed adding Generic (Sub)TLV with high TLV numbers
        • Fixed Energy Management TLV location parsing issue
        • Fixed warning when adding TCP/UDP classifiers in an IPv6 classifier

        This article is intended for debugging a ByteBlower 1300. Only when the ByteBlower debug log contains the line below should you go through the steps below, preferably after contacting the support.byteblower@excentis.com.

         > Stopped ByteBlower due to: No cores found on NUMA node 0

        Unfortunately the NUMA configuration can't be checked over TeamViewer, it needs to be done on the premises. The steps list how to get to these settings. below. Most will probably look familiar. Depending on the result we might need to RMA the system, contacting support will help you further.

        Step 1. Enter the BIOS menu
        Attach a keyboard and screen to the ByteBlower and reboot the system. You'll need to press DEL when the SUPERMICRO logo shows up.

        Step 2 Navigate to the ACPI settings.
        In the BIOS we're interested in the ACPI Configuration. This setting is found in the Advanced menu. As you can see below, the option is third to last.

        Step 3 Verify NUMA Support.
        In the ACPI Configuration you'll find the NUMA Support option. This option should be Enabled.

        Press "Esc" to go back to the main menu

        And then select Exit -> Save and Exit. (Also do this even if the NUMA was enabled: This step will reprogram the BIOS !!!)

        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.

        2.10.8 (2019-08-29)


        • Add support for ByteBlower 3200 Gen2

        2.10.6 (2019-08-14)


        • Unintended traffic on the management interface TCP port 9002 could cause the ByteBlower daemon to stop. We've made it robust against these packets
        • MLD Listening Reports could in some rare cases cause the ByteBlower to stop. This is resolved.
        • Some tools couldn't handle the lacking of a dongle. Now those tools report a correct error when the dongle is missing.

        2.10.4 (2019-08-08)

        Fixes - Configurator

        • The IPv4 gateway was already optional in the management interface configuration, due to an input validation bug, it seemed required
        • When adding a route, an error was thrown when looking for the correct interface to add the route on.

        Fixes - ByteBlower

        • ByteBlower is now able to correctly handle fragmented IPv4 packets
        • Improved TCP performance when sending from 10G to 1G and the switch has small buffer sizes and latency is high

        Fixes - Meetingpoint

        • New networkinterface on wireless devices was created over time. Info is now updated instead of creating a new interface

        2.10.2 (2019-07-04)


        • Server: TCP: Fix long performance drops that sometimes occurred in situations with high packet loss.
        • MeetingPoint: Add iOS 13 as supported device
        • Configurator: When the network configuration is corrupt, throw a more adequate error with more information instead of an obscure out_of_range.
        • Configurator: When a custom port configuration is used, the interface was not marked as trunking
        • Configurator: Fixed an issue when the ByteBlower interfaces could not be configured after a fresh install.

        2.10.0 (2019-04-24)



        • Adding support for NBase-T (2.5Gbit and 5GBit) interfaces.
        • Added an option to restart the TCP on a wireless endpoint. A TCP session will automatically restart if its been dropped by a bad Wi-Fi connection.
        • Multiclient TCP API [Beta]


        • The server could crash when the FrameTag (Time/Sequence) was requested before the frame bytes were set.
        • Creating a frameblasting flow with ARP packets could cause the server to stop. This is fixed.
        • Restored our /legal directory which was lost in a previous release.

        The Byteblower GUI generates several types of reports. The HTML and PDF reports from the ByteBlower GUI are limited by size of the test-run. On this page you'll a guideline to how large your tests can grow. This is a limitation by the graphing of the results over time.

        For ByteBlower GUI v2.10 the limit of the graphical report is about 12 000 Graphing-Hr. This value is counted as follows:

        1. Count how long your test tests.
        2. Each type of graph in the report has a different cost. For each graph in the report you'll need to multiply with right value using the table below.
          Graphing type Multiplier Lines
          FrameBlasting 1
          Latency 5 Minimum, Average, Maximum and Jitter twice
          TCP 5 Goodput, TCP throughput, round-trip time, transmit window, retransmissions
          Out of Sequence 1
        3. Multiply the cost with the duration. The total should be less than 12000.

        An example

        For the example we use actions of of the below config. This scenario has 4 flows and 3 different types.

        • Duration of the test run:
          This test runs for 5 days. This can be read in the Duration colunmn next to the name of the scenario.
        • Calculate the multiplier:
          This test run has a multiplier of 10 + 1 + 6 = 17
          • 2 TCP flows: 2 X 5 = 10.
          • 1 FrameBlasting flow: 1 X 1 = 1
          • 1 FrameBlasting + Latency flow: 1 X (1 + 5) = 6
        • Multiply
          17 X 5days = 17 X 5 x 24 Hr = 2040 Graph-hr   
          2040 Graph-hr < 12000 Graph hr.
          This test-run is ok.

        In total this test is below the reporting limit. You can thus generate HTML reports out of it.

        Creating larger tests?

        The above guideline is only the HTML and PDF reports. For larger testruns you've got following options:

        1. Split up the test-run into smaller scenarios.
        2. Only generate the csv reports using the ByteBlower CLT.
        3. Use the ByteBlower API.

        Using Acrobat reader XI, you can get an error message saying there is an error displaying a page.
        Installing Acrobat reader DC solves this.
        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 describes the behavior of the NATDiscovery in the ByteBlower GUI. The text intends to answer technical questions. For a step-by-step guide on how to use NATDiscovery we have an article in the examples section.

        The NAT discovery is enabled in the port view. We'll assume that the reader is already somewhat familiar with how a NAT operates. The focus in this article is solely on using such ByteBlower ports for FrameBlasting.

        Problem description

        Any ByteBlower Port can be used as source or destination of a FrameBlasting flow. As we'll see further, this makes an important difference. For the clarity we'll call traffic out of the NAT the upstream direction. The ByteBlower Port with the NAT config is then the source of the flow. The reverse direction, traffic streaming into the NAT is called the downstream direction. In this second case, the NAT config is found on the destination. An example is found in the figure below.

        In the figure above, both NAT_CPE_1 and NAT_CPE_2 are inside the LAN. They are configured with a valid IPv4 address and can reach each-other using that address. Yet these addresses won't be known outside of their LAN. A router or modem provides the connection with the wider network. It will modify all traffic into and out of the LAN.

        What part of the packets do change? Only where the frames are addressed to. This keeps the devices inside the LAN private.  A very common situation is that that all upstream traffic shares the same IPv4 source address. When needed the Layer 4 port numbers (e.g. UDP) will also change. This packet modification is called a Network Address Translation or NAT. One such NAT mapping is made for each IPV4 address and UDP port number being sent upstream. The devices inside the NAT, they themselves don't know to which values their packets will be translated to.

        This upstream traffic is shown in the figure below. CPE1 and CPE2 both sent traffic upstream (green arrows). The addresses of this traffic are translated. A node in the Wide Area Network (WAN) can't tell anymore whether the lighter shade was from CPE1 or CPE2, only the router in the middle is able to.

        Downstream traffic is more tricky. The IPv4 addresses of the devices inside the LAN are kept secret, you can't thus reach them with these. In fact you can only reach the devices using an already existing NAT mapping. This mapping is only created from upstream traffic. In summary, if you want to sent traffic downstream, the CPE first needs to contact you upstream.

        This translation has an impact on your ByteBlower. Default the ByteBlower uses both source and destination addresses to recognize to whom the traffic belongs. Aftertranslation these values will have changed. The addresses thus need to be resolved, this will be described in the upstream discovery section. In addition for downstream traffic the NAT mapping needs to be initialized with upstream data first.

        Upstream Discovery

        As presented above, the addresses of  packets from the CPE to the WAN are translated by the NAT. The upstream discovery determines the values they are being translated to. This discovery is done for FrameBlasting flows with a source that has the NAT config enabled. It's performed while setting up the test.

        Determining the translation is straightforward, the ByteBlower GUI takes the steps below:
        1. Create a frame with an easy to recognize payload. Base the addresses on the data you'd wish to sent.
        2. Send the frame through the NAT.
        3. At the destination listen for the traffic from the previous step.
        4. Discover the translated addresses from the received traffic.
        This forward discovery is done for all addresses. When multiple flows use the same frames and the same ports then the results of the forward discovery are reused. Most NAT devices will retain this translation for at least 2 minutes.

        Below we'll briefly describe the steps in this discovery. This will help troubleshooting potential issues.

        Step 1: Frame creation

        A new frame is created based on the original frame. We'll call this the NAT Discovery Frame. It has the same values for following fields:
        • MAC addresses
        • VLAN headers when applicable
        • IPv4 addresses taken from the ByteBlower Port config
        • OSI Layer 4 type. For most configurations this will be UDP.
        • Layer 4 port numbers.
        The frame differs solely in the payload. This has been replaced with a small textual description and a unique token. It stays small: the frame is about 100 bytes large including Ethernet overhead.

        Step 2: Upstream traffic

        The probing frame is sent out from the ByteBlower port with the NAT config. The frame rate is low: about 10 packets a second or at about 8 kbit/s. Traffic is generated for at most 20 second, but as we'll see next, most of the time the NATDiscovery finishes earlier.

        Step 3 and 4: Receiving the frame

        A RawBasicCapture captures all traffic. A BPF filter based on the IPv4 and Layer 3 (mostly UDP) destination addresses of the frame limits the number of captured packets. Each received packet is compared to the expected payload from step 1. This comparison is done eagerly: as soon as new frames arrive.

        The source IPv4 address and the source Layer 4 port of the received frame are retained. We call these the public addresses. These values are used to count the traffic during the test-run.

        Downstream Discovery

        In this section we'll explain the downstream discovery. This algorithm is used when the destination of the FrameBlasting flow is behind a NAT.

        As we mentioned in the introduction, downstream traffic through a NAT requires first upstream data. These first packets create the NAT mapping. Only after this step, downstream traffic is possible. This is reflected in the steps for the downstream discovery:
        1. Use the upstream discovery to create the NAT mapping en  determine its values
        2. Adapt the UDP frame to these new settings: The IPv4 and UDP destination addresses take the values of the forward learning

        Step 1 Do upstream discovery

        Upstream discovery is started from the destination ByteBlower port, this is the ByteBlower port inside the NAT. This can be confusing: even though this port is configured to receive the traffic of the flow, it will transmit during initialization.

        The public addresses are used in the second step.

        Step 2: Adapt the Frames

        The configured ByteBlower frames are modified to the learned NAT mapping. The public IPV4 address and learned Layer 4 port are used as the destination of the frame.
        This article explains the situation where a server is asked to generate more traffic than available by its hardware. There are a number of ways this can happen, but the response is always the same. We'll first explain the reason and next delve into the causes and give hints to avoid this error in the future.

        Exceeding the hardware limit is only possible with FrameBlasting. At the start of such a flow, the Byteblower Server attempts to reserve the requested bandwidth. If this step fails, the flow isn't started. The other flows on the system aren't affected and the rest of the test continues.

        Such an fault is list in the Warning section of the test-report. No througput results are available, these have the value value n/a. Of both there's an example below.

        To avoid this warning in future runs, you can take following actions.
        1. When it's caused in a single scenario, you'll need to either

          • Lower the bandwidth of the conflicting flow. The total show be remain below the hardware interface limit.

          • When caused by multiple conflicting flows. Have them spread out so they don't run simultaneously any more.

        2. When sharing the system, you'll need to coordinate to avoid exceeding the interface limit.

        This API release includes the beta release of the Python code. You find an introduction to the Python API in this howto.

        The full change-log is found at the bottom of this article.


        You can download this version of the TCL API from these locations:

        • [[SecureDownload:ByteBlower/API/Tcl/2.7.0/ByteBlower-API-Tcl-windows-x86-installer.exe:Windows TCL installer]]
        • [[SecureDownload:ByteBlower/API/Tcl/2.7.0/ByteBlower-API-Tcl-linux-x86-installer.run:Linux 32bit TCL installer]]
        • [[SecureDownload:ByteBlower/API/Tcl/2.7.0/ByteBlower-API-Tcl-linux-x86_64-installer.run:Linux 64bit TCL installer]]
        • [[SecureDownload:ByteBlower/API/Tcl/2.7.0/ByteBlower-API-Tcl-osx-installer.dmg:Mac OS X TCL installer]]
        • [[SecureDownload:ByteBlower/API/Tcl/2.7.0/ByteBlower-API-Tcl-universal.zip:Zip including packages for all platforms for Tcl.]]

        You can download this version of the Python API from these locations:

        • [[SecureDownload:ByteBlower/API/Python/2.7.0/ByteBlower-API-Python-windows-x86-installer.exe:Windows Python installer]]
        • [[SecureDownload:ByteBlower/API/Python/2.7.0/ByteBlower-API-Python-linux-x86-installer.run:Linux 32bit Python installer]]
        • [[SecureDownload:ByteBlower/API/Python/2.7.0/ByteBlower-API-Python-linux-x86_64-installer.run:Linux 64bit Python installer]]
        • [[SecureDownload:ByteBlower/API/Python/2.7.0/ByteBlower-API-Python-osx-installer.dmg:Mac OS X Python installer]]


        The HTML reference documentation for both the Python and Tcl API

        • [[SecureDownload:ByteBlower/API/Tcl/2.7.0/documentation-html.zip:Reference documentation]]

        Changelog 2.7.0 (2017-08-29)


        • Introduction of the Layer4.Tcp.Tunnel. [br] This feature allows one to tunnel TCP traffic through a ByteBlower port. It makes remote debugging much more easy.
          • ByteBlowerPort::Tunnel.Tcp.Add creates a Layer4.Tcp.Tunnel.
        • Made the Python API publicly available.
        • The new call ByteBlowerPort::Interface.Speed.Get returns the bitrate of the parent interface.
        • Minimized communication overhead when destroying Layer5.Http.Client

        If you run into trouble with the ByteBlower GUI you can contact our support ( support.byteblower@excentis.com ). It is best to add as much info to so we can asses directly what the problem is and help you further. The relevant info is

        • ByteBlower project
        • HTML-Report ( if you have one )
        • GUI logs

        The last one can be found through following menu

        Clicking on SystemInfo will open a text-editor with the full log. Just add this file to your support-request and send it to us

        Most popular articles 
        Newest articles 

        We to help you!