我在ESXi 5上有一台虚拟机，作为PBX的防火墙，正在运行vyatta。 当我在任何界面上运行tcpdump时，我得到一些荒谬的数字！ 例如 4 packets captured 402 packets received by filter 210 packets dropped by kernel 4294966860 packets dropped by interface 这是从tcpdump大约3秒钟。 这在两个外部（即电缆调制解调器）接口间歇性地发生，并且很less在lan接口上发生。 这往往与丢包一致，但由于该网站是遥远的，很难看到在停机时间到底发生了什么。 重新启动后，通常不会再发生至less一个星期。 任何build议在哪里看？ 运行基于Debian挤压（6.0.5）的vyatta Core 6.5 R1。
我已经捕获了一个数据包跟踪，并希望编写一个脚本，使我能够隔离一对匹配的确认和序列数据包（没有其他方法可以过滤掉所有其他数据包），然后我可以计算出往返时间（RTT）2台计算机之间 我遇到的问题是我不能根据它们的ACK和序列号来过滤这两个数据包 它需要用tcpdump来实现，但是像awk这样的脚本语言是可以的
有人可以给我关于以下情况的想法（Linux 2.6.18-348.4.1.el5）： 在某些时候，tcpdump会显示从服务器端口发送到本地客户端的[FIN，ACK]数据包 strace日志显示在那个时候该端口的那个套接字句柄上没有执行套接字活动（strace日志正确地显示了该客户端的其余通信） 防火墙和SELinux都停止了 问题是复杂的条件，需要服务器执行networking请求Kerberos身份validation的另一个客户端连接100％重现。 什么是可能的原因，可能导致tcpdump显示strace中丢失的数据包？ 它看起来更像是服务器问题，TCP设置问题还是一些防火墙服务问题？
我正在寻找是什么导致在接口上丢弃数据包： RX packets:9064457 errors:0 dropped:4736 overruns:0 frame:0 TX packets:6388938 errors:0 dropped:0 overruns:0 carrier:0 我知道这不是防火墙，因为它甚至在它达到之前就被丢弃了。 我做了一个转储文件：tcpdump -n -s0 -w interface_errors.pcap -i eth1 然后我尝试用tshark / tcpdump来分析（重放）这个转储： tshark -r interface_errors.pcap not ip and not ipv6 and not arp 有了这个基本上我得到的是一些LLDP多播，IPX数据包从一些Windows机器。 有没有办法进一步debugging，以确定接口上的这些错误的根本原因？ 谢谢
有一个事务处理服务器（TP-Server），我的应用程序（客户端）连接到这个服务器。 我们看到一个奇怪的数据包序列，在TP-Server正在发送一个零（0）字节数据的PUSH数据包，但是这个数据包的序列号是不正确的; 序号是最后收到的字节的序号。 请看这里的TCP转储数据 http://pastebin.com/5UBXWazy TP-Server是172.250.10.10.13824。 客户端是172.11.105.5.49524。 “TP-Server”不在我的控制之下，不知道它在运行什么操作系统。 “客户端”是我在Debian Squeeze上运行的支付应用程序。 您可以看到TP-Server在下面的数据包中发送了空字节数据。 20:52:34.472819 IP (tos 0x0, ttl 59, id 51820, offset 0, flags [DF], proto TCP (6), length 53) 172.250.10.10.13824 > 172.11.105.5.49524: Flags [P.], cksum 0xe36f (correct), seq 1457045850:1457045851, ack 3097912286, win 17680, options [nop,nop,TS val 646012206 ecr 73190886], length 1 0x0000: 4500 0035 ca6c 4000 […]
为了安全起见，我们希望列出在我们的应用程序中使用的所有POST请求URI（所以我们将通过mod_security除了那些URI以外禁用POST）。 我们的想法是在完全回归testing中使用tcpdump捕获这些数据，然后wireshark获得所有URI的明确列表。 问题是，我们无法find正确的tcpdump参数来捕获HTTP POST请求（因为完整的tcpdump会快速填满磁盘，所以这是需要的）。 下面的命令工程查找，但显示GET的，POSTS和一些其他数据包（太多）： sudo tcpdump -A 'tcp port 9081 and (((ip[2:2] – ((ip[0]&0xf)<<2)) – ((tcp[12]&0xf0)>>2)) != 0)' 以下只捕获POST请求，但在wireshark中，它们显示为TCP数据包，我们无法从这些数据中提取URI（就像我们在wireshark中使用自定义值http.request.uri HTTP http.request.uri ）： sudo tcpdump -A 'tcp port 9081 tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x504f5354' 我们应该使用什么tcpdump参数来捕获HTTP POST请求（在wireshark中显示为HTTP数据包），或者我们如何从这些TCP数据包（第二个命令）中提取URI？
操作系统：Centos7 我禁用中断审核， ethtool -C eno2 rx-usecs 0, 然后使用tcpdump开始捕获该接口。 转储文件正在按预期增长。 也许一个小时后，tcpdump进程仍在运行，我可以看到接口正在接收数据包（通过ifconfig），但数据包不再被tcpdump捕获。 我停止tcpdump（显示没有丢弃）＆重新启动，但仍然没有数据包被捕获，即使ifconfig显示接口仍在接收数据包。 所以我启用了中断审核， ethtool -C eno2 rx-usecs 20, 并再次启动tcpdump …数据包被捕获。 然后，我禁用中断审核，再次启动tcpdump，并且数据包仍然被捕获。 一段时间后检查，发生同样的问题…没有数据包被捕获 – 即使接口正在接收数据包。 我注意到ifconfig显示'NIC'每次我意识到数据包不再被捕获时就丢弃了一个额外的数据包。 任何帮助将是伟大的。 谢谢。
在同一台机器上通过UDP广播进行通信的一组守护进程应用程序让我很难捕获它们的stream量。 networking接口为eth0，configuration为静态IP，没有连接电缆，连接断开： # ip addr show eth0 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000 link/ether 00:60:e0:59:7a:80 brd ff:ff:ff:ff:ff:ff inet 192.168.0.1/24 brd 192.168.0.255 scope global eth0 inet6 fe80::260:e0ff:fe59:7a80/64 scope link valid_lft forever preferred_lft forever 应用程序发送UDP广播消息到192.168.0.255，我不能改变这一点。 这些消息分别到达另一个守护进程，我可以通过阅读它们的debugging日志来validation。 这与链接状态无关。 但是，只要接口链路断开，我无法用tcpdump来嗅探这些软件包。 如果我插入电缆，我会看到包裹通过。 如何将这些软件包捕获到pcap文件中，而无需插入电缆（这在计划的实验设置中是不可能的）。
我需要使用不同的参数/选项运行2个并发的tcpdump命令。 为什么？ 因为我们写了一些与以下选项兼容的漫长脚本： tcpdump -ixenbr0 -s 400 -n -A 'port sip || (tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420) || (tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x504f5354 && tcp[((tcp[12:1] & 0xf0) >> 2) + 4:1] = 0x20) || (tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x48545450 && tcp[((tcp[12:1] & 0xf0) >> 2) + 4:4] = 0x2f312e31 […]
在使用Microsoft Lync Client（Mac OS X）进行应用程序共享期间，带有RST标志的TCP ACK从应用程序端发送到针对TCP零窗口数据包的Lync端，并且调用被取消。 图像链接。 供参考： My Application End: 172.16.6.106:55848 Lync End (Remote): 172.16.14.58:18627 Environment: My Application End: Centos/Linux Lync End: Mac OSX Shared Over Wifi.