tcpdump本身不生成流向图，需结合多接口抓包、lo比对、内核协议栈判断及网络配置分析，通过时间戳、TCP序号和IP头TTL等人工还原封包路径。
tcpdump 本身不生成「流向图」，它只输出原始数据包的时间线记录。所谓“封包流向图”，是人对网络路径、协议栈处理顺序、进出接口等逻辑的抽象还原，不是某个命令一键画出来的。
你真正需要的，是结合 tcpdump 抓包 + 内核数据路径认知 + 网络拓扑判断，自己拼出流向。下面分几个实操关键点说清楚。
怎么用 tcpdump 定位封包经过哪些接口
封包“流向”的第一层就是物理/逻辑接口进出顺序。同一台机器上，tcpdump -i eth0 和 tcpdump -i lo 捕到的包，时间戳和内容能告诉你包是否经过了网卡、是否被路由转发、是否进了本地协议栈。
- 在
eth0上看到某 IP 包进来，但在lo上没看到对应响应 → 包可能被丢弃、NAT 或防火墙拦截，没进本地栈 - 在
lo上看到请求（如 curl localhost:80），但eth0上没看到外发 → 服务没往外连，或走的是 Unix socket（tcpdump捕不到） - 同时在
eth0和eth1上捕到相同连接的包 → 这台机器很可能在做路由或 NAT，需检查sysctl net.ipv4.ip_forward
为什么 tcpdump -i any 不能代替多接口监听
-i any 是把所有接口的包汇总输出，但它会隐藏关键信息：哪个接口收、哪个接口发。比如一个 TCP 连接，SYN 来自 eth0，ACK 却从 br0 发出 —— -i any 会把这两包混在一起，看不出转发路径。
- 真实环境（尤其是容器、KVM、iptables DNAT 场景）中，包经常跨多个虚拟/物理接口流转
-
-i any输出里没有接口字段，你无法区分src 192.168.1.100是从哪块网卡进来的 - 正确做法：对每个可疑接口单独跑
tcpdump -i $IFACE -nn -c 50 port 80，再比对时间戳和 seq/ack 号
怎么判断封包是否被内核协议栈处理（而非直接转发）
关键看 tcpdump 是否在 lo 接口捕到该连接的包。Linux 内核有个隐式规则：只要目标 IP 是本机任一接口地址（包括 127.0.0.1），包就会进入本地协议栈；否则走转发流程。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 执行
ip addr show列出所有配置的 IP，再用tcpdump -i lo host $IP看是否有匹配包 → 有 = 进本地栈，无 = 被转发或丢弃 - 若目标 IP 是本机但
lo没抓到，检查net.ipv4.conf.all.arp_ignore和rp_filter，它们可能导致包被静默丢弃 -
tcpdump -i eth0 -n 'ip[12:4] = 0xc0a80164'（十六进制匹配 192.168.1.100）可绕过 host 解析限制，确认原始 IP 是否到达网卡
流向图真正的复杂点不在工具，而在上下文
你抓到的每一行 tcpdump 输出，背后都依赖具体网络配置：路由表、iptables 规则、conntrack 状态、bridge 设置、namespace 隔离……这些不会出现在包里，但直接决定流向。
比如一个 HTTP 请求从容器发出，tcpdump -i docker0 看到 SYN，-i eth0 也看到 SYN，但中间没看到 SNAT 日志？那得查 iptables -t nat -vnL POSTROUTING，而不是怪 tcpdump 没画图。
别指望单个命令给出图形化路径 —— 流向是推理结果，不是渲染产物。最可靠的“图”，是你在不同位置（宿主机、容器 netns、交换机镜像端口）分别抓包后，用时间戳+TCP号+IP头 TTL 对齐出来的链条。
