NAME¶

bbctl - query and control tool for BitBabbler hardware RNG devices

SYNOPSIS¶

bbctl [options]

DESCRIPTION¶

The bbctl program can be used to issue command requests to the control socket of software controlling a BitBabbler device (such as the seedd(1) daemon).

OPTIONS¶

The following options are available:

-s, --scan

Scan for active devices. This will report the device identifiers which can be queried from the owner of the control socket.

-i, --device-id=id

Act on only the specified device. If no devices are explicitly specified then the default is to act upon all of them. This option may be passed multiple times to act on some subset of the available devices. The id must be an identifier name as reported by bbctl --scan, you cannot use device logical or physical addresses here.

-b, --bin-freq

Report the 8-bit symbol frequencies.

-B, --bin-freq16

Report the 16-bit symbol frequencies.

--bin-count

Report the 8-bit symbol counts. Similar to --bin-freq except the bins are reported in symbol order instead of sorted by frequency.

--bin-count16

Report the 16-bit symbol counts. Similar to --bin-freq16 except the bins are reported in symbol order instead of sorted by frequency.

--first=n

Show only the first n results. Useful when you don't want to actually see all 65 thousand entries for the 16-bit bins. The default (if neither this nor the --last option are specified) is to report everything in its full glory. Don't say I didn't warn you.

--last=n

Show only the last n results. Useful when you don't want to actually see all 65 thousand entries for the 16-bit bins. If used together with the --first option, then both the requested head and tail of the results will be shown.

-r, --bit-runs

Report on runs of consecutive bits.

-S, --stats

Report general QA statistics.

-c, --control-socket=path

The filesystem path for the service control socket to query. This can belong to any process that supports the BitBabbler control socket interface and for which the user running bbctl has permission to connect to.

An address of the form tcp:host:port may be used if the control socket is bound to a TCP port rather than a unix domain socket path. The host part can be a DNS hostname or address literal. If an IPv6 address literal is used it should be enclosed in square brackets (e.g. tcp:[::1]:2020 to bind to port 2020 on the local IPv6 interface). The port can be a port number or a service name (as defined in /etc/services or other system name-service databases which are queried by getaddrinfo(3)).

-V, --log-verbosity=n

Change the logging verbosity of the control socket owner.

--waitfor=device:passbytes:retry:timeout

This option will make bbctl wait before exiting until the seedd(1) QA checking reports that at least passbytes of good entropy have been obtained from the given device. It will check for that every retry milliseconds, waiting for a maximum of timeout milliseconds before failing.

The device is a QA test identifier as reported by --scan, and must be provided, as must the expected passbytes count. The retry time is optional, and if not specified it will default to 1000 milliseconds. If the timeout is 0 (or not explicitly passed), then this will wait for an unbounded amount of time for the requested condition to occur.

The passbytes, retry, and timeout parameters may be suffixed with an SI multiplier (e.g. k, M, G) as a convenience, so a timeout of 30k would wait for 30 seconds.

This option may be passed multiple times to wait for multiple devices, and the given conditions for each of them will be tested for in the order that they are specified on the command line. i.e. Later conditions will not be tested for at all until all prior ones have been met, and the timeout clock for each test only begins after the previous test has successfully completed.

When all required conditions pass, bbctl will report success with an exit code of 0. If a timeout is exceeded, or any other error occurs which means the test cannot be successfully completed (like passing a device which does not exist, or querying a --control-socket which no process provides), then a non-zero exit code will be returned.

This option mostly exists to make it possible to delay or even prevent other services from starting until a sufficient amount of entropy has been obtained to feel comfortable that they can operate securely or as intended. See the notes on BOOT SEQUENCING in seedd(1) for more details on that. It may be used for other purposes too, but note that passbytes is an absolute measure of the number of good bytes seen since seedd was started, it is not relative to the number that were obtained prior to executing this request.

-v, --verbose

Make more noise about what is going on internally. It may be passed multiple times to get swamped with even more information.

-?, --help

Show a shorter version of all of this, which may fit on a single page.

--version

Report the bbctl release version.

FILES¶

/run/bit-babbler/seedd.socket

The default --control-socket path if not explicitly specified. This may be under /var/run on platforms which don't (yet) provide a /run top level directory (or a TCP socket on platforms which don't support unix domain sockets). It is set at compile time by SEEDD_CONTROL_SOCKET.

SEE ALSO¶

seedd(1).

AUTHOR¶

seedd was written by Ron <ron@debian.org>. You can send bug reports, feature requests, praise and complaints to support@bitbabbler.org.