问题标签 [packet-loss]

我正在使用 pfsend 以非常高的速度将流量从主机 1 发送到主机 2。

在 host2 端，我使用 pfcount 来获取有关丢弃数据包和接收数据包数量的一些统计信息。

我正在从 host1 运行 pfsend，如下所示：pfsend -z -n 0 -i eth2 -m MAC@

的输出结果pfsend如下：

在host2端，pfcount的输出如下：

任何人都可以为我提供一些见解？是否与连接两台主机的交换机有关？或与 Linux 网络内核相关的东西？问候。

I have an android smartphone connecting via WIFI to an embedded AP. I am sniffing WIFI traffic with a laptop running Tshark on Linux. I am transferring small (234 bytes) TCP packets 5 times every 100ms, followed by 500ms with no data. Periodically, packets will be ignored, forcing retransmission. Some level of packet retransmission is expected when transferring data over TCP sockets, but this is excessive. Especially so because the packets are received by the sniffer without problem (i.e., there is no ‘in flight’ corruption), AND subsequent re-transmitted packets are also ignored (dropped) by android.

Please note: When I say ‘IGNORED’, I mean I don’t see any acknowledgement, either from the receiving radio (802.11 ACK), or from receiving TCP stack (TCP ACK) in the Wireshark trace. In the image below, data packet 599 is acknowledged immediately, while the next data packet (606) is ignored, as are the next four re-transmissions (607-610).

Wireshark log

This DOES NOT HAPPEN with the same APK running on Android v4.x (4.0.4 & 4.2.2 tested), nor on a similar application running on iOS. In both cases, there IS the expected dropped TCP packet, followed by a retransmission, but that is almost always ACK’ed immediately.

Since there is nothing special about the packets I am transferring, and seamless retransmission of TCP packets is expected to some extent to address packet loss, I suspect that many applications are suffering this same issue, but simply accept the reduction in overall transfer rate, attributing the slower transfer to “WIFI congestion”.

In my case, the WIFI hardware/firmware solution (provided by a third party) chokes up with excessive TCP backlog occurs. They have a new solution with a bandaid fix that appears to help with recovery, but that does not resolve the problem of hardware already in the field.

I believe something has changed under android 5.x such that the radio is periodically either shut down or shifted off-channel. Since it appears to happen periodically, I though this might be due to channel scanning (with the expectation that any packets dropped during the scan interval would be recovered by retransmissions when the radio returned). I was unable to find a clear definition of Android channel scanning behavior (I have a separate post on that).

When failed, retransmission will occur in bursts of 4 or 5 packets with several milliseconds in between, then nothing for 1 second, followed by another burst. Usually, retransmitted packets are ignored for some time (could be multiple seconds). Eventually, a retransmission packet is acknowledged, and transmission continues with the next packet.

I noted that there was also periodic DNS probing occurring (list of URLs that are periodically probed via DNS queries is below). Some may be installed applications, while others will be operating system (for instance, ‘connectivitycheck.android.com’ will likely be used to verify if the AP actually provides internet connectivity, which it does NOT in my case).

The px.demdex.net entry drew my attention, as I had no idea who this represented. It turned out to be Adobe. Since there were clearly bits of code actively probing that I had no knowledge of, and to ensure my issue is purely an Android issue, I factory reset the Nexus 4 smartphone, and declined any initialization options that might be implicated in WIFI comms issues (such as Google Location services, allow to use WIFI even when off, etc.). TCP packets are still dropped.

On the android side, I have: - Set Location to “Device Only” (GPS) - Disabled WIFI “Scanning always available” - Acquired a “WIFI_MODE_FULL_HIGH_PERF” lock within the app whenever the socket is open. - Socket is opened when app starts communication, and held open until app closes. If no packets appear for some time (currently 3 seconds), app closes socket & opens a new one in an attempt to force comms to re-establish.

I discovered the “setAllowScansWithTraffic()” function of IWifiManager, which sounds like it would give me the explicit control of scanning (to remove that possibility from the list), but it seems implementing this would be difficult, and could not be part of my app (?). I believe IWifiManager provides a stub for android implementers to build their own WIFI manager (OS) service, and it is not intended to be used at the app level.

I’d appreciate any input / suggestions.

UPDATE

While chasing the "channel scanning" possibility, I logged ACK packets on WIFI channel 3 with my packet sniffer, while the hardware under test was operating on WIFI channel 8. This may explain the missing ACKs - they are sent on the wrong WIFI channel. I've opened an Android bug

显然，当我使用 iptables 在发送方 A 的输出中丢弃数据包时，A 的 TCP 实例会重新发送它们，因为它永远不会从接收方 B 获得丢失数据包的 ACK。最后，根据丢弃的概率（>0），来自 A 的所有数据都可能到达接收者 B。因此，丢包会导​​致网络延迟和网络上正在发送的 TCP 段的增加。使用 ipfw 我会面临同样的情况吗？数据包是在 TCP 状态机之前还是之后处理的？我能得到的所有信息，即使是 dummynet 官方页面，也不清楚，即使是 googletechtalk。

