Skip to main content
The skb tracking section enables following packets through the Linux networking stack by assigning unique tracking IDs based on the socket buffer’s original head pointer and timestamp.

​
Fields

​
orig_head
u64
required
Head of buffer - the value of skb->head when the packet was first seen by the tracking logic.This pointer, combined with the timestamp, creates a unique tracking ID for the packet.
​
timestamp
u64
required
Timestamp when the tracking logic first saw the packet (in nanoseconds).Combined with orig_head to form the unique tracking ID.
​
skb
u64
required
Current socket buffer address - the address of the struct sk_buff *.Used to distinguish between skb clones that share the same tracking ID.

​
Tracking ID

The unique tracking ID for a packet is computed as: 
tracking_id = (timestamp << 64) | orig_head
This creates a 128-bit identifier that:
  • Remains consistent for a packet across the network stack
  • Is shared between skb clones (same packet, different skbs)
  • Changes only when the underlying packet data is reallocated

​
SKB Address

The skb field contains the current skb pointer, which allows distinguishing between:
  • Related packets: Same tracking_id, different skb (clones)
  • Same packet: Same tracking_id, same skb (same skb at different probes)

​
Display Format

#{tracking_id_hex} (skb {skb_hex})
Example: 
#1a2b3c4d5e6f7890abcdef0123456789 (skb ffff8881234abcd0)

​
Example JSON

​
Basic Tracking Event

{
  "skb_tracking": {
    "orig_head": 18446623346735780864,
    "timestamp": 7322460997041,
    "skb": 18446623349161350912
  }
}

​
Multiple Events for Same Packet

Event 1 (first time packet is seen): 
{
  "skb_tracking": {
    "orig_head": 18446623346735780864,
    "timestamp": 7322460997041,
    "skb": 18446623349161350912
  }
}
Event 2 (same packet, same skb): 
{
  "skb_tracking": {
    "orig_head": 18446623346735780864,
    "timestamp": 7322460997041,
    "skb": 18446623349161350912
  }
}
Event 3 (cloned skb): 
{
  "skb_tracking": {
    "orig_head": 18446623346735780864,
    "timestamp": 7322460997041,
    "skb": 18446623349161362048
  }
}
All three events share the same tracking ID (same orig_head and timestamp), but events 2 and 3 have different skb addresses.

​
Tracking Info Section

During post-processing with the sort command, the skb_tracking section may be replaced with a tracking section that includes an event index:
​
tracking
TrackingInfo
Enhanced tracking information added during post-processing.

​
TrackingInfo Fields

​
Display Format with Index

#{tracking_id_hex} (skb {skb_hex}) n {index}
Example: 
#1a2b3c4d5e6f7890abcdef0123456789 (skb ffff8881234abcd0) n 5

​
Example JSON (Post-Processed)

{
  "tracking": {
    "skb": {
      "orig_head": 18446623346735780864,
      "timestamp": 7322460997041,
      "skb": 18446623349161350912
    },
    "idx": 5
  }
}

​
When This Section Appears

The skb tracking section is populated when:
  • The skb-tracking collector is enabled (-c skb-tracking)
  • The probe has access to an struct sk_buff * parameter
  • This is the first time Retis sees this packet (assigns tracking ID)

​
Reconstructing Packet Flows

Use tracking IDs to reconstruct packet journeys:
  1. Filter by tracking ID: Find all events with the same tracking_id
  2. Sort by timestamp: Order events chronologically (use retis sort)
  3. Follow the path: Trace the packet through kernel functions
  4. Identify clones: Events with same tracking_id but different skb are clones

​
Example Flow

7322460997041 [k] ip_rcv          #1a2b...6789 (skb ffff8881234abcd0) n 0
7322460997156 [k] ip_forward      #1a2b...6789 (skb ffff8881234abcd0) n 1  
7322460997234 [k] ip_output       #1a2b...6789 (skb ffff8881234abcd0) n 2
7322460997299 [k] skb_clone       #1a2b...6789 (skb ffff8881234a1000) n 3  (clone!)
7322460997401 [k] dev_queue_xmit  #1a2b...6789 (skb ffff8881234abcd0) n 4

​
Limitations

Tracking IDs are not preserved across:
  • Packet reallocations (new skb->head)
  • Packet fragmentation/reassembly
  • Encapsulation/decapsulation (in some cases)
  • Packet copies with new buffers
In these cases, a new tracking ID is assigned.
For complete packet flow analysis, use the retis sort command which groups and sorts events by tracking ID, adding the idx field to show event order.

Build docs developers (and LLMs) love

Get started for freeTalk to us