问题[tcpdump](unix)

我正在为我们的 CAN 总线协议编写 Wireshark 解析器，我注意到 tcpdump 捕获了两次 CAN 帧，并且其输出与 candump 程序不同。

例如，当我执行以下命令时

$ cansend vcan0 123#R
$ cansend vcan0 123#22

tcpdump 显示以下输出

$ tcpdump -i vcan0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vcan0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
00:19:18.372611
    0x0000:  2301 0040 0000 0000 0000 0000 0000 0000  #..@............
00:19:18.374097
    0x0000:  2301 0040 0000 0000 0000 0000 0000 0000  #..@............
00:19:33.605064
    0x0000:  2301 0000 0100 0000 2200 0000 0000 0000  #.......".......
00:19:33.610799
    0x0000:  2301 0000 0100 0000 2200 0000 0000 0000  #.......".......

但 candump 显示正确。

$ candump vcan0
  vcan0  123   [0]  remote request
  vcan0  123   [1]  22

tcpdump 版本

$ tcpdump --version
tcpdump version 4.9.2
libpcap version 1.9.0-PRE-GIT (with TPACKET_V3)

我有两个问题

1. 这个问题有解决办法吗或者在新版本中已经解决了吗？
2. 如果不需要或需要更新版本，我可以在 Wireshark 远程捕获中使用 candump 吗？我知道我可以预览 candump 日志，但我更喜欢使用远程捕获进行实时检查。

我如何过滤 tcpdump 输出（普通屏幕，不是 -w）以便只看到带有标志 [P] 的行？

在 Debian 12 上运行 tcpdump 4.99

在同一子网中的两个节点之间运行时，我遇到了以下问题traceroute。这样做是为了测试这两个节点之间的网络连接是否可靠。一家知名数据库供应商的支持团队建议我们使用这种方法。

运行该命令时： traceroute -s 10.1.3.205 -r 10.1.3.210 随机有数据包未收到，并且没有报告 RTT：

traceroute to 10.1.3.210 (10.1.3.210), 30 hops max, 60 byte packets
 1  10.1.3.210 (10.1.3.210)  0.152 ms  0.064 ms *

相反，运行带有 ICMP: 选项的 traceroutetraceroute -I -s 10.1.3.205 -r 10.1.3.210是可靠的，并且不会发生丢失数据包的情况。

在我们的环境中，多个 Linux 系统上都发现了同样的问题，这些系统具有不同的补丁级别、不同的 traceroute 版本，无论系统是虚拟机还是物理系统。

为了简化和更容易读取 tcpdump，我尝试使用以下命令：

for i in {1..10}; do traceroute -s 10.1.3.205 -r 10.1.3.210 -n 1 -m 1 -q 1; done

输出如下：

for i in {1..10}; do traceroute -s 10.1.3.205 -r 10.1.3.210 -n 1 -m 1 -q 1; done
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.203 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.067 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.067 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.071 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.067 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.075 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  *
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.142 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.067 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.054 ms

每 7 个数据包都没有响应，这种情况是可以重现的。现在，支持团队最终确定我们的网络设置中存在此数据包丢失问题。

运行相同的循环，延迟 1 秒，所有 10 个数据包均被发送和接收：

for i in {1..10}; do traceroute -s 10.1.3.205 -r 10.1.3.210 -n 1 -m 1 -q 1; sleep 1; done

我有点怀疑这种测试网络可靠性的方式是否正确，因为通常使用 traceroute 来监控路由连接上的网络路径。

我尝试使用 SAP 进行了几个小时的网络连接测试niping，没有发现丢失的连接。

那么我是否遗漏了什么明显的内容？使用traceroute这种方式是否是测试网络可靠性的可行方法？

我想从第三台主机查看两台主机之间的流量，我的网络上都有我在第三台主机上执行此操作：

ip link set eth0 promisc on

tcpdump -vv -i eth0 -xX host 192.168.0.2 and host 192.168.0.38 and not stp

我在 192.168.0.2 上进行了 ssh，从 192.168.0.2 我 ping 192.168.0.38，而不是在我的终端上看到 udp 数据报，我看到了这个

tcpdump -vv -i eth0 -xX host 192.168.0.2 and host 192.168.0.38 and not stp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
^C
0 packets captured
8 packets received by filter
0 packets dropped by kernel

为什么？

我尝试指定 src 和 dst ..

  tcpdump -vv -i eth0 -xX src host 192.168.0.2 and dst host 192.168.0.38 and not stp

但没有任何改变。

当我需要使用 捕获一些数据包tcpdump时，我使用如下命令：

tcpdump -i eth0 "dst host 192.168.1.0"

