When I try to compile TraceProto, the configure complains
checking for libnet_init in -lnet... no
configure: error: ERROR - libnet check failed
How do I get it to compile?
First make sure that you have libnet installed correctly. If you
are using linux, try
Assuming its there, try specifying the --with-libnet-dir configure
option. If your libnet.a is in /usr/lib/libnet.a you would use
The same applies to libpcap, except that you would use --with-pcap-dir.
When I tried to compile TraceProto, the configure works but the
make bombs with errors about libnet. How do I get it to compile?
The first step is to make sure that you have the correct version
of libnet. TraceProto uses the libnet 1.1.x tree and is not
compatible with the older 1.0.x Libnet. The newer version is
If that doesn't work try specifying the libnet location using the
configure option. If
your libnet.a is in /usr/lib/libnet.a and the libnet.h is at
/usr/include/libnet.h you would use
If it still doesn't compile, file a bug report at
What does the '--with-pcap-fileno' configure option do?
Libpcap is the packet capture library better known as the library
behind the tcpdump utility. It has some very nifty features, but
unfortunately also has some rough edges. The timeout built into
the library that returns if the capture function hasn't seen a
packet come in after the timeout fails to work on linux and possibly
other platforms. Further, the pcap documentation fails to
accurately identify the pcap_fileno as a way to access the socket
file descriptor which allows for the use of the select function
to do the same timeout.
Kudos to Michael Toren, the author of
tcptraceroute who documented the correct usage of pcap_fileno
and his workaround so nicely in his source code.
The end result is that the user has a choice at compile time --
use the pcap_fileno to do impliment the timeout or to use the
original traceproto workaround which is the default. (The
pcap_fileno is probably the better method and will likely become
the default after further testing.)
When I trace to location X, the first time it works and the next
time the last hop or the second to the last hop tims out completely.
When I try a third time sometimes it works and sometimes there are
two missing hops. Whats going on?
Whats probably happening is that there is a stateful firewall in the path.
It may or may not show up as a hop, but it is probably at or before the
hop that goes missing. The first time you trace through it, the firewall
puts an entry in its connection list. As the first trace finishes the
firewall observes that and marks the connection as closed but it may not
actually remove the connection from the list yet. It may hold on to the
connection record for a certain perion of time.
8 X X X
9 X X X
10 X X X
11 S S S
8 X X X
9 X X X
10 X X X
11 * * *
12 S S S
Since TraceProto starts with a standard port number, the firewall sees
the second trace and beleives it to be duplicate packets from the closed
connection and drops them. Try specifying a different starting port
with the '-s' flag. There are plans in the future to randomize the
starting source port.
NOTE: The 0.9.2beta0 has the randomized starting source port
and the effect is still in evidence. Obviously the simple
explanation is not the correct one in this case. Anyone who observes
the effect and has information about the firewall in question -- let
us know what you know.
Is there a Windows port of TraceProto?
At the moment, no. TraceProto was originally written without Windows portability
in mind. There have been several requests for a Windows port and the initial
research indicates that it may be possible. Lack of Windows programming experiance
is going to be a factor, so while it is tentatively in the works, don't expect it
until its posted (though we'll probably post a news item from time to time with