bwctl(1)

📦 version 1.5.4, in ubuntu jammy

💖 NAME 💖

bwctl, bwping, bwtraceroute — the client application you use to request throughput, traceroute, ping and owamp tests.

(Yes bestie, this is the bwctl(1) page, straight out of the General Commands Manual. Buckle up. 🫶)

✨ SYNOPSIS ✨

bwctl [options] -c recvhost -s sendhost
bwctl [options] -c recvhost
bwctl [options] -s sendhost
bwping [options] -c recvhost -s sendhost
bwping [options] -c recvhost
bwping [options] -s sendhost
bwtraceroute [options] -c recvhost -s sendhost
bwtraceroute [options] -c recvhost
bwtraceroute [options] -s sendhost

🌈 DESCRIPTION 🌈

So bwctl is a command line client application, and its whole thing is initiating throughput tests. That's it. That's the job. 👑

This version of bwctl can kick off Iperf, Nuttcp, Iperf3, Ping, Traceroute, Tracepath and Owamp tests. A whole roster. Iconic behavior.

Here's the tea on how it actually works: bwctl contacts a bwctld daemon on both the receiving host and the sending host. bwctld is the one that manages and schedules the resources of the host it runs on. And if you only specify one of the receiving host or the sending host, bwctl just assumes the local host is the other endpoint. bwctl will try to contact a local bwctld if it can. But if there's no local bwctld running, bwctl assumes the local host doesn't require policy controls and will execute the bwctld functionality needed to run the test directly. DIY era. 💅

Now, in cases where bwctl is directly running the test on the host, there are several configuration options that are shared with bwctld. Those configuration options can be set using the bwctlrc(5) configuration file, in a way that's very similar to how they're specified in the bwctld.conf(5) file. Sibling energy fr.

The bwctl, bwping and bwtraceroute clients are used to request the desired type of throughput, latency or traceroute test. And not just what — they also request when the test is wanted. bwctld on each endpoint responds with either a tentative reservation or a test denied message. Once bwctl is able to get a matching reservation from both bwctld processes (one for each host involved in the test), it confirms the reservation. Then the bwctld processes run the test and return the results. The results get returned to the client from both sides of the test, from the respective bwctld processes. And on top of that, the bwctld processes share the results from their respective side of the test with each other. Collaborative queens. 🎀

