Question 1) 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?

Answer 1) First make sure that you have libnet installed correctly. If you are using linux, try

locate libnet.a
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.

Question 2) When I tried to compile TraceProto, the configure works but the make bombs with errors about libnet. How do I get it to compile?

Answer 2) 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 available at

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

Question 3) What does the '--with-pcap-fileno' configure option do?

Answer 3) 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.)

Question 4) 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?

Answer 4) 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.

First Trace
8  X X X
9  X X X
10  X X X
11  S S S
Second Trace
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.

Question 5) Is there a Windows port of TraceProto?

Answer 5) 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 the progress). Logo