Layer Four Traceroute (LFT) and WhoB

The alternative traceroute and whois tools for network (reverse) engineers

04/26  LFT 3.98 released! Minor build system fixes for Linux packaging/autoconf.

  LFT 3.97: New in 3.97: ECMP hashing support added to ICMP and UDP tracing engines (TCP has been ECMP-friendly since 1998); New --watch mode with ncurses textual user interface support is about as cool as you can make things look textually; Speedups achieved using LFT autotune for continuous tracing. Enjoy.

  LFT 3.96: New in 3.96: active Path MTU Discovery (-K) discovers bottleneck link MTU across all probe modes (TCP, UDP, ICMP); per-hop RTT statistics (-j N) renders a candlestick chart with min/avg/max/stddev and jitter alerts above the ASCII art hop diagram; asynchronous reverse DNS via c-ares makes traces noticeably faster; Unicode annotation glyphs and a richer x-axis label (End-to-End RTT & protocol/port) improve the -o display. Also includes autoconf modernization and a fully updated Windows build system.

03/26  LFT 3.95: modernized to getaddrinfo/getnameinfo throughout, added async DNS, getopt_long long-form options, and the new -o ASCII art hop diagram. LFT 3.94: libpcap API modernization and Linux setcap support.

LFT, short for Layer Four Traceroute, is a sort of 'traceroute' that often works much faster (than the commonly-used Van Jacobson method) and goes through many configurations of packet-filters (firewalls). More importantly, LFT implements numerous other features including AS number lookups through several reliable sources, loose source routing, netblock name lookups, et al. What makes LFT unique? LFT is the all-in-one traceroute tool because it can launch a variety of different probes using ICMP, UDP, and TCP protocols, or the RFC1393 trace method. For example, rather than only launching UDP probes in an attempt to elicit ICMP "TTL exceeded" from hosts in the path, LFT can send TCP SYN or FIN probes to target arbitrary services. Then, LFT listens for "TTL exceeded" messages, TCP RST (reset), and various other interesting heuristics from firewalls or other gateways in the path. LFT also distinguishes between TCP-based protocols (source and destination), which make its statistics slightly more realistic, and gives a savvy user the ability to trace protocol routes, not just layer-3 (IP) hops. With LFT's verbose output, much can be discovered about a target network.

WhoB is a likable whois client (see whois(1)) designed to provide everything a network engineer needs to know about a routed IP address by typing one line and reading one line. But even so, it's worth typing a few more lines because WhoB can do lots of other cool things for you! It can display the origin-ASN based on the global routing table at that time (according to Prefix WhoIs, RIPE NCC, or Cymru), the 'origin' ASN registered in the RADB (IRR), the netname and orgname, etc. By querying pWhoIs, WhoB can even show you all prefixes being announced by a specific Origin-ASN. WhoB performs the lookups quickly, the output is easily parsed by automated programs, and it's included as part of the Layer Four Traceroute (LFT) software package. LFT uses WhoB as a framework (and you can too, quite easily--see whois.h). Recent LFT releases (as of version 2.5) include WhoB functionality through a standalone "whob" client/command placed in the LFT binary directory.

LFT and WhoB continue to evolve and provide more and more useful data to network engineers and to anyone else that cares how IP datagrams are being routed. With the advent of smarter firewalls, traffic engineering, QoS, and per-protocol packet forwarding, LFT and WhoB have become invaluable tools for many network managers worldwide.

LFT and WhoB are released under our open source license.

NOTES CONCERNING PLATFORMS AND DISTRIBUTIONS

Many people have complained about various problems on the Windows platform. Both LFT and the WhoB client compile and run well under Cygwin environments on Windows. Unfortunately, Microsoft's changes to the Windows IP stack (beginning with XP Service Pack 2) reduced raw socket functionality significantly as part of their security hardening process. These changes have effectively prevented LFT from working properly while using TCP. LFT's UDP tracing and other advanced features still work properly.

BUILDING LFT

LFT builds and tests successfully on most Linux systems, most BSD-based systems (OpenBSD, FreeBSD), Darwin (macOS), and Solaris. The autoconf (./configure) script should appropriately identify and configure makefiles for these and various other target platforms.

COMPILATION

Note that before you can compile LFT on UNIX-like systems, you need to install libpcap. It is available from the tcpdump/libpcap website.

LFT supports autoconf! To build LFT for your system, use the ./configure script.

The easy way: Configure, build, and install LFT in one go (root required for install):

# ./configure && make && sudo make install

On Linux, make install automatically uses setcap(8) to grant LFT only the specific network capabilities it needs (cap_net_raw,cap_net_admin) — no setuid root required. On FreeBSD and other platforms, LFT is installed setuid root. Root access is required for make install in both cases.

On macOS, LFT requires setuid root because it uses two separate privilege paths: libpcap (via /dev/bpf*) for capturing response packets, and a raw socket (SOCK_RAW) for sending probe packets. ChmodBPF (the mechanism used by Wireshark) only grants access to BPF capture devices — it does not grant the ability to create raw sockets, which on macOS requires root. Unlike Linux, macOS has no setcap equivalent to selectively grant raw socket capability to a binary.

The recommended installation on macOS is therefore setuid root:

# sudo chown root /usr/local/bin/lft && sudo chmod u+s /usr/local/bin/lft

This is standard practice for network diagnostic tools on macOS — ping and traceroute ship setuid root for the same reason. make install performs this step automatically when run as root.

If you are installing manually (without make install), grant privileges appropriate for your platform:

Linux — preferred, least privilege:

# sudo setcap cap_net_raw,cap_net_admin=eip ./lft

BSD / macOS — setuid root (required):

# sudo chown root lft && sudo chmod 4755 lft

REPORTING BUGS

Please send bug reports to lft AT oppleman.com

When reporting bugs, please include level-2 verbose output (e.g., "lft -VV <target>") in your e-mail / bug report.

CREDITS + THANKS

We thank the following contributors that either coded or helped test and debug problems with LFT (not ordered intentionally):

• Victor Oppleman - project maintainer, contributor
• Eugene Antsilevitch - contributor
• Sergey Kondryukov - contributor
• Zachary Kanner - contributor
• Lane Davis - contributor
• Robb Ballard - package maintainer
• Florin Andrei - packaging contributor
• Jim McKim - solaris port contributor
• Nils McCarthy - FFT's original author

AUTHORS' NOTE

To those who would ask the question "who did that first?" with regard to utilizing TCP for traceroute, the answer is "We don't know." However, LFT was first released to the public in 1998 under the name FFT, and that was the first we'd heard of.