我有一个问题，我试图追查，我相信问题是物理networking硬件。 我已经阅读了pktcap-uw命令中的VMWare文档，我知道我可以使用它将stream量转储到一个可以用Wireshark查看的文件，但是我得到的pcap有点奇怪。 看文档，我想看到端口80上的两个IP地址（IP A和IP B）之间的stream量，我可以使用–ip开关，但是如果我有–ip A –ip B，那是一个布尔AND或布尔OR。 tcpdump允许你指定OR或AND，并使用圆括号做一个完整的布尔expression式。 对于pktcap-uw还有–dstip和–srcip，但是如果使用tcpdump equivelant，通常只能获得一半的对话。 什么是正确的语法？
我们一直试图抓住一个奇怪的问题，我们可以在solaris 10上从Apache 2.2.19上find一个页面，并且一些请求的排列可靠地花费各种固定的时间来响应。 它看起来是基于TCP套接字的closures，从客户端上的tcpdump开始，我们通常会看到在填充TCP窗口的服务器与最后一次响应之间的暂停，以及最后一个数据块与FIN从服务器。 所以在networking上它只是挂起了HTTP响应的中间传输，但是服务器上的netstat在FIN_WAIT_1中显示了一个套接字。 我们不能在服务器上做一个tcpdump来澄清，但是在我们看来，操作系统已经把TCP对话交给了硬件，所以相信它已经开始四处closures了，但是NIC从来不放这个包，数据包（可能是1或2 @ 1500字节和400或其他）。 这就像我们可以绘制的一样清晰的图像，除了最近的一个testing，我们做了一个惊人的…一个64076字节的文件由apache提供 – 最后一个包的432ms延迟。 我们给文件添加了一个字符，这导致了一个额外的数据包被创build，53个字节也包含了FIN，而不是我们在略小的文件上看到的空的52字节FIN，延迟的那个文件。 这个额外的数据包的存在可靠地改变了FIN对话的发生，并使对话从几乎半秒到几毫秒。 最常见的是在调查的整个过程中，这个延迟时间为4.6秒，我们再次看到窗口大小在波动，SACK在需要的时候返回到Apache，但是最后一个窗口的时间已经满了，持续46秒，然后回到最后2或3kb的数据，以及Solaris认为它发送的FIN以前。 我们的tcpdumps在F5 BigIP上，所以有一个ASICstream量以及一个Cisco 6509（仅限L2），但是我们在相邻的Solaris机器上执行wget时看到的是相同的用户体验，所以不要不相信BigIP正在做的任何黑魔法。 但是这一切都混淆了窗口大小和MSS和喜欢的混淆，但如果这听起来很熟悉任何人，我们都耳朵！
这里是接口的configuration： ＃ifconfig virbr0 virbr0：flags = 4355 mtu 1500 inet 192.168.11.1networking掩码255.255.255.255广播255.255.255.255 ether 52：54：00：99：e3：0d txqueuelen 0（以太网） RX数据包0字节0（0.0 B） RX错误0丢弃0超限0帧0 TX分组0字节0（0.0 B） TX错误0丢弃0超载0载波0碰撞0 ＃ip链接显示virbr0 13：virbr0 @ NONE：mtu 1500 qdisc noqueue状态LOWERLAYERDOWN模式DEFAULT link / ether 52：54：00：99：e3：0d brd ff：ff：ff：ff：ff：ff 我能ping通，build立TCP连接等到192.168.11.1，但tcpdump报告 捕获0个数据包 filter收到的0个数据包 内核丢弃了0个数据包 UPDATE 我发现如果将地址分配给veth接口，将其放入networking名称空间，然后将veth对的另一端连接到virbr接口，所有数据包将显示在virbr接口上的tcpdump上。 但是原来的问题依然存在。
我正在经历一个CISCO防火墙和连接到它的Docker主机之间的奇怪交互：CISCO定期将我的主机标记为SYN攻击者，并closures我的以太网端口。 我一直在运行tcpdump主机过滤SYN数据包，这是我已经遇到的模式的一个例子： 20:45:53.863232 In 00:0c:29:67:9f:5b ethertype IPv4 (0x0800), length 76: 172.16.23.92.34272 > 172.16.23.102.3314: Flags [S], seq 2717143176, win 29200, options [mss 1460,sackOK,TS val 670292160 ecr 0,nop,wscale 7], length 0 20:45:53.863268 Out 02:42:ed:33:9c:27 ethertype IPv4 (0x0800), length 76: 172.16.23.92.34272 > 172.17.0.8.3306: Flags [S], seq 2717143176, win 29200, options [mss 1460,sackOK,TS val 670292160 ecr 0,nop,wscale 7], length […]
我在这个领域是新的。 我被要求在我的networking课程中使用tcpdump捕获ICMP目标不可达消息。 所以我试图捕获一个ICMP目标不可达的消息，其目标IP是dst 172.17.1.8。 我的代码如下： sudo tcpdump -c 1 'icmp[0] = 3' and dst 172.17.1.8 它显示“tcpdump：详细输出抑制，在eth0上使用-v或-vv完全协议解码，链接型EN10MB（以太网），捕获大小为96字节” 问题是，为了捕获不可达消息，一些数据包需要首先发送到这个IP地址。 我已经在代码之前尝试了ping 2包到目的地。 但是，代码将不会执行，直到ping完成。 所以仍然不能通过使用tcpdump收到无法访问的消息。 谢谢。
我在镜像端口上运行tcpdump，当我使用简单的tcpdump命令时，它显示了VLAN ID： tcpdump -i eth1 -n -e 22:02:53.308715 78:31:c1:c6:c8:9e (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 114: vlan 10, p 0, ethertype IPv4, redacted-MBP.home.redacted.net.netbios-ns > 192.168.10.255.netbios-ns: NBT UDP PACKET(137): REFRESH(8); REQUEST; BROADCAST 但是，如果我尝试过滤VLAN 10 ID，那么它不显示任何数据包： tcpdump -i eth1 -n -e '(vlan 10)' 我究竟做错了什么？
我正在寻找一种方法来捕获整个tcpstream，但只有当1）错误发生（如RST）时，将其保存到文件2）不确定如果可能的话 – 分析HTTP响应，如果HTTP 500发生存储是一个stream。 networkingstream量很高，所以我想避开整个stream量。 目前的tcpick可能是这样的： 例： 在唯一文件（客户端和服务器混合在一起）中logginghttp数据： # tcpick -i eth0 "port 80" -wRub 然后，我可以分析保存的文件，并删除正确的 – 但它是一个矫枉过正的：/
我有一个DigitalOcean VPS实例，其出站stream量performance奇怪，在7天内线性增长。 我试图找出通过tcpdump发生了什么，但要说实话，我不知道我应该找什么，通过做tcpdump port not 22这里是我能够交通types的一个片段看，这对我来说很正常： 15:48:10.638709 IP ubuntu-512mb-nyc3-01.http > client.yota.ru.57498: Flags [S.], seq 262596971, ack 2836813416, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0 15:48:10.641314 IP client.yota.ru.57493 > ubuntu-512mb-nyc3-01.http: Flags [P.], seq 772:1106, ack 41341, win 260, length 334: HTTP: GET /js/pathseg.js HTTP/1.1 15:48:10.641578 IP ubuntu-512mb-nyc3-01.http > client.yota.ru.57493: Flags [.], seq 41341:44061, ack 1106, […]
我试图解决这个问题已经很长时间了，但是也尝试了在这个网站上find的所有build议，我没有解决问题。 我在CentOS服务器上安装了OpenVPN。 这台服务器也可以使用squid代理。 安装进行的很好，当我启动服务，我可以在我的ifconfig输出中看到tun0设备： tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.8.0.1 PtP:10.8.0.1 Mask:255.255.255.0 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) 但是，当我尝试从客户端连接，我得到这个日志（错误）： Thu Dec 29 17:02:17 2016 us=212571 OpenVPN 2.3.14 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] […]
突然之间，我没有能够ssh到任何机器。 我认为这是我的路由器/networking问题，我尝试了不同的networking，但结果是一样的。 我在服务器和客户端上都使用了tcp dump，发现校验和不正确。 客户端在MacOS 10.12.6上，服务器运行Ubuntu。 下面是服务器和客户端的TCP转储。 服务器 sudo tcpdump -n -vvv -n dst host 59.90.xxx.xxx 06:51:41.285561 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) 10.128.x.xx.22 > 59.90.xxx.xxx.54341: Flags [S.], cksum 0xb1fb (incorrect -> 0x0b7d), seq 1875710046, ack 3542782445, win 28160, options [mss 1420,sackOK,TS val 1107257724 ecr […]