.TH GNUNET-TRANSPORT "1" "23 Dec 2006" "GNUnet"
gnunet\-transport \- a tool to test a GNUnet transport service
gnunet\-transport 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 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 since the transport services cannot
be used by two processes at the same time.
gnunet\-transport 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
'could not connect'. For NAT, both messages are NOT errors
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 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\. The reason is, that gnunet\-transport\
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
\fB\-c \fIFILENAME\fR, \fB\-\-config=\fIFILENAME\fR
use config file (default: /etc/gnunetd.conf)
print help page
\fB\-L \fILOGLEVEL\fR, \fB\-\-loglevel=\fILOGLEVEL\fR
change the loglevel. Possible values for \fILOGLEVEL\fR are NOTHING, FATAL, ERROR, FAILURE, WARNING, MESSAGE, INFO, DEBUG, CRON and EVERYTHING.
use ping mode (loopback mode is default)
\fB\-r\fI COUNT \fB\-\-repeat=\fICOUNT\fR
send COUNT messages in a sequence over the same connection
\fB\-s\fI SIZE \fB\-\-size=\fISIZE\fR
test using the specified message size, default is 11
\fB\-t\fI TRANSPORT\fR, \fB\-\-transport=\fITRANSPORT\fR
run using the specified transport, if not given the transports
configured in the configuration file are used.
\fB\-u \fIUSER\fR, \fB\-\-user=USER\fR
run as user USER (and if available as group USER). Note that to use this option, you will probably have to start gnunet-transport as
root. It is typically better to directly start gnunet-transport as that user instead.
print the version number
gnunet\-transport can run for a long time, depending on
how high you have set the \fICOUNT\fR level. Run first with small numbers
for \fICOUNT\fR to get an initial estimate on the runtime.
default gnunetd configuration file
.SH "REPORTING BUGS"
Report bugs by using mantis <https://gnunet.org/mantis/> or by sending electronic mail to <firstname.lastname@example.org>
.SH "SEE ALSO"