Ping on the Linux Loopback Interface Packet Capture

Lesson Contents

This packet capture contains one ping to 127.0.0.1, captured on the Linux loopback interface lo. Traffic to localhost never touches a network card, so many people assume you can’t capture it. You can: on Linux, run Wireshark or tcpdump -i lo. What you get looks a little strange: Ethernet headers with all-zero MAC addresses, the same IP address as source and destination, and a reply that arrives 13 microseconds after the request.

Two packets is all it takes to see how the loopback interface works, and how Linux ping measures round-trip time. More captures are in the Packet Capture Library.

Want to open this capture in Wireshark yourself? The pcap file is free with a NetworkLessons account. Your free account also unlocks all our free lessons and every capture in the Packet Capture Library.

Create a free account to download the pcap

Already have an account? Log in and the download button appears here.

Capture overview

File	linux-loopback-icmp.pcap
Packets	2 (echo request, echo reply)
Protocol	ICMP echo (RFC 792) over IPv4
Capture point	Linux loopback interface `lo`, link type Ethernet
Devices	A single Linux host running `ping -c 1 127.0.0.1`
Wireshark filter	`icmp` or `ip.addr == 127.0.0.1`

Packets in this capture

No. Time       Source     Destination  Length  Info
1   0.000000   127.0.0.1  127.0.0.1    98      Echo (ping) request  id=0x6bbb, seq=1/256, ttl=64
2   0.000013   127.0.0.1  127.0.0.1    98      Echo (ping) reply    id=0x6bbb, seq=1/256, ttl=64

Packet walkthrough

Echo request (packet 1)

Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
    Destination: 00:00:00_00:00:00 (00:00:00:00:00:00)
    Source: 00:00:00_00:00:00 (00:00:00:00:00:00)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Total Length: 84
    Identification: 0x27b4 (10164)
    010. .... = Flags: 0x2, Don't fragment
    Time to Live: 64
    Protocol: ICMP (1)
    Source Address: 127.0.0.1
    Destination Address: 127.0.0.1
Internet Control Message Protocol
    Type: Echo (ping) request (8)
    Code: 0
    Identifier (BE): 27579 (0x6bbb)
    Sequence Number (BE): 1 (0x0001)
    ICMP Data: a7ffde5a00000000fbfe050000000000101112131415161718191a1b1c1d1e1f...
        Timestamp from icmp data: Apr 24, 2018 09:57:59.392955000 UTC
        Data (40 bytes)

All-zero MAC addresses: the Linux loopback device pretends to be an Ethernet interface, so the capture has an Ethernet header, but there’s no real hardware and no ARP. The kernel just fills in zeros. On macOS and BSD, the loopback interface uses a different link type (Null/Loopback), and you won’t see an Ethernet header at all.
127.0.0.1 to 127.0.0.1: the whole 127.0.0.0/8 range is reserved for loopback. Packets to it never leave the host. Routers must never forward them, and a packet with a 127.x.x.x address on a real network is invalid.
TTL 64 and DF set: the Linux defaults. Windows uses TTL 128, and Cisco IOS uses 255. That’s a quick way to guess the operating system of the sender in any capture.
Identifier 0x6bbb: Linux ping uses an ID that’s unique to this ping process. Combined with the sequence number, it lets the program match each reply to its request. Wireshark shows the 16-bit fields in both byte orders (BE and LE), because different operating systems fill them differently. That’s why the packet list says seq=1/256.
Timestamp in the ICMP data: the first bytes of the payload are the time the request was sent (a Unix timestamp in seconds and microseconds). Linux ping reads it back from the reply to calculate the round-trip time, so it doesn’t need to remember when it sent each request. The rest of the data is a counting pattern (0x10, 0x11, 0x12…) that fills the default 56-byte payload.
98 bytes: 14 bytes of Ethernet header, 20 bytes of IP header, 8 bytes of ICMP header and 56 bytes of data. The default Linux ping size of 56 data bytes gives the familiar “64 bytes from…” output, counting ICMP header plus data.

Echo reply (packet 2)

Internet Control Message Protocol
    Type: Echo (ping) reply (0)
    Code: 0
    Checksum: 0x4e17 [correct]
    Identifier (BE): 27579 (0x6bbb)
    Sequence Number (BE): 1 (0x0001)
    ICMP Data: a7ffde5a00000000fbfe050000000000101112131415161718191a1b1c1d1e1f...
        Timestamp from icmp data: Apr 24, 2018 09:57:59.392955000 UTC
        Data (40 bytes)

Type 0 (echo reply) with the same identifier, sequence number and data as the request. The reply copies the payload, including the timestamp, back to the sender.
13 microseconds: the reply arrives 0.000013 seconds after the request. The kernel answers the ping itself, with no cable, switch or network card involved, so this is pure processing time in the IP stack. Any ping to a real host takes longer, and that difference is your network latency.

Capturing on lo is useful for more than ping: you can see the traffic between a local application and a local service, such as a web app talking to a database on the same server, or a network automation script talking to a local API.