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: https://setup.byteblower.com/software.html#Tools

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)	optional
--interface, -i	The name of the ByteBlower interface to capture on. Examples: trunk-1-1, nontrunk-1	required
--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!	required
--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

Examples:

• byteblower-remote-capture --server byteblower-1.excentis.com --interface nontrunk-1 --filter "ip host 10.0.0.1 and ip host 10.0.0.2" --out example1.pcap
• byteblower-remote-capture --server byteblower-1.excentis.com --interface trunk-1-1 --filter "ip host 10.0.0.2 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 byteblower-dev-1300-1.lab.byteblower.excentis.com -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.

So:

Bandwidth-delay product = RTT x BandWidth

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

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

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