gnunet-transport-check - a tool to test a GNUnet transport service

gnunet-transport-check [OPTIONS]

gnunet-transport-check can be used to test or profile a GNUnet transport service. The tool can be used to test both the correctness of the software as well as the correctness of the configuration. gnunet-transport-check features two modes, called loopback mode and ping mode. In loopback mode the test is limited to testing if the transport can be used to communicate with itself (loopback). This mode does not include communication with other peers which may be blocked by firewalls and other general Internet connectivity problems. The loopback mode is particularly useful to test the SMTP transport service since this service is fairly hard to configure correctly and most problems can be reveiled by just testing the loopback. In ping mode the tool will attempt to download peer advertisements from the URL specified in the configuration file and then try to contact each of the peers. Note that it is perfectly normal that some peers do not respond, but if no peer responds something is likely to be wrong. The configuration is always taken from the configuration file. Do not run gnunetd while running gnunet-transport-check since the transport services cannot be used by two processes at the same time.

gnunet-transport-check will always produce an error-message for the NAT transport in loopback mode. If NAT is configured in accept-mode (as in, accept connections from peers using network address translation), the check will fail with the message "could not create HELO", which is correct since the peer itself is clearly not going to advertise itself as a NAT. If the peer is configured in NAT-mode, that is, the peer is behind a NAT box, the message will be but exactly what is supposed to happen.

Similarly, a NAT-ed peer should typically configure the TCP transport to use port 0 (not listen on any port). In this case, gnunet-transport-check will print 'could not create HELO' for the TCP transport. This is also ok. In fact, a correctly configured peer using NAT should give just two errors (could not connect for tcp and could not create HELO for NAT) when tested using gnunet-transport-check. The reason is, that gnunet-transport-check only tests loopback connectivity, and for a NAT-ed peer, that just does not apply.

Note that in ping mode the HTTP download times out after 5 minutes, so if the list of peers is very large and not all peers can be queried within the 5 minutes the tool may abort before trying all peers.

-c FILENAME, --config=FILENAME

use config file (default: /etc/gnunet.conf)

-h, --help

print help page

-L LOGLEVEL, --loglevel=LOGLEVEL

change the loglevel. Possible values for LOGLEVEL are NOTHING, FATAL, ERROR, FAILURE, WARNING, MESSAGE, INFO, DEBUG, CRON and EVERYTHING.

-p, --ping

use ping mode (loopback mode is default)

-r COUNT --repeat=COUNT

send COUNT messages in a sequence over the same connection

-s SIZE --size=SIZE

test using the specified message size, default is 11

-t TRANSPORT, --transport=TRANSPORT

run using the specified transport, if not given the transports configured in the configuration file are used.

-u USER, --user=USER

run as user USER (and if available as group USER). Note that to use this option, you will probably have to start gnunet-transport-check as root. It is typically better to directly start gnunet-transport-check as that user instead.

-v, --version

print the version number

-V, --verbose

be verbose

gnunet-transport-check can run for a long time, depending on how high you have set the COUNT level. Run first with small numbers for COUNT to get an initial estimate on the runtime.

/etc/gnunet.conf

default gnunetd configuration file

Report bugs by using mantis <https://gnunet.org/mantis/> or by sending electronic mail to <gnunet-developers@gnu.org>

gnunetd.conf(5), gnunetd(1)