NAME
gnunet-transport-check - a tool to test a GNUnet transport service
SYNOPSIS
gnunet-transport-check [OPTIONS]
DESCRIPTION
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/gnunetd.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
NOTES
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.
FILES
/etc/gnunetd.conf
default gnunetd configuration file
REPORTING BUGS
Report bugs by using mantis <https://gnunet.org/bugs/> or by sending
electronic mail to <gnunet-developers@gnu.org>
SEE ALSO
gnunetd.conf(5), gnunetd(1)