我提前感谢您的帮助。

我正在寻找一种可靠的方法来在 linux 中丢弃数据包，就好像你的网络不好一样。查看堆栈溢出（和互联网）似乎有两个很好的可能性在这个答案中指出。这两个都应该有 5% 的丢包率。

1. tc qdisc change dev eth0 root netem loss 5%
2. iptables -A INPUT -m statistic --mode random --probability 0.05 -j DROP

但是，netem 文档说明了以下内容：

当在本地（不在网桥或路由器上）使用 loss 时，会将 loss 报告给上层协议。这可能会导致 TCP 重新发送并表现得好像没有丢失一样。在测试协议对丢失的响应时，最好在网桥或路由器上使用网络

根据我（非常有限）的理解，两种解决方案（netem和iptables）都使用相同的解决方案，因此会遇到相同的缺点。

有什么方法可以准确地模拟丢弃的数据包，而无需在交换机或网桥上运行程序？由于 CRC 将不得不重新请求它们，因此破坏数据包是否是一种“丢弃”它们的穷人方式？

谢谢你。

我们正在使用licode MCU 将录制的视频从 Google Chrome 流式传输到服务器。没有第二个谷歌浏览器实例来处理反馈，服务器必须这样做。

我们遇到的一件事是当丢包丢帧并且视频不同步时。这会导致视频质量非常差。

在 ExternalOutput.cpp 中有一个地方可以检测到当前接收到的数据包没有单调递增。在这里您可以看到它丢弃了当前帧并重置了搜索状态。

我想知道如何修改它，以便它可以从这个数据包丢失中恢复。在当前序列号上提交 NACK 数据包是解决方案吗？我还读到有一种谷歌浏览器提交 RED 数据包（冗余）以处理数据包丢失的模式。

客户端首先发送文件名，服务器用该名称创建一个文件以将数据写入其中。

文件名是从命令参数转换而来的，格式类似于“file.txt”。问题是每次我转换“.txt”以外的文件名时都会发生错误。

我在丢包的情况下测试代码，概率为 15%。如果发生丢失，整个数据包将消失，不会留下任何部分。这就是为什么我认为文件名每次都丢失的原因。如果文件名包没有丢失，文件将以正确的名称打开。所以我认为它至少每 10 次会收到一个合适的，但它从来没有。

我猜这些变量没有任何其他问题。当不假设丢包时，它按我预期的方式工作。我从 strlen(argv[3]) + 1 更改了第三个参数，但没有任何改变。

我可以通过修改代码来解决这个问题吗？

有时我的 DSL 路由器会以这种奇怪的方式出现故障：

可以看出，错误代码$?是0. 所以我不能简单地检测命令是否失败，因为任何脚本的输出都不会产生错误。

检测数据包丢失的正确方法是什么？
我需要解析输出grep还是有一些更简单的方法？

我们想开发一个桌面工具来检查服务器和客户端之间的数据包丢失。工具将在客户端机器上运行。客户端打开了 TCP 和 UDP 端口 4172，并且可以在该端口上进行通信。是否可以识别双向数据传输？有没有 .net api 可以做到这一点？

我检查了一些工具，如Pcap.Net和WinPcap

我编写代码是为了处理接收 UDP 数据包。数据包长度相同（120 字节），每秒大约有 1,000 个数据包进来。简单地说，我的代码是这样的。

当我编写此代码时，我希望 recv() 函数此时返回 UDP 套接字缓冲区中的每个字节，但是，即使缓冲区中有更多字节，它似乎每次只返回一个数据包（120 字节） . 所以现在我遇到了丢包。我知道有很多其他方法可以解决这个问题，但是，现在一次读取 UDP 缓冲区中的所有现有字节对我来说是最简单的方法。那么，有没有办法一次读取 UDP 缓冲区中的所有字节？

提前致谢

我和我的朋友有相同类型的互联网连接 (ADSL 2+)，我们获得相似的速度 (10 down 1 up) 和 ping，但是当我们都尝试连接到相同的 IP 时，我们得到不同的 ping。我们正在尝试从澳大利亚连接到加拿大的服务器（158.69.135.112），我得到了更高的 ping，但如果我们都 ping 美国或英国的 IP，我们会得到非常相似的 ping。这是我们的跟踪路由结果。

我的追踪路线

朋友的踪迹

我朋友的 ping 比我少了 100 多毫秒，traceroute 有问题吗？我注意到在第一个 traceroute 的第 12 和第 13 跳之间有一个很大的跳跃，这可能是一个问题吗？任何帮助表示赞赏！