When running tcpdump with -i any to monitor multiple network interfaces simultaneously, the default output doesn't indicate which specific interface captured each packet. This becomes particularly problematic in environments with numerous interfaces where traffic analysis requires knowing the ingress point.

The standard tcpdump implementation (as of version 4.99) doesn't include interface information in its output when using -i any. The packet metadata shows:

15:30:45.123456 IP 192.168.0.1 > 10.0.0.2: ICMP echo request, id 1234, seq 1, length 64

Notice the missing interface identifier that would tell us whether this came through eth0, wlan0, or another interface.

1. Using tshark (Wireshark CLI)

The more robust solution is to use tshark which preserves interface information:

tshark -i any -f "host 192.168.0.1" -T fields -e frame.interface_name -e ip.src -e ip.dst

Sample output:

eth0 192.168.0.1 10.0.0.2
wlan0 192.168.0.1 10.0.0.3

2. nfdump Alternative

For netflow analysis, nfdump can provide interface information:

nfdump -r nfcapd.file -o extended -s record/bytes | grep 192.168.0.1

3. Custom Wrapper Script

When you must use tcpdump, create a wrapper that captures per-interface:

#!/bin/bash
INTERFACES=$(ls /sys/class/net/ | grep -v lo)
for IFACE in $INTERFACES; do
  tcpdump -i $IFACE -n "host 192.168.0.1" -l | sed "s/^/$IFACE: /" &
done
wait

When dealing with 50+ interfaces:

• Use BPF filters (-f) to minimize processing overhead
• Consider sampling (-c) for high traffic volumes
• For critical systems, use dedicated monitoring interfaces with port mirroring

For large-scale deployments:

# Using Elastic Stack with Packetbeat
packetbeat.interfaces.device: any
packetbeat.flows:
  timeout: 30s
  period: 10s
output.elasticsearch:
  hosts: ["monitoring-server:9200"]

---

When running tcpdump on systems with multiple network interfaces (especially in gateway or monitoring scenarios), a common pain point emerges: the captured packets don't indicate which physical interface they arrived on. This becomes critical when you need to:

• Diagnose asymmetric routing issues
• Verify firewall interface bindings
• Monitor traffic distribution across interfaces

The standard tcpdump implementation (even with -i any) doesn't include interface information in its output. For example:

# tcpdump -i any -n host 192.168.0.1
12:34:56.789 IP 192.168.0.1.12345 > 10.0.0.2.80: Flags [S], seq 123456789, win 64240

Notice the missing interface identifier that would tell us whether this came through eth0, eth1, etc.

1. Using tcpdump with -D and Parallel Capture

For systems with many interfaces, we can script parallel captures:

#!/bin/bash
INTERFACES=$(tcpdump -D | grep -v 'any' | cut -d' ' -f2)
for IF in $INTERFACES; do
  tcpdump -i $IF -n host 192.168.0.1 -w $IF.pcap &
done

This creates separate capture files per interface, preserving the origin information.

2. Using dumpcap (Wireshark Suite)

The dumpcap utility (part of Wireshark) includes interface information:

# dumpcap -i any -f "host 192.168.0.1" -w combined.pcap
# tshark -r combined.pcap -T fields -e frame.interface_name -e ip.src

3. Custom BPF Filtering

For advanced users, BPF can help identify interface-specific patterns:

# tcpdump -i any -n '(host 192.168.0.1) and (vlan and incoming)'

For environments with 50+ interfaces, consider:

• PF_RING: High-performance packet capture with interface metadata
• nProbe: Specialized for interface-aware traffic analysis
• Zeek (Bro): Network monitoring framework with native interface logging

Here's a complete solution using tcpdump and jq for JSON output:

#!/bin/bash
# Get all interfaces except loopback
IFACES=$(ip -o link show | awk -F': ' '!/lo:/{print $2}')

# Start parallel captures
for IF in $IFACES; do
  tcpdump -i $IF -n -j adapter_unsynced -s 0 -w - host 192.168.0.1 | \
  tshark -r - -T json | jq '.[].interface.name' >> capture.log &
done