（虽然我想到了，首先：这与加密没有任何关系——否则你会看到流量，肯定是加密的，但你仍然会看到“东西”通过。）
只有在多播或广播的情况下，您才能看到进出此设备的流量。
这是因为 AP（接入点）和 STA（站）之间的通信方式在 Wi-Fi/802.11 中发生。在 802.11 级别，假设 STA A 和 STA B 之间的每个“单播”[0] 通信实际上不直接从 STA A 到 STA B：首先有一个来自 STA 的 802.11 帧A发给AP，AP再发给STA B等
因此，如果您的设备发送一些多播/广播流量，您会看到这一点 - 但只有这一点（响应多播/广播通常是单播）。
您可能会看到来自该站点的某些流量例如是 ARP 请求 - 这是广播，因此 AP 的工作是将其发送到其所有 STA。你会看到这些。
Wi-Fi 环境中此类流量的另一个非常常见的示例是 STA 是 DHCP 客户端。然后您将看到 DHCP 请求。在典型情况下，此 STA 将在与 AP 关联/验证后立即发出此类 DHCP 请求。在这种情况下，从您的 PC 上运行 wireshark（这是来自同一 AP 的另一个 STA），您将看到 DHCP 请求，因为它是广播的，并且 AP 将分发它（我故意不使用术语“转发”）。但通常不多，因为在典型情况下 AP 也是 DHCP 服务器，因此有关此 DHCP 过程的其余通信将直接发生在 AP 和所述 STA 之间。但是，您还应该看到由上述 DHCP 客户端 STA 发出的 ARP 请求（见上文），以检查 DHCP 服务器刚刚提供的 IP 确实是免费的，因为这就是 DHCP 协议的要求[1 ] 如果正确实施。
您可能看到的另一种不太常见但并不罕见的流量是固有广播的流量：
- ICMPv6 邻居请求/广告（来自 STA 运行
具有双 IP 堆栈的现代操作系统）
- Dropbox LAN 发现协议（哦，这可能会很吵
普通 PC STA）
- UPnP SSDP（即端口 1900 上的 UDP 多播）
- ...可能还有更多，具体取决于运行的应用程序
STA（当然也可以是 AP，例如 DHCP）。
这是在 AP/STA 设置中使用 Wi-Fi/802.11 时理解和永远不会忘记的基本点：所有通信都通过 AP，从不直接在 STA 之间[ 2][3].
如果您“从未使用过 Wireshark 查看不是来自我的 PC 的流量”，您可能不熟悉 promiscuous mode 的概念，但请注意，这不是重点，也无济于事：混杂模式只能帮助查看到达您的网络接口但通常会被其驱动程序或您的操作系统堆栈丢弃的流量。但在这里，流量实际上从一开始就不会到达您的接口，因为 AP 不会在基本 802.11 级别向它发送流量：AP 的基本作用是充当网桥（“交换机") 在 STA 之间，您的情况与使用有线以太网交换机的情况相同，您需要在交换机上进行端口镜像才能看到此类流量，因为交换机足够智能，不会发送此信息您将连接到的端口的流量。
在 802.11 上下文中，除了 “常规模式” 和 “混杂模式”，还有第三种模式："monitor"。在监控模式下——如果一切正常，因为这并不总是很明显——运行wireshark的数据包嗅探PC将不是STA，也不会以任何方式参与任何Wi-Fi流量，但你可能会“看到一切”（如果有加密，则加密，但wireshark 可以提供帮助。
关于 Wi-Fi 数据包嗅探的棘手世界，请参阅：
WLAN (IEEE 802.11) capture setup
（虽然针对wireshark，但技术概念也适用于其他基于pcap 的工具，例如libpcap（当然......）但也适用于tcpdump）
[0]
我在这里在其根级别使用术语“单播”，也就是说不是在它的“IP/第 3 层”含义中（我们处于 802.11 级别，即 PHY（第 1 层）+ 介质访问控制，又名MAC（第 2 层）- 介质是“空中”，但更根本的是“单播 = 从特定实体 A 到另一个特定实体 B 的通信”。
[1]：
来自RFC 2131, Dynamic Host Configuration Protocol，3.1 客户端-服务器交互-分配网络地址，第16页，第5段：
客户端应该对参数进行最终检查（例如，ARP
分配的网络地址），并注明租约的期限
在 DHCPACK 消息中指定。此时，客户端是
配置。如果客户端检测到该地址已被使用
（例如，通过使用 ARP），客户端必须发送 DHCPDECLINE
向服务器发送消息并重新启动配置过程。
[2]：
（最近的）Wi-Fi direct，不是 AP/STA 独有的——但这将是另一个话题——改变了这方面的格局。
[3]：
...别担心，这不会给 AP 软件带来任何负担（例如，这甚至不会进入用户区 AP 软件，例如 hostapd），这是由 ho-so 精心管理的- 技术先进的 Wi-Fi 硬件芯片组。
编辑：
抱歉，我一直忙于解释你们的“为什么”问题，忘记了“……现在该怎么办？”：
...但是在此特定情况下需要进行故障排除
一个问题。
所以我一直在使用两种方法：
1/ 使用监控模式。
虽然，可能会有很多问题：
- 您的（嗅探）Wi-Fi 硬件可能不支持它（通常不是
至少在 Linux 上存在问题，但是...），
- 您的操作系统可能不支持和/或需要特定硬件（请参阅
上面 Wireshark 的 wiki 链接，特别是如果您使用的是 Windows），
- 无线电环境可能嘈杂令人讨厌（我的情况是
工作）并且由于您正在嗅探PC只是被动地收听
无线电，而不是连接到任何你可能会错过数据包的东西（也
我在工作中的情况，出现在
wireshark“关注对话框”和
然后你会看到一些“（XXX缺失字节）），
- 在此之前，您遇到了加密问题，您可能想要
切换到非加密以缓解问题，这可能不是一个选项
（我通常能够做到这一点，但经常有一些“（XXX失踪
bytes)" 让整个事情变得毫无用处。
总而言之，根据我的经验，我将监控模式保留给低级 Wi-Fi 芯片组和基本 802.11 堆栈问题调查 = 不用于更高级别的应用协议故障排除。 但是，请尝试一下，如果这对你有用，那就没问题了。
2/ 在您正在排除故障的设备上运行实际的嗅探过程，并将其转发到解剖站（运行 wireshark/tcpdump 的 PC）。
这需要对设备进行相当多的控制（这对我来说很好，因为可以说是“我构建它们”）。为了使用它，我使用 SSH 连接在设备上启动 tcpdump - 相当多的先决条件，所以当然，如果您没有远程 shell 功能，也没有在设备上执行 pcap/tcpdump，那对你... :-/ 如果可行的话，我强烈推荐它。
这里是：
ssh foo@device "/usr/sbin/tcpdump -U -s0 -w - -i <wireless interface on the device> 'not port 22'" | wireshark -k -i -
...这会在设备上启动一个tcpdump 进程（当然，“foo”用户必须具有适当的权限才能在其默认混杂模式下启动tcpdump，尽管它的--no-promiscuous-mode 选项可能没问题，具体取决于关于你的问题）自行嗅探<wireless interface on the device>，过滤掉SSH本身，以便该工具不会与感兴趣的流量混淆，并将其发送回PC，然后将其通过管道传输到wireshark。还有“Voilà”，看魔术！
希望这会有所帮助。