TraceProto

checking for libnet_init in -lnet... no
configure: error: ERROR - libnet check failed

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

locate libnet.a

--with-libnet-dir=/usr/

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 http://www.packetfactory.net/Projects/Libnet/.

If that doesn't work try specifying the libnet location using the

--with-libnet-dir=/path/to/libnet/

--with-libnet-dir=/usr/
If it still doesn't compile, file a bug report at 

http://sourceforge.net/tracker/?atid=669390&group_id=114774&func=browse
 

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

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.

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.

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