BWCTL (that's bwctl and bwctld) is used to enable non-specific network measurement tests to hosts without having to give full user accounts on the given systems. Users want the ability to run throughput tests to determine the achievable or available bandwidth between a pair of hosts. And it's often useful to test to multiple points along a network path to determine the network characteristics along that path. Typically, users who want to do this path decomposition have to directly contact the network/system administrators who control the hosts along the path. The administrator then needs to either run half of the test for the user or give them a user account on the host. Also, network paths of interest are typically controlled by multiple administrators. These hurdles have made this kind of testing difficult in practice. 💀

BWCTL was designed to help with this problem. It allows an administrator to configure a given host as an Iperf, Iperf3, Nuttcp, or Owamp endpoint. That endpoint can be a packet sender (e.g. Iperf client) or a packet receiver (e.g. Iperf server). It can be shared by multiple users without any concern that those users will interfere with each other. Specific policy limits can be applied to specific users, and individual tests are scheduled so they won't interfere with each other. And as a bonus, full user accounts are not required for the users running the tests. Slay. ✨

BWCTL also lets the administrator classify incoming connections based upon a user name and AES key combination, or alternatively, based upon an IP/netmask. Once the connection is classified, the bwctld can determine the exact type and intensities of throughput tests that will be allowed. More info on the policy controls lives in the bwctld(8) man page. Go read it, iykyk.

And finally, BWCTL makes use of a distributed scheduling algorithm. Each host maintains a schedule independently. As a client requests a test, the two endpoints are contacted and each bwctld server responds with the first available open schedule slot. This enables on-demand tests to co-exist with regularly scheduled tests, since regularly scheduled tests are implemented by having the client request tests on regular intervals. Different priorities can be implemented using the event_horizon configuration directive to bwctld. (By allowing clients that implement regularly scheduled tests to reserve their time slots further into the future.) Main character scheduling algorithm, honestly. 👑

🦋 ARGUMENTS 🦋

🔐 Connection/Authentication Arguments:

  • -4, --ipv4 — forces bwctl to use IPv4 addresses only.
    • Default: Unspecified (IPv6 is preferred).
  • -6, --ipv6 — forces bwctl to use IPv6 addresses only.
    • Default: Unspecified (IPv6 is preferred).
  • -A authmethod — authmethod is used to specify the authentication method the bwctl client is willing to use for communication with the bwctld on the sendhost and recvhost. The authentication options of bwctl are intended to be extensible. The communication from the bwctl client to each bwctld server may take different options for different types of authentication. If the authmethod option is specified for either the -s or the -c argument, it overrides the authmethod specified with the -A option for communication with that particular host. (Therefore, the -A argument is really only useful if the same authentication can be used with both hosts.)

Allowing different authentication methods for each connection should allow a client to use different authentication methods with different servers, which should in turn allow cross-domain tests to occur more easily.

The format for authmethod is:

authmode [authscheme schemeopts]
  • authmode — specifies the authentication mode the client is willing to speak with a server. It must be set as a character string with any or all of the characters "AEO". The modes are:
    • A — [A]uthenticated. This mode encrypts the control connection.
    • E — [E]ncrypted. This mode encrypts the control connection. If the test supports encryption, this mode will additionally encrypt the test stream. (Encryption of the test stream is not currently supported, so this mode is currently identical to authenticated.)
    • O — [O]pen. No encryption of any kind is done.

The client can specify all the modes with which it is willing to communicate. The most strict mode that both the server and the client are willing to use will be selected.

  • Default: "AEO"
  • authscheme schemeopts — authscheme indicates the authentication scheme that should be used to achieve the authenticated or encrypted modes. schemeopts are a list of arguments specific to each particular authentication scheme. Supported authscheme values follow (listed with the schemeopts each scheme requires):
    • AESKEY userid [keyfile] — this is the initial "simple" shared secret (AES key) model. userid is required to identify which shared secret the server and client should use. keyfile optionally specifies a file to retrieve the AES key from. If keyfile is not specified, the user will be prompted for a passphrase. keyfile can be generated using the aespasswd(1) application.
    • Default: Unauthenticated

authscheme and schemeopts are only needed if authenticated communication (A or E modes of authmode) is wanted with sendhost and recvhost.

  • -B, --local_address srcaddr — bind the local address of the client socket to srcaddr. srcaddr can be specified using a DNS name or using standard textual notations for the IP addresses.
    • Default: Unspecified (wild-card address selection).
  • -c, --receiver recvhost[:port] [authmethod] — specifies the host that will run the Iperf, Iperf3 or Nuttcp server. The :port suffix is optional and is only needed if bwctld is being run on a non-default port number. If an IPv6 address is being specified, note that the accepted format contains the recvhost portion of the specification in square brackets as: [fe80::fe9f:62d8]:4823. This ensures the port number is distinct from the address specification, and is not needed if the :port suffix is not being used.

At least one of the -c or -s options must be specified. If one of them is not specified, it is assumed to be the local host.

authmethod is a specifically ordered list of keywords that is only needed if authenticated communication is wanted with recvhost. These keywords are used to describe the type of communication and authentication that should be used to contact the recvhost. If recvhost and sendhost share the same authentication methods and identities, it is possible to specify the authmethod for both recvhost and sendhost using the -A argument. An authmethod specified with the -c option will override an authmethod specified with the -A argument for communication with the recvhost.

The format for authmethod and a description of the currently available authentication methods are described with the -A argument.

  • -s, --sender sendhost[:port] [authmethod] — specifies the host that will run the Iperf, Iperf3 or Nuttcp client. The :port suffix is optional and is only needed if bwctld is being run on a non-default port number. If an IPv6 address is being specified, note that the accepted format contains the sendhost portion of the specification in square brackets as: [fe80::fe9f:62d8]:4823. This ensures the port number is distinct from the address specification, and is not needed if the :port suffix is not being used.

At least one of the -c or -s options must be specified. If one of them is not specified, it is assumed to be the local.

Okay so bestie, authmethod is a specifically ordered list of keywords — you only need it if you want authenticated communication with sendhost. These keywords are used to describe the type of communication and authentication that should be used to contact the sendhost. If recvhost and sendhost share the same authentication methods and identities, it’s possible to specify the authmethod for both recvhost and sendhost using the -A argument. An authmethod specified with the -s option will override an authmethod specified with the -A argument for communication with the sendhost.

The format for authmethod and a description of the currently available authentication methods are described with the -A argument.

  • -o, --flip — By default, the sender will connect to the receiver. The --flip option causes the receiver to connect to the sender. This option is not available for all test types (e.g. for iperf tests). This is most useful if the receiver is behind a firewall.

🧪 bwctl Test Arguments:

The arguments were named to match their counterparts in Iperf as closely as possible. (Iperf said “copy my fit but don’t make it obvious” 😭💅)

  • -T, --tool — Specify which throughput tester to use:
    • iperf
    • iperf3
    • nuttcp Default: None. Selects a tool that the client and server have in common.
  • -S, --tos TOS — Set the TOS byte in the sending packets. Default: None.
  • -D, --dscp DSCP — Set an RFC 2474 style DSCP value for the TOS byte in the sending packets. This can be set using a 6-bit numeric value in decimal, hex, or octal. Additionally, the following set of symbolic DSCP name constants are understood. (Example applications are taken from RFC 4594.)
    • NONE, DEFAULT (000000), DF, CS0 — Service Class: Standard; Examples: Undifferentiated
    • CS1 (001000) — Service Class: Low-Priority Data; Examples: No BW assurance
    • AF11 (001010), AF12 (001100), AF13 (001110) — Service Class: High-Throughput Data; Examples: Store and forward
    • CS2 (010000) — Service Class: OAM; Examples: OAM&P
    • AF21 (010010), AF22 (010100), AF23 (010110) — Service Class: Low-Latency Data; Examples: Web-based ordering
    • CS3 (011000) — Service Class: Broadcast Video; Examples: TV & live events
    • AF31 (011010), AF32 (011100), AF33 (011110) — Service Class: Multimedia Streaming; Examples: Streaming video and audio
    • CS4 (100000) — Service Class: Real-Time Interactive; Examples: Video conf and gaming
    • AF41 (100010), AF42 (100100), AF43 (100110) — Service Class: Multimedia Conferencing; Examples: H.323 video conferencing
    • CS5 (101000) — Service Class: Signaling; Examples: Video conf and gaming
    • EF (101110) — Service Class: Telephony; Examples: IP Telephony bearer
    • CS6 (110000) — Service Class: Network Control; Examples: Network routing
    • CS7 (111000) — (no Service Class or Examples listed)

Default: Unset.

  • -b, --bandwidth bandwidth — Limit UDP send rate to bandwidth (bits/sec). Default: 1 Mb
  • -i, --report_interval interval — Report interval (seconds). Default: unset (no intervals reported)
  • -l, --buffer_length len — length of read/write buffers (bytes). Default: 8 KB TCP, 1470 bytes UDP
  • -O, --omit seconds — Initial period of data to omit from the final statistics. This is so that you can skip past initial conditions such as TCP Slow Start. Currently only implemented by the iperf3 tool.
  • -P, --parallel nStreams — Number of concurrent streams for the test. See the -P option of Iperf for details.
  • -t,--test_duration time — Duration of test (seconds). Default: 10
  • -u, --udp — UDP test. Default: TCP test
  • -W,--dynamic_window window — Same as the -w option, except that the value is advisory. bwctl will attempt to dynamically determine the appropriate TCP window, based upon RTT information gathered from the control socket. If bwctl is unable to dynamically determine a window, the value window will be used. Default: Unset (system defaults)
  • -w, --window window — Socket buffer sizes (bytes). For TCP, this sets the TCP window size. For UDP, this sets the socket receive buffer size. Default: Unset (system defaults)

🏓 bwping Test Arguments:

  • -T, --tool — Specify which throughput tester to use:
    • ping
    • owamp Default: None. Selects a tool that the client and server have in common.
  • -E, --no_endpoint — Allow a ping test to run where the receiver may not have bwctl available.
  • -l, --packet_length length — The size of the packets to send for the ping or owamp test. Default: Minimally sized packets
  • -N, --num_packets nPackets — The number of packets to send in this test. Default: 10
  • -i, --packet_interval seconds — The time between when each packet is sent for the test. Default: 1.0 seconds
  • -t, --ttl ttl — The TTL value to tag each packet with. This only applies to ping tests. Default: None

🧭 bwtraceroute Test Arguments:

  • -T, --tool — Specify which throughput tester to use:
    • traceroute
    • tracepath Default: None. Selects a tool that the client and server have in common.
  • -E, --no_endpoint — Allow a test to run where the receiver may not have bwctl available.
  • -l, --packet_length length — The size of the packets to send for the tests. Default: Minimally sized packets
  • -F, --first_ttl ttl — The minimum TTL to set for traceroute. This sets the first hop in the route that will be returned. This does not work for tracepath tests. Default: None
  • -M, --max_ttl ttl — The maximum TTL to set for traceroute. This sets the last hop in the route that will be returned. This does not work for tracepath tests. Default: None
  • -t, --test_duration secondsfR — The maximum amount of time to wait for the traceroute test to finish. Default: 10 seconds

Scheduling Arguments 💖

okay so this is the when of it all, bestie. Time windows, intervals, all that scheduling drama. Let's get into it. ⏰

  • -a, --allow_ntp_unsync syncfuzz — Let bwctl run even when the system clock isn't NTP-synced. You use this to say how far off the local clock is from UTC. bwctl really prefers an NTP-synchronized system clock, because both endpoints need to agree on the same scheduled time window for test execution.

If two systems do NOT have a close enough notion of time, then the throughput test will eventually fail, because one endpoint of the test will attempt to run at a different time than the other. 😭

If the operating system supports the NTP system calls, and the system clock is determined to be unsynchronized, error messages will still be reported depending upon the value of the -e flag.

When calculating the time errors, this value will be added in to account for the difference. The maximum time offset can be bounded on the server side, using the max_time_error directive, to prevent a denial of service attack. If set, the server will reject any requests to test with a peer that has too high a timestamp error.

Default: Unset (Defaults to Set for systems without the NTP system calls)
  • -I, --test_interval interval — Specifies that bwctl should attempt to run a throughput test every interval seconds.
Default: Unset. If it is unset, bwctl only runs the test once.
  • -L, --latest_time longest — Specifies the longest amount of time the client is willing to wait for a reservation window. When bwctl requests a test from the bwctld server, it specifies the earliest time and the latest time it is willing to accept. The latest time is determined by adding this longest option to the earliest time. The earliest time is essentially 'now'. The longest time is specified as a number of seconds.
Default: If interval is set, the default is 50% of interval. Otherwise, the default is twice the test duration time but no smaller than 10 minutes. (See -t.)
  • -n, --num_tests nIntervals — Number of tests to perform if the -I option is set.
Default: Continuous
  • -R, --randomize alpha — Randomize the start time of the test within this alpha percent of the interval. Valid values for alpha are from 0-50. bwctl will attempt to run the test every interval +/- alpha percent. For example, if the interval is 300 seconds and alpha is set to 10 percent, then bwctl will attempt to run a test every 270-330 seconds. This option is only useful with the -I option.
Default: 0 (no randomness)

Output Arguments ✨

now for where the results go and how they look. aesthetic matters, okay?

  • -d, --output_dir dir — Specifies directory for results files if the -p option is set.
  • -e, --facility facility — Syslog facility to log messages to.
Default: LOG_USER
  • -f, --units units — Specify the units for the tool to use when displaying the results. The accepted values for units are tool specific.

Iperf:

  • k — Kilobits per second
  • K — Kilobytes per second
  • m — Megabits per second
  • M — Megabytes per second
  • -h, --help — Print a help message.
  • -p, --print — Place test results in files. Print the filenames to stdout when results are complete.
  • -q, --quiet — Quiet output. Output as little as possible.
  • -r, --syslog_to_stderr — Send syslog messages to stderr. This is the default unless the -q option is specified, so this option is only useful with the -q option.
  • -V, --version — Print version information and exit.
  • -v, --verbose — Verbose output. Specifying additional -v's increases the verbosity.
  • -x, --both — Output both sender and receiver results. By default, only the results from the appropriate side for the given tool are output. If the -p option is specified, the sender results are placed in an additional file.
  • -y, --format format — Specify the output format of the tool. The accepted values for format are tool specific.

Iperf:

  • c — [c]omma-separated output

ENVIRONMENT VARIABLES 🌈

bwctl environment variables, bestie. The little chart is variable → use → default:

  • BWCTLRC — use: Config file, default: ~/.bwctlrc
  • BWCTL_DEBUG_TIMEOFFSET — use: Offset, default: 0.0(seconds)

EXAMPLES 💅

bwctl -c somehost.example.com

Run a default 10 second TCP test as soon as possible with local as the sender and somehost.example.com as the receiver, using whichever tools they have in common. Return the results from the receive side of the test.

bwctl -x -c somehost.example.com

Like the previous test, but also return the results from the sender side of the test.

bwctl -x -c somehost.example.com -s otherhost.example.com

Like the previous test, but with otherhost.example.com as the sender instead of local.

bwctl -t 30 -T iperf -s somehost.example.com

Run a 30 second TCP Iperf test with somehost.example.com as the sender and local as the receiver.

bwctl -I 3600 -R 10 -t 10 -u -b 10m -s somehost.example.com

Run a 10 second UDP test about every hour (3600 +/- 360 seconds) with the sender rate limited to 10 Mbits per second from somehost.example.com to local.

bwctl -s somehost.example.com AE AESKEY someuser

Run the default 10 second TCP test. Authenticate using the identity someuser. bwctl will prompt for a passphrase that will be used to create an AES key.

bwping --no_endpoint -N 30 -i 0.5 --ttl 150 -c somehost.example.com

Run a ping test that sends 30 pings, one packet per half-second, with a TTL of 150 to somehost.example.com from local. If somehost.example.com does not have bwctl running, the ping test runs anyway.

bwtraceroute -T tracepath -E -c somehost.example.com

Run a tracepath test to somehost.example.com from local. If somehost.example.com does not have bwctl running, the tracepath test runs anyway.

SEE ALSO 👑

ACKNOWLEDGMENTS 🫶

This material is based in part on work supported by the National Science Foundation (NSF) under Grant No. ANI-0314723. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the NSF.

and that's the whole vibe, bestie 💖 — this page is bwctl(1), dated $Date$, periodt. 💅

📦 where this page comes from