Knowledge base : Download Area > ByteBlower > Tools

ByteBlower 2.x remote capture tool.

Sometimes it becomes handy if the user could capture on a ByteBlower port.  This is possible using the ByteBlower Tcl API.  But what if the Tcl API is not available or Tcl is not installed on the PC?

Hello byteblower-remote-capture!  byteblower-remote-capture is a command line tool which enables the user to start and stop captures on a ByteBlower server.  The result will be saved on the local PC. 

Note: Rx and Tx capture only supported on servers running version 2.9. Prior systems capture only RX

You can find the tool at following location:

The tool can be configured using command line arguments:

Argument name Description Notes
--server, -s The (remote) ByteBlower server to capture on.  
When this option is not given, localhost will be used. (handy for use on a ByteBlower server)
--interface, -i The name of the ByteBlower interface to capture on.
Examples: trunk-1-1, nontrunk-1
--out, -o The name of the file in which the results must be stored.  Only PCAP is supported for now.
Warning: If the given file name already exists, the file will be overwritten!
--filter, -f A well formed BPF capture filter to use.  This can be used to only select a portion of the incoming data optional
--snaplen Snaplen in bytes ( Note: Supported since ByteBlower server 2.9 ) optional


  • byteblower-remote-capture --server --interface nontrunk-1 --filter "ip host and ip host" --out example1.pcap
  • byteblower-remote-capture --server --interface trunk-1-1 --filter "ip host and udp dst 1000" --out example2.pcap

Known issue:

If you run the byteblower-remote-capture tool and you get following error:
wouter@wouter-VirtualBox ~/Downloads $ ./byteblower-remote-capture -s -i nontrunk-1 -o t.pcap
terminate called after throwing an instance of 'std::bad_cast'
  what():  std::bad_cast
Aborted (core dumped)

Please update your remote-capture-tool to the latest 2.9 version. Older versions of the capture-tool aren't compatible with the latest ByteBlower 2.9 Server

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

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


Bandwidth-delay product = RTT x BandWidth

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

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

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

We to help you!