我一直认为dst 主机 192.168.1.0部分称为 BPF，Berkeley Packet Filter。对我来说，这是一种过滤网络数据包的简单语言。但是今天我的室友告诉我，BPF 可以用来捕获性能信息。根据他的描述，它就像perfmonWindows上的工具。这是真的吗？它与我在问题开头提到的 BPF 相同吗？

tcpdump 手册显示：

-n     Don't convert addresses (i.e., host addresses, port numbers, etc.) to names.

我n在 tcpdump 命令中看到了 double：
https ://danielmiessler.com/study/tcpdump/

tcpdump -nnSX port 443

tcpdump 命令中的双 n 是什么意思？

这些程序之间的相关性是什么？ tcpd和inted / rinetd非常古老，但尽管如此，它们仍然存在于许多发行版中……为什么？hosts.allow而且tcpd之间也存在相关性hosts.deny，但我注意到即使没有安装tcpd ，这些文件也存在......（尝试使用命令dpkg也注意到这与没有包不对应）......好吧.. a混乱。谁帮我澄清一下？hosts.allow/deny

谢谢

我正在尝试捕获在 mininet 网络仿真框架中运行的一组进程的 tcpdump。

Mininet 的工作原理是将每个进程/进程集放入其自己的网络命名空间，然后通过veth设备连接每个网络命名空间。

我正在尝试做的是使用 tcpdump 来获取随时间变化的带宽使用情况。然而，这不是难点。

我期望的是我可以做sudo tcpdump host 10.0.0.1（10.0.0.1作为模拟节点之一）来捕获命名空间之间的所有流量。但是，我正在0捕获数据包。

我以前做过这个工作，但我不记得是怎么做到的。Mininet 在 mininet docker 容器中运行，带有net=host.

我必须捕获从主机 A 发送到主机 B 的任何 UDP 端口的所有 UDP 数据包。以下如果在主机 B 上运行，则不起作用。

$ sudo tcpdump -i eth0 -SX udp src <hostA>
tcpdump: 'udp' modifier applied to host

实现相同目的的正确命令行是什么？

我有两个用 veth 对连接的 linux 容器。在一个容器的 veth-interface 上，我设置了 tc qdisc netem 延迟并将流量从它发送到另一个容器。如果我使用 tcpdump/wireshark 观察双方的流量，可以看出发送方和接收方的同一数据包的时间戳不会因所选延迟而有所不同。

我想更详细地了解 libpcap 将时间戳放入对应于 tc qdisc 的出口流量。我在互联网上搜索了一个方案/图像，但没有找到。我找到了这个主题（wireshark 数据包捕获点），但它建议通过多一个容器/接口来引入间接性。在我的情况下，这不是一个可能的解决方案。有没有什么方法可以解决这个问题，而不是引入额外的中间接口（即不改变拓扑），并且只通过在已经给定的 veth-interface 上记录但以可以看到延迟的方式来解决这个问题？

更新：

我太快了，所以弄错了。我的解决方案（与@AB 的答案的第一个变体相同）和@AB 的 IFB 解决方案（我已经检查过）都不能解决我的问题。a1-eth0问题是拓扑中发送方接口的传输队列溢出：

[a1-br0 ---3Gbps---a1-eth0]---100Mbps---r1---100Mbps---r2

我太快了，只检查了a1-eth0和 router之间链接的延迟 10ms r1。今天我试图让延迟更高：100 毫秒、200 毫秒，结果（我得到的每个数据包延迟和速率图）对于上面的拓扑和普通拓扑开始有所不同：

[a1-eth0]---100Mbps---r1---100Mbps---r2

所以不，当然，对于准确的测试，我不能有额外的链接：Linux 桥、这个 IFB 和任何其他第三方系统都没有引入。我测试拥塞控制方案。我想在一个特定的拓扑中做到这一点。而且我不能仅仅为了绘图而改变拓扑——我的意思是，如果我的速率和延迟结果/图同时发生变化。

更新 2：

所以看起来解决方案已经找到了，如下图所示（NFLOG解决方案）。

更新 3：

这里描述了 NFLOG 解决方案的一些缺点（大的 Link-Layer 标头和错误的 TCP 校验和，用于零负载的出口 TCP 数据包），并提出了一个更好的解决方案，使用 NFQUEUE 没有任何这些问题：零长度出口数据包的 TCP 校验和错误（使用 iptables 捕获）。然而，对于我的任务（测试拥塞控制方案），NFLOG 和 NFQUEUE 都不适合。正如同一个链接所解释的，当从内核的 iptables 捕获数据包时，发送速率会受到限制（这就是我的理解）。因此，当您通过从接口捕获（即定期）在发送方进行记录时，您将获得 2 GB 转储，而如果您通过从 iptables 捕获在发送方进行记录，您将获得 1 GB 转储。大致说来。

更新 4：

最后，在我的项目中，我使用了我自己的答案中描述的 Linux 桥接解决方案。