lft

lft [options] <hostname|IP_address>

-p port
    Specifies the destination port for the probes. Essential for testing specific application services.

-s port
    Sets the source port for outgoing probes. Useful in specific firewall or NAT testing scenarios.

-t protocol
    Defines the transport protocol to use for probes (e.g., tcp, udp, icmp). Defaults to TCP if no port is specified.

-m max_ttl
    Sets the maximum number of hops (Time-To-Live) that lft will probe. Prevents infinite loops.

-i interface
    Specifies the network interface through which probes should be sent.

-a
    Disables hostname resolution for the hops. Displays only IP addresses, which can speed up output.

-c
    Enables 'connect' mode, particularly for TCP probes. lft will attempt a full TCP handshake (SYN/ACK) rather than just SYN.

-q num_queries
    Determines the number of probes sent for each hop. More probes provide more reliable round-trip time averages.

-w timeout
    Sets the timeout in seconds to wait for a response from a hop before moving to the next.

-v
    Activates verbose output, providing more detailed information about the probing process and responses.

lft, or Layer Four Traceroute, is a powerful network diagnostic utility similar to the standard traceroute command, but with significantly enhanced capabilities. While traceroute primarily relies on ICMP packets to map network paths, lft can employ a variety of transport protocols, including TCP SYN, UDP, and ICMP, and allows specifying arbitrary source and destination ports.

This flexibility makes lft invaluable for scenarios where traditional traceroute is insufficient, such as troubleshooting connectivity through firewalls, testing the reachability of specific application ports (e.g., HTTP on port 80, SSH on port 22), or diagnosing issues with NAT (Network Address Translation) devices. By sending probes on Layer 4, lft can often reveal path details that are obscured or blocked by firewalls configured to drop ICMP traffic. It displays each hop along the network path to a destination, along with round-trip times, and can optionally provide AS (Autonomous System) numbers for a more comprehensive view of network topology.

Using lft often requires root privileges due to its reliance on raw sockets for crafting and sending custom packets.

While its ability to use various protocols is a strength, it also means that specific probes (e.g., TCP SYN on unusual ports) might be blocked by firewalls more aggressively than standard ICMP echo requests. Conversely, firewalls designed to block ICMP might allow lft's TCP probes to pass.

The tool can generate a fair amount of network traffic, especially with higher query counts or longer traces, and its output can be complex for users unfamiliar with network protocols.

lft operates by sending probe packets with an incrementally increasing Time-To-Live (TTL) value, starting from 1. Each router along the path decrements the TTL. When a packet's TTL reaches zero, the router typically sends an ICMP 'Time Exceeded' message back to the source. lft captures these messages to identify the router at each hop. By allowing users to specify the type of probe (TCP SYN, UDP, or ICMP) and the destination port, lft can effectively simulate various types of network traffic, providing insights into how different protocols and ports traverse a network path.

The output of lft displays each hop's IP address and (optionally) hostname, along with the round-trip time(s) for the probe(s) sent to that hop. Asterisks (*) indicate that a probe timed out or no response was received. Depending on the options used, lft can also show Autonomous System (AS) numbers for each hop, which helps in understanding the ownership and routing policies of different segments of the network path.

lft was developed by Mike Schiffman (Schiffman Associates) in the early 2000s, specifically designed to address limitations found in traditional traceroute implementations. Its primary motivation was to provide a more robust and flexible tool for network path discovery, especially in environments secured by firewalls. It quickly found its niche among network administrators and security professionals needing to diagnose connectivity issues related to specific application ports or to test network paths that actively filtered standard ICMP probes. It has since been maintained as a valuable, albeit less common, alternative to its ICMP-centric predecessor.

traceroute(8), ping(8), nmap(1), netstat(8), ss(8)