我正在尝试确定在 802.11n 网络上捕获 WLAN 帧的计算机是否能正确执行此操作。
我通过让一台计算机 (1) 下载一些文件来生成流量，并捕获生成的流量来实现这一点。另一台计算机 (2) 捕获计算机 (1) 生成的 WLAN 流量。显然，我只能在计算机 (1) 上以以太网格式保存流量（尽管它是通过我的无线接口发送的）。计算机 (2) 在链接类型为 IEEE802_11_RADIO 的无线监视器接口上接收流量。
这在一定程度上是有效的。过了一会儿，计算机 (1) 看到以下内容（任意数字）：
tshark -r /tmp/testcap -Y "eth.dst==[mac NIC] or eth.src==[mac NIC]" | wc -l
给出 3757 个数据包。
计算机（2）看到以下内容：
tshark -r /tmp/ctrlcap -Y "wlan.sa==[mac NIC] or wlan.da==[mac NIC] or wlan.ra==[mac NIC] or wlan.ta==[mac NIC]" | wc -l
给出 7234 个数据包。
人们会想象数据包的数量应该是相同的，但显然数据包的数量差别很大。
我一直在寻找这个问题的解释，然后我偶然发现了一个叫做MSDU 聚合（http://en.wikipedia.org/wiki/Frame_aggregation）。但是，如果我理解正确的话，这意味着计算机 (2) 上的 802.11 数据包数量将低于计算机 (1) 上的以太网数据包数量，但事实并非如此。
有人能解释这种行为吗？是否可以用其他方式验证我是否捕获了正确数量的数据包？
答案1
我通过让一台计算机 (1) 下载一些文件来生成流量，并捕获生成的流量来实现这一点。另一台计算机 (2) 捕获计算机 (1) 生成的 WLAN 流量。显然，我只能在计算机 (1) 上以以太网格式保存流量（尽管它是通过我的无线接口发送的）。
去引用Wireshark wiki 上有关捕获 WLAN 流量的页面：
当不处于监控模式时，适配器可能只捕获数据包；您可能必须将适配器置于监控模式才能捕获管理和控制数据包。此外，当不处于监控模式时，适配器可能会提供带有伪造以太网报头（而不是 802.11 报头）的数据包，并且可能不会提供额外的无线电层信息（例如数据速率和信号强度）。您可能必须执行与操作系统和适配器类型相关的操作才能启用监控模式；有关如何执行此操作的信息如下所述。
此处引用的关键部分是“此外，当不处于监控模式时，适配器可能会提供带有伪以太网头而不是 802.11 头的数据包”。
在计算机 (1) 上，您可能没有在监控模式下进行捕获。在该计算机上，可能或不可能在监控模式下进行捕获；WinPcap 和 Wireshark 不支持监控模式，因此如果您运行的是 Windows，则只有在您有 AirPcap 适配器（与传输数据包的 802.11 适配器分开）时，您才会看到 802.11 标头。
计算机（2）在链路类型为 IEEE802_11_RADIO 的无线监控接口上接收流量。
在那适配器，您可能正在以监视模式进行捕获。
此处 Wireshark wiki 引述的关键部分是“当不处于监控模式时，适配器可能仅捕获数据包；您可能必须将适配器置于监控模式才能捕获管理和控制数据包。” 这意味着计算机 (2) 上的捕获可能会看到非数据包，但计算机 (1) 上的捕获可能不会看到，因此计算机 (2) 上的捕获可能会有更多数据包。
例如尝试：
tshark -r /tmp/ctrlcap -Y "wlan.fc.type == 2 and (wlan.sa==[mac NIC] or wlan.da==[mac NIC] or wlan.ra==[mac NIC] or wlan.ta==[mac NIC])" | wc -l
这样你就可以消除非数据包，例如信标帧，在计算机上计算数据包时（2）。