无法通过 Wireshark（通过 Wi-Fi）找到特定设备的流量
Unable to find traffic for specific device w/ Wireshark (over Wi-Fi)
我有一个设备与我机器上的 TCP 服务器 运行 通信。我的机器通常通过以太网连接到网络，但是我也有一个无线适配器，可以用来连接到我的路由器。设备（TCP 客户端）连接到我的路由器（WPA2-个人/AES 加密/安全密钥）。
我可以在我的以太网适配器上看到带有 Wireshark 的设备与我的服务器通信。查看无线适配器时找不到设备（我正在通过 IP 查找设备）。我进入编辑 > 首选项 > 协议 > IEEE 802.11 无线局域网 > 解密密钥 > 然后设置 wpa=pwd "password:ssid" 和 wep-psk "key that I generated here".
我从未使用 Wireshark 查看不是来自我的 PC 的流量，但是在这个特定实例中有必要解决问题。任何帮助将不胜感激。
（虽然我想到了，但首先：根本原因与加密没有任何关系 - 否则你会看到流量，当然是加密的，但你仍然会看到 "stuff" 通过。）
您只会看到流量 to/from 此设备如果是多播或广播。
这是因为AP（接入点）和STA（站）之间的通信方式发生在Wi-Fi/802.11。在 802.11 级别，假设 STA A 和 STA B 之间的每个 "unicast"[0] 通信实际上 而不是 直接从 STA A 到 STA B：首先从 STA A 到 AP 的 802.11 帧，然后 AP 将其发送到 STA B 等
因此，如果您的设备发送一些 multicast/broadcast 流量，您将看到这个 - 但只有这个（对 multicast/broadcast 的响应通常是单播的）。
您可能会看到源自此站的某些流量将是 ARP 请求 - 这是广播，因此 AP 的工作是将其发送到其所有 STA。你会看到这些。
Wi-Fi 环境中此类流量的另一个非常常见的示例是 STA 是 DHCP 客户端。然后您将看到 DHCP 请求。在典型情况下，此 STA 会在 association/authentication 之后向 AP 发出此类 DHCP 请求。在这种情况下，从您的 PC 运行 wireshark（这是来自同一 AP 的另一个 STA），您将看到 DHCP 请求，因为它是广播的并且 AP 将分发它（我有意不使用术语 "forward").但通常不会更多，因为在典型情况下，AP 也是 DHCP 服务器，因此有关此 DHCP 过程的其余通信将直接在 AP 和所述 STA 之间发生。不过，您还应该看到一个 ARP 请求 - 见上文 - 由所述 DHCP 客户端 STA 发出，以检查 DHCP 服务器刚刚提供的 IP 是否确实是免费的，因为这是 DHCP 协议要求[1] ] 如果正确实施。
您可能会看到的另一种不常见但也不罕见的流量是固有广播流量：
- ICMPv6邻居solicitations/advertisement（来自STA运行一个
具有双 IP 堆栈的现代 OS）
- Dropbox LAN 发现协议（哦，这可能会很吵
普通 PC STA)
- UPnP SSDP（即端口 1900 上的 UDP 多播）
- ...可能还有更多取决于 运行 中的应用程序
STA（当然也可以是 AP，例如 DHCP）。
这是在 AP/STA 设置中使用 Wi-Fi/802.11 时需要理解和永远不会忘记的基本点：所有通信都通过 AP，从不 直接在 STA[2][3].
之间
如果你"have never used Wireshark to look at traffic that does not originate from my PC"，你可能不熟悉promiscuous mode的概念，但请注意，这不是重点，在这里也无济于事：混杂模式只能帮助看到到达您的网络接口但通常会被其驱动程序或您的 OS 堆栈丢弃的流量。但是在这里，流量实际上从一开始就不会进入您的接口，因为 AP 不会在基本 802.11 级别将此流量发送给它：AP 的基本作用是充当桥梁（ "switch") 在 STA 之间，你的情况与使用有线以太网交换机时的情况相同，你需要在交换机上进行端口镜像才能看到这样的流量，因为交换机是智能的足以不将此流量发送到您要连接的端口。
在 802.11 上下文中，除了 "regular mode" 和 "promiscuous mode" 之外，还有第三种模式： "monitor"。在监控模式下——如果一切正常，因为这并不总是很明显——你的数据包嗅探 PC 运行 wireshark 将不会成为 STA，也不会以任何方式参与任何 Wi-Fi 流量，但你可以然后 "see everything"（如果有加密，则加密，但 wireshark 可以提供帮助）。
关于 Wi-Fi 数据包嗅探的棘手世界，请参阅：
WLAN (IEEE 802.11) capture setup
（虽然针对 wireshark，技术概念也适用于其他基于 pcap 的工具，例如 libpcap（当然...）而且 tcpdump)
[0]
我在此处的根级别使用术语 "unicast"，也就是说不是 "IP/layer 3" 的含义（我们处于 802.11 级别，即 PHY（第 1 层）+ 介质访问控制又名 MAC（第 2 层）- 媒体是 "the air), but more fundamentally as "单播 = 从特定实体 A 到另一个特定实体 B 的通信。
[1]:
来自 RFC 2131, Dynamic Host Configuration Protocol，3.1 客户端-服务器交互 - 分配网络地址，第 16 页，第 5 段：
The client SHOULD perform a final check on the parameters (e.g., ARP
for allocated network address), and notes the duration of the lease
specified in the DHCPACK message. At this point, the client is
configured. If the client detects that the address is already in use
(e.g., through the use of ARP), the client MUST send a DHCPDECLINE
message to the server and restarts the configuration process.
[2]:
（最近的）Wi-Fi direct，它不是 AP/STA 独有的——但这将是另一个话题——改变了这方面的格局。
[3]:
...别担心，这不会给 AP 软件带来任何负载（例如，这甚至不会进入用户态 AP 软件，例如 hostapd），这是由 ho 精心管理的-技术如此先进的 Wi-Fi 硬件芯片组。
编辑：
抱歉，我一直忙着解释 "why" 的问题，忘记了“...现在怎么办？”：
...however it's necessary in this particular instance to troubleshoot
a problem.
所以我一直在使用两种方法：
1/ 使用监控模式。
不过，可能会有很多问题：
- 您的（嗅探）Wi-Fi 硬件可能不支持它（通常不是
至少在 Linux 上有问题，但是...),
- 您的 OS 可能不支持 and/or 需要特定的硬件（请参阅
Wireshark 的 wiki link 上面，特别是如果你在 Windows),
- 无线电环境可能嘈杂得令人讨厌（我在
工作），因为你在嗅探 PC 只是被动地听
无线电而不是连接到任何你可能会错过数据包的东西（也
我在工作中遇到的情况出现在
wireshark "follow dialog" 和
然后你会看到一些 "(XXX missing bytes)),
- 在此之前，您遇到了加密问题，您可能需要
切换到非加密以简化事情，这可能不是一个选项
（我通常能够做到这一点，但往往有些“（XXX丢失
字节）”使整个事情变得毫无用处。
总而言之，根据我的经验，我将监控模式保留给低级 Wi-Fi 芯片组和基本 802.11 堆栈问题调查 = 不用于更高级别的应用程序协议故障排除。 但是，请试一试，如果对你有用，那就太好了。
2/ 运行你正在排除故障的设备上的实际嗅探过程，并将其转发到解剖站（PC 运行 wireshark/ tcpdump).
这需要对设备进行相当多的控制（这对我来说很好，因为 "I build them" 可以这么说）。为了使用它，我使用 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à"，看魔术！
希望对您有所帮助。
我有一个设备与我机器上的 TCP 服务器 运行 通信。我的机器通常通过以太网连接到网络，但是我也有一个无线适配器，可以用来连接到我的路由器。设备（TCP 客户端）连接到我的路由器（WPA2-个人/AES 加密/安全密钥）。
我可以在我的以太网适配器上看到带有 Wireshark 的设备与我的服务器通信。查看无线适配器时找不到设备（我正在通过 IP 查找设备）。我进入编辑 > 首选项 > 协议 > IEEE 802.11 无线局域网 > 解密密钥 > 然后设置 wpa=pwd "password:ssid" 和 wep-psk "key that I generated here".
我从未使用 Wireshark 查看不是来自我的 PC 的流量，但是在这个特定实例中有必要解决问题。任何帮助将不胜感激。
（虽然我想到了，但首先：根本原因与加密没有任何关系 - 否则你会看到流量，当然是加密的，但你仍然会看到 "stuff" 通过。）
您只会看到流量 to/from 此设备如果是多播或广播。
这是因为AP（接入点）和STA（站）之间的通信方式发生在Wi-Fi/802.11。在 802.11 级别，假设 STA A 和 STA B 之间的每个 "unicast"[0] 通信实际上 而不是 直接从 STA A 到 STA B：首先从 STA A 到 AP 的 802.11 帧，然后 AP 将其发送到 STA B 等
因此，如果您的设备发送一些 multicast/broadcast 流量，您将看到这个 - 但只有这个（对 multicast/broadcast 的响应通常是单播的）。
您可能会看到源自此站的某些流量将是 ARP 请求 - 这是广播，因此 AP 的工作是将其发送到其所有 STA。你会看到这些。
Wi-Fi 环境中此类流量的另一个非常常见的示例是 STA 是 DHCP 客户端。然后您将看到 DHCP 请求。在典型情况下，此 STA 会在 association/authentication 之后向 AP 发出此类 DHCP 请求。在这种情况下，从您的 PC 运行 wireshark（这是来自同一 AP 的另一个 STA），您将看到 DHCP 请求，因为它是广播的并且 AP 将分发它（我有意不使用术语 "forward").但通常不会更多，因为在典型情况下，AP 也是 DHCP 服务器，因此有关此 DHCP 过程的其余通信将直接在 AP 和所述 STA 之间发生。不过，您还应该看到一个 ARP 请求 - 见上文 - 由所述 DHCP 客户端 STA 发出，以检查 DHCP 服务器刚刚提供的 IP 是否确实是免费的，因为这是 DHCP 协议要求[1] ] 如果正确实施。
您可能会看到的另一种不常见但也不罕见的流量是固有广播流量：
- ICMPv6邻居solicitations/advertisement（来自STA运行一个 具有双 IP 堆栈的现代 OS）
- Dropbox LAN 发现协议（哦，这可能会很吵 普通 PC STA)
- UPnP SSDP（即端口 1900 上的 UDP 多播）
- ...可能还有更多取决于 运行 中的应用程序 STA（当然也可以是 AP，例如 DHCP）。
这是在 AP/STA 设置中使用 Wi-Fi/802.11 时需要理解和永远不会忘记的基本点：所有通信都通过 AP，从不 直接在 STA[2][3].
之间如果你"have never used Wireshark to look at traffic that does not originate from my PC"，你可能不熟悉promiscuous mode的概念，但请注意，这不是重点，在这里也无济于事：混杂模式只能帮助看到到达您的网络接口但通常会被其驱动程序或您的 OS 堆栈丢弃的流量。但是在这里，流量实际上从一开始就不会进入您的接口，因为 AP 不会在基本 802.11 级别将此流量发送给它：AP 的基本作用是充当桥梁（ "switch") 在 STA 之间，你的情况与使用有线以太网交换机时的情况相同，你需要在交换机上进行端口镜像才能看到这样的流量，因为交换机是智能的足以不将此流量发送到您要连接的端口。
在 802.11 上下文中，除了 "regular mode" 和 "promiscuous mode" 之外，还有第三种模式： "monitor"。在监控模式下——如果一切正常，因为这并不总是很明显——你的数据包嗅探 PC 运行 wireshark 将不会成为 STA，也不会以任何方式参与任何 Wi-Fi 流量，但你可以然后 "see everything"（如果有加密，则加密，但 wireshark 可以提供帮助）。
关于 Wi-Fi 数据包嗅探的棘手世界，请参阅：
WLAN (IEEE 802.11) capture setup
（虽然针对 wireshark，技术概念也适用于其他基于 pcap 的工具，例如 libpcap（当然...）而且 tcpdump)
[0] 我在此处的根级别使用术语 "unicast"，也就是说不是 "IP/layer 3" 的含义（我们处于 802.11 级别，即 PHY（第 1 层）+ 介质访问控制又名 MAC（第 2 层）- 媒体是 "the air), but more fundamentally as "单播 = 从特定实体 A 到另一个特定实体 B 的通信。
[1]: 来自 RFC 2131, Dynamic Host Configuration Protocol，3.1 客户端-服务器交互 - 分配网络地址，第 16 页，第 5 段：
The client SHOULD perform a final check on the parameters (e.g., ARP for allocated network address), and notes the duration of the lease specified in the DHCPACK message. At this point, the client is configured. If the client detects that the address is already in use (e.g., through the use of ARP), the client MUST send a DHCPDECLINE message to the server and restarts the configuration process.
[2]: （最近的）Wi-Fi direct，它不是 AP/STA 独有的——但这将是另一个话题——改变了这方面的格局。
[3]:
...别担心，这不会给 AP 软件带来任何负载（例如，这甚至不会进入用户态 AP 软件，例如 hostapd），这是由 ho 精心管理的-技术如此先进的 Wi-Fi 硬件芯片组。
编辑：
抱歉，我一直忙着解释 "why" 的问题，忘记了“...现在怎么办？”：
...however it's necessary in this particular instance to troubleshoot a problem.
所以我一直在使用两种方法：
1/ 使用监控模式。
不过，可能会有很多问题：
- 您的（嗅探）Wi-Fi 硬件可能不支持它（通常不是 至少在 Linux 上有问题，但是...),
- 您的 OS 可能不支持 and/or 需要特定的硬件（请参阅 Wireshark 的 wiki link 上面，特别是如果你在 Windows),
- 无线电环境可能嘈杂得令人讨厌（我在
工作），因为你在嗅探 PC 只是被动地听
无线电而不是连接到任何你可能会错过数据包的东西（也
我在工作中遇到的情况出现在
wireshark"follow dialog" 和 然后你会看到一些 "(XXX missing bytes)), - 在此之前，您遇到了加密问题，您可能需要 切换到非加密以简化事情，这可能不是一个选项 （我通常能够做到这一点，但往往有些“（XXX丢失 字节）”使整个事情变得毫无用处。
总而言之，根据我的经验，我将监控模式保留给低级 Wi-Fi 芯片组和基本 802.11 堆栈问题调查 = 不用于更高级别的应用程序协议故障排除。 但是，请试一试，如果对你有用，那就太好了。
2/ 运行你正在排除故障的设备上的实际嗅探过程，并将其转发到解剖站（PC 运行 wireshark/ tcpdump).
这需要对设备进行相当多的控制（这对我来说很好，因为 "I build them" 可以这么说）。为了使用它，我使用 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à"，看魔术！
希望对您有所帮助。