(虽然我想到了,首先:这与加密没有任何关系——否则你会看到流量,肯定是加密的,但你仍然会看到“东西”通过。)
如果是多播或广播,您只会看到进出此设备的流量。
这是因为 AP(接入点)和 STA(站)之间的通信方式在 Wi-Fi/802.11 中发生。在 802.11 级别,假设 STA A 和 STA B 之间的每个“单播”[0] 通信实际上并不直接从 STA A 到 STA B:首先从 STA A 到 AP 的 802.11 帧,然后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 请求(见上文),
您可能会看到的另一个不太常见但并不罕见的流量是固有广播的流量:
- ICMPv6 邻居请求/广告(来自运行具有双 IP 堆栈的现代操作系统的 STA)
- Dropbox LAN 发现协议(哦,这对于普通 PC STA 来说可能会很吵)
- UPnP SSDP(即端口 1900 上的 UDP 多播)
- ...并且可能更多取决于在 STA(或 AP,当然,例如 DHCP)中运行的应用程序。
这是在 AP/STA 设置中使用 Wi-Fi/802.11 时要理解且永远不会忘记的基本点:所有通信都通过 AP,而不是直接在 STA[2][3] 之间进行。
如果您“从未使用过 Wireshark 查看并非来自我的 PC 的流量”,您可能不熟悉混杂模式的概念,但请注意,这不是重点,也无济于事:混杂模式可以仅有助于查看到达您的网络接口但通常会被其驱动程序或您的操作系统堆栈丢弃的流量。但在这里,流量实际上从一开始就不会到达您的接口,因为 AP 不会在基本 802.11 级别向它发送流量:AP 的基本作用是充当两者之间的桥梁(“交换机”) STA,您的情况与使用有线以太网交换机的情况相同,您需要在交换机上进行端口镜像才能查看此类流量,因为交换机足够智能,不会将此流量发送到您要连接的端口。
在 802.11 上下文中,除了“常规模式”和“混杂模式”之外,还有第三种模式:“监控”。在监控模式下——如果一切正常,因为这并不总是显而易见的——你运行的数据包嗅探电脑wireshark
将不是一个 STA,也不会以任何方式参与任何 Wi-Fi 流量,但你可能会“看到一切”(如果有加密,但wireshark
可以提供帮助)。
关于 Wi-Fi 数据包嗅探的棘手世界,请参阅:
WLAN (IEEE 802.11) 捕获设置
(虽然针对wireshark
,但技术概念也适用于其他pcap
基于工具,例如libpcap
(当然......)但也tcpdump
)
[0] 我在这里使用术语“单播”在它的根级别,也就是说不是在它的“IP/第 3 层”含义中(我们在 802.11 级别,即 PHY(第 1 层)+ 中访问控制又名 MAC(第 2 层)- 介质是“空中”,但更根本的是“单播 = 从特定实体 A 到另一个特定实体 B 的通信”。
[1]:来自RFC 2131,动态主机配置协议,3.1 客户端-服务器交互 - 分配网络地址,第 16 页,第 5 段:
客户端应该对参数进行最终检查(例如,分配网络地址的 ARP),并注意 DHCPACK 消息中指定的租约持续时间。至此,客户端就配置好了。如果客户端检测到地址已经被使用(例如,通过使用 ARP),客户端必须向服务器发送 DHCPDECLINE 消息并重新启动配置过程。
[2]:(相当新的)Wi-Fi direct不是 AP/STA 独有的——但这将是另一个话题——改变了这方面的格局。
[3]: ...别担心,这不会给 AP 软件带来任何负担(例如,这甚至不会去用户区 AP 软件,例如hostapd
),这是由 ho-技术如此先进的 Wi-Fi 硬件芯片组。
编辑:
抱歉,我一直忙于解释你的问题的“为什么”,忘记了“......现在如何?”:
...但是在这种特殊情况下有必要对问题进行故障排除。
所以我一直在使用两种方法:
1/ 使用监控模式。
虽然,可能有很多问题:
- 您的(嗅探)Wi-Fi 硬件可能不支持它(至少在 Linux 上通常不是问题,但是......),
- 您的操作系统可能不支持和/或需要特定硬件(请参阅上面的 Wireshark 的 wiki 链接,尤其是在 Windows 上时),
- 无线电环境可能非常嘈杂(我在工作时就是这种情况),因为您正在嗅探 PC 只是被动地收听无线电,而不是连接到任何您可能会错过数据包的东西(我在工作时也是这种情况,出现在
wireshark
“跟随对话框”,然后你会看到一些“(XXX缺失字节)),
- 在此之前,你有加密问题,你可能想切换到非加密来缓解事情,这可能不是一个选择(我通常能够这样做,但经常会出现一些“(XXX丢失字节) “让整个事情变得毫无用处。
总而言之,根据我的经验,我将监控模式保留给低级 Wi-Fi 芯片组和基本的 802.11 堆栈问题调查 = 不用于更高级别的应用协议故障排除。但是,请试一试,如果这对你有用,那就没问题了。
2/ 在您正在排除故障的设备上运行实际的嗅探过程,并将其转发到解剖站(运行wireshark
/的 PC tcpdump
)。
这需要对设备进行相当多的控制(这对我来说很好,因为可以这么说,因为“我建造了它们”)。为了使用它,我使用 SSH 连接tcpdump
在设备上启动 a - 相当多的先决条件,所以当然,如果您没有远程 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à”,观看魔术!
希望这可以帮助。