dev collector provides information about network devices, either from a struct net_device available in probe arguments or through a struct sk_buff and its device reference.
Overview
Thedev collector extracts network device (interface) information as packets flow through the networking stack. This helps identify which interfaces packets are traversing and correlate events with specific network devices.
What Data is Retrieved
Thedev collector retrieves:
- Device name: Network interface name (e.g., “eth0”, “wlan0”)
- Interface index (ifindex): Unique numeric identifier for the device
- Rx interface index (rx_ifindex): Input interface for received packets (when available)
Probe Installation
The
dev collector does not install any probes. It only retrieves data when network device information is available in probe arguments.struct net_device *parametersstruct sk_buff *parameters (readsskb->dev)
Command-Line Options
Thedev collector has no specific command-line options.
Event Sections Produced
Thedev collector produces the dev event section.
See dev event documentation for detailed format.
Event Format
Usage Examples
Basic Device Tracking
Track which interfaces packets use:With Filtering
Monitor specific interface:Track Interface Path
See which interfaces a packet traverses:With Other Context
Combine with other collectors:Multi-Interface Debugging
Debug routing between interfaces:Example Output
Basic Output
With Receive Interface
Tracking Across Interfaces
Usingretis sort after collection:
Integration with Other Collectors
skb
Essential combination:skb-tracking
Track interface transitions:skb-drop
Identify where drops occur:ct (Conntrack)
Interface and connection state:nft (Netfilter)
Interface-based firewall rules:ovs (OpenVSwitch)
OVS port mapping:ns (Namespace)
Interface and namespace:Use Cases
Debug Routing
See which interface packets are routed to:Multi-Interface Hosts
Track traffic on specific interfaces:Bridge Debugging
See packets crossing bridge interfaces:VLAN Interfaces
Track VLAN interface handling:Tunnel Debugging
See packets entering/exiting tunnels:Container Networking
Understanding Interface Information
Interface Index (ifindex)
Unique numeric identifier:- Assigned by kernel when interface is created
- Persistent while interface exists
- Can be reused after interface deletion
- Use
ip link showto see current mapping
Interface Name
Human-readable identifier:- Can be changed with
ip link set name - Limited to 15 characters (IFNAMSIZ)
- Common patterns: ethX, wlanX, vethX, tunX, brX
Receive Interface (rxif)
Original input interface:- Available in some contexts (e.g., forwarding, bridging)
- Useful for tracking where packets entered the system
- Not always present (depends on packet path)
Common Interface Types
- Physical: eth0, ens33, eno1
- Wireless: wlan0, wlp2s0
- Virtual Ethernet: veth0, veth1 (usually in pairs)
- Bridges: br0, docker0
- Tunnels: tun0, gre0, vxlan0
- VLANs: eth0.100, vlan100
- Loopback: lo
- Bonding: bond0
Technical Details
Kernel Types
Thedev collector activates when these types appear in probe arguments:
struct net_device *struct sk_buff *(readsskb->dev)
Data Extraction
The collector:- Checks if
struct net_deviceis directly available - If not, checks if
struct sk_buffis available - Reads device information from
skb->dev - Extracts device name, ifindex, and rx_ifindex
- Validates data (device name must be valid UTF-8)
Union Considerations
skb->dev is in a union and isn’t always valid. The collector:
- Validates device name is UTF-8
- Returns empty section if data looks invalid
- Avoids reporting garbage data
Source Code References
- Collector:
retis/src/collect/collector/dev/dev.rs - eBPF hook:
retis/src/collect/collector/dev/bpf/dev_hook.bpf.c - Event factory: Inline in
dev.rs
Best Practices
- Combine with skb: Always collect packet data alongside device info
- Use tracking: Enable
skb-trackingto see interface transitions - Filter by interface: Use metadata filters for specific interfaces
- Check both directions: Monitor both transmit and receive paths
- Correlate with namespace: Use
nscollector in containerized environments
Performance Considerations
- No probe overhead: Doesn’t install probes
- Minimal extraction: Only reads when device info is available
- Small data: Device info adds ~20 bytes per event
- Efficient validation: Quick UTF-8 check
- Works with any probe: Activates automatically
Troubleshooting
No Device Information
If device information is missing:- Verify
devcollector is enabled - Check probes have appropriate arguments:
struct net_device *orstruct sk_buff *
- Some probe points may not have valid device info
Wrong Interface Name
If interface names seem wrong:- Check interface exists:
ip link show - Verify index matches:
ip link show dev <name> - Interface might have been renamed
- Interface might be in different namespace
Missing rxif
The receive interface is only available in certain contexts:- Forwarding scenarios
- Bridge processing
- Some routing contexts
rxif to be absent in many cases.
Invalid Device Data
If seeing empty device sections:- Device pointer might be NULL
- Device might be in invalid state
- Probe point might be before device assignment
- This is normal validation behavior
Filtering by Interface
By Name
By Index
Multiple Interfaces
See Also
- ns collector - Network namespace information
- skb collector - Packet data
- dev event format - Event format details
- Filtering - Filter by interface
