[参考译文] WL1831：AP 模式：新客户端无法连接、且所有已连接的设备在邻居表中显示失败

您好、Chander：

是否可能有10多个器件连接到该 AP？ 器件数量有限制(10)、因此我很好奇是否达到了该限制。  

您使用的内核版本是什么？ 我认为您的系统相当过时。 我们有固件、驱动程序和 hostapd/请求程序更新。 要更新您的系统、我建议遵循以下指南： https://www.ti.com/lit/ug/swru561a/swru561a.pdf 

您好、Sabeeh：

以下是客户的回应：

是否可能有10多个器件连接到该 AP？ 器件数量有限制(10)、因此我很好奇是否达到了该限制。  

>> 我们可以看到这一观察结果少于4-5个设备。 它不会接近 AP 限制。

您使用的内核版本是什么？ 我认为您的系统相当过时。 我们有固件、驱动程序和 hostapd/请求程序更新。 要更新您的系统、我建议遵循以下指南： https://www.ti.com/lit/ug/swru561a/swru561a.pdf 

>> Observation 对我们来说有点惊讶,因为这是非常基本的功能,并且应该可靠地使用我们的版本。 我们希望您的支持人员在我们的版本中找出问题的根本原因。 一旦我们知道根本原因、我们就可以做出升级或修补决策。

我们可以支持您提供日志或运行任何测试工作以更快地分析问题。 请做必需的。 请参阅下面的版本详细信息：

内核-4.1.15

------------------

wl1271-NVS cortexa7hf-vfp-neon R8.6_sp1+git0+d39cb9d352-r1

wl18xx-calibrator cortexa7hf-vfp-neon 8.7.3-r0

wl18xx-固件 cortexa7hf-vfp-neon 8.9.0-r0

wlconf cortexa7hf-vfp-neon R8.6_sp1+git0+d39cb9d352-r1

WPA 请求程序 cortexa7hf-vfp-neon 2.7-r0

wpa-supplicant-cli cortexa7hf-vfp-neon 2.7-r0

wpa-supplicant-passphrase cortexa7hf-vfp-neon 2.7-r0

------------------

固件版本：

Wlcore：PHY 固件版本：版本8.2.0.0.242
wlcore：已启动固件(版本8.9.0.0.79)

------------------

您好、Chander：

我强烈建议客户将 wl18xx-fw.bin 更新为8.9.0.0.90、然后重新测试： https://git.ti.com/cgit/wilink8-wlan/wl18xx_fw/commit/?id=d2588c16809ecca8e0dc7ea011fc6180c7b08a92 

这可能无法解决他们的特定问题、但 我们需要了解此错误的来源：hostapd、wl18x 驱动程序或 FW。  

更新 FW 后、请使用 Wireshark 收集 Wi-Fi 监听器日志。  我需要更多详细信息以便更好地提供支持。  

您好 Sabeeh：

我们已将  wl18xx-fw.bin 更新为 8.9.0.0.90版本、此更新未解决 我们的问题。我还收集了 Wireshark 日志。 我已随此消息附加了日志文件

 e2e.ti.com/.../wireshark-log.zip

您好 Sabeeh：

我们已将  wl18xx-fw.bin 更新为 8.9.0.0.90版本、此更新未解决 我们的问题。我还收集了 Wireshark 日志。 我已随此消息附加了日志文件

 e2e.ti.com/.../wireshark-log.zip

我们观察到一些客户端连接 失败、一些客户端可以成功连接到 Wi-Fi AP。

您好、Lokesh。

Wireshark 日志没有帮助。 似乎您已经收集了以太网监听器。 Wireshark 捕获应显示 WL18x 器件的 MAC 地址。 您能记得吗？  

日志应显示关联和身份验证帧。 如果客户端连接出现问题、则 Wireshark 日志将显示此信息。 以下是一个示例： https://documentation.meraki.com/General_Administration Tools/Tools_and_Troubleshooting / Analyzing_Wireless_Packet_Captures 

您好 Sabeeh：

我们的系统在 Wireshark 中不支持监控模式、因此我们可以在不使用监控模式的情况下收集日志、或者我们需要使用支持监控模式的外部 Wi-Fi 适配器。

您好、Lokesh。  

我鼓励您 购买支持监控模式的 Wi-Fi 适配器。  

您能否尝试禁用 ELP 模式、看看这是否能纠正问题？ 可使用以下命令禁用 ELP：

iw wlan0将 power_save 设置为 off

回声0 >/sys/kernel/debug/ieee80211/phy0/wlcore/sleep_auth

您好 Sabeeh：

我们收集了 Wireshark 日志、它附加在下面的 zip 文件中、有两种类型的日志文件、一种是在所有客户端均正确连接时使用、另一种是在出现此问题时使用。

此处提供了网关和客户端的 MAC 地址、以便您更好地了解

Gateway MAC Address (DUT):  34:15:13:3e:34:0c

和客户端的 Mac 地址：  

笔记本电脑 Mac 地址：74：04：f1：9a：D3:0A

Tablet Mac 地址: 84:B8:B8:98:A5:f3

移动 Mac 地址: 1a:19:4e:61:56:58

e2e.ti.com/.../Wireshark_5F00_log.zip

您好 Sabeeh：

我们尝试了通过给定命令禁用 ELP 模式、但这并没有纠正我们的问题。

昨天我已经将 Wireshark 日志发送给您、请分析此日志 APA。

您好、Lokesh。

感谢您提供日志。 您能否说明该日志显示的内容？

这是我看到的。 似乎网关、笔记本电脑和平板电脑通信没有问题。 只有移动设备尝试连接但发送多个取消身份验证帧。 这是您遇到的情况吗？

我们可能还需要从 WL18x 本身收集日志。 以下是有关如何执行此操作的指南： https://www.ti.com/lit/ug/swru435a/swru435a.pdf 

您好 Sabeeh：

             根据您的响应、移动设备正在发送多个取消身份验证帧。 根据我们的分析,其他客户端也发送多个去身份验证帧。 发生这种情况的原因可能是、当此问题导致客户端无法连接到 Wi-Fi。 我关闭了客户端 Wi-Fi、等待了一段时间、客户端尝试连接到网关(DUT)、但无法连接、然后我重复此过程多次可能是由于这个原因、我们可以看到多个取消身份验证帧。

而根据你的网关,笔记本电脑和平板电脑通信没有问题,但我看到当这个问题发生时,在 Wireshark 日志中没有什么特别的,我们可以看到根据我的观察和理解。

如果我们无法根据 Wireshark 日志找到问题、那么我们需要采取什么措施、以便我们可以收集有关该问题的更多信息并进一步进行分析。

这里我还附加了一些 Wireshark 日志文件，这是发生的问题，但在该文件中，当系统正常时会生成许多日志，因此我无法对其进行筛选。如果您找到任何信息性日志，请查看这些日志，这样对我们会很有帮助。

e2e.ti.com/.../2308.log.zip

建议从 WL18x 本身收集日志。 但为此、我们需要安排硬件、以便此过程可能需要一些时间、因此请建议任何其他方法以便我们可以为您提供帮助、与 Wireshark 配置中的某些更改相关的方法以及我们可以快速执行的其他任何方法、以便尽快解决我们的问题。

我们观察到、客户端连接积累后、会出现另一个问题。
一般来说、我的 Gateway 始终与3个客户端(笔记本电脑、手机和平板电脑)相连

我观察到,当我的问题访问我2个客户端的 WiFi,然后我们看到 Wi-Fi 模块的固件崩溃, Wi-Fi 模块在几次后开始自我恢复,然后客户端自动连接。 通常,当所有客户端都连接在这段 时间,该固件也会崩溃,但它需要日志时间(几乎1小时以上)。

可能此观察结果会帮助您解决问题。

固件崩溃日志如下所示：

9月6日06：09：34 hostapd：wlanap1：STA 1a：19：4e：61：56：58 WPA：组密钥握手已完成(RSN)
9月6日：09：35 hostapd：wlanap1：STA 84：B8：B8：98：A5：F3 IEEE 802.11：已身份验证
9月6日：09：35 hostapd：wlanap1：STA 84：B8：B8：98：A5：F3 IEEE 802.11：相关(AID 1)
9月6日06：09：35 hostapd：wlanap1：STA 84：B8：B8：98：A5：F3 WPA：配对密钥握手完成(RSN)
SEP 6 06：09：53 hostapd：wlanap1：STA 84：B8：B8：98：A5：F3 WPA：组密钥握手在4次尝试后失败(RSN)
9月6日：09：55 hostapd：wlanap1：STA 84：B8：B8：98：A5：F3 IEEE 802.11：已身份验证
9月6日：09：55 hostapd：wlanap1：STA 84：B8：B8：98：A5：F3 IEEE 802.11：相关(AID 1)
9月6日06：09：55 hostapd：wlanap1：STA 84：B8：B8：98：A5：F3 WPA：配对密钥握手完成(RSN)   //此时我关闭平板电脑和笔记本电脑的 WiFi
9月6日：10：32 hostapd：wlanap1：STA 1a：19：4e：61：56：58 IEEE 802.11：已验证
9月6日：10：32 hostapd：wlanap1：STA 1a：19：4e：61：56：58 IEEE 802.11：Associated (AID 1)
9月6日06：10：33 hostapd：wlanap1：STA 1a：19：4e：61：56：58 WPA：配对密钥握手完成(RSN)
9月6日：10：54 hostapd：wlanap1：STA 1a：19：4e：61：56：58 IEEE 802.11：已验证
9月6日：10：54 hostapd：wlanap1：STA 1a：19：4e：61：56：58 IEEE 802.11：Associated (AID 1)
9月6日06：10：55 hostapd：wlanap1：STA 1a：19：4e：61：56：58 WPA：配对密钥握手完成(RSN)
9月6日：11：14 hostapd：wlanap1：STA 1a：19：4e：61：56：58 IEEE 802.11：已验证
9月6日06：11：14 hostapd：wlanap1：STA 1a：19：4e：61：56：58 IEEE 802.11：相关(AID 1)
9月6日06：11：14 hostapd：wlanap1：STA 1a：19：4e：61：56：58 WPA：配对密钥握手完成(RSN)
SEP 6 06：11：37内核：wlcore：错误 Tx 卡滞(在 FW 中)达5000ms。 开始恢复
9月6日06:11:37内核:------- [剪切此处]-------
SEP 6 06:11:37内核:警告: CPU: 0 PID: 1813 at /home/build/distro/master/skyline410/sky2.0/build/tmp/work-shared/imx6ul-skyline/kernel-source/drivers/net/wireless/ti/wlcore/main.c :796 wl12xx_queue_recovery_work.part.9+0x58/0x5c ()
SEP 6 06:11:37内核:模块链接在: CDC_ACM evbug
9月6日06:11:37内核: CPU: 0 PID: 1813 Comm: kworker/U2:1未被污染4.1.15-SML-20200120+g77f6154 #3
9月6日06:11:37内核:硬件名称: Freescale I. MX6 Ultralite (器件树)
SEP 6 06：11：37内核：workqueue：phy0 wl12xx_tx_watchdog_work
9月6日06：11：37内核：[<80015aa0>](discount_backtrace)、来自[<80012664>](show_stack+0x10/0x14)
SEP 6 06：11：37内核：[<8001264>](show_stack)(<805ed99c>](dump_stack+0x90/0xd0)
SEP 6 06：11：37内核：[<805ed99c>](dump_stack) from [<8002b95c>](warn_slowpath_common+0x80/0xb0)
SEP 6 06：11：37内核：[<8002b95c>](warn_sleppath_common)、来自[<8002ba28>](WARN_sleppath_null + 0x1c/0x24)
SEP 6 06：11：37内核：[<8002ba28>](warn_sleppath_null）来自[<80362f54>](wl12xx_queue_recovery_work.part.9+0x58/0x5c)
9月6日06：11：37内核：[<80362f54>](wl12xx_queue_recovery_work.part.9)来自[<80363074>](wl12xx_TX_watchdog_work+0x11c/0x120)
9月6日06：11：37内核：[<80363074>](wl12xx_tx_watchdog_work)、来自[<8003ebec>](proce_one_work+0x118/0x3e4)
SEP 6 06：11：37内核：[<8003ebec>](process _one_work)来自[<8003ef04>](worker_thread+0x4c/0x4f4)
SEP 6 06：11：37内核：[<8003ef04>](worker_thread)来自[<80043e44>](kthread+0xdc/0xf4)
9月6日06：11：37内核：[<80043e44>](kthread)来自[<8000f468>](RET_from_fork+0x14/0x2C)
SEP 6 06:11:37内核:--[结束跟踪5b6ecaa2359b7107 ]--
9月6日06:11:37内核: wlcore:硬件恢复正在进行中。 FW 版本：版本8.9.0.0.79
SEP 6 06：11：37 kernel: wlcore: PC: 0x0, HINT _STS: 0x00000020计数: 1
9月6日06:11:37内核: wlcore: down
SEP 6 06:11:37内核: ieee80211 phy0:已请求硬件重启
SEP 6 06：11：38内核：wlcore：PHY 固件版本：版本8.2.0.242
9月6日06：11：38内核：wlcore：已启动固件(版本8.9.0.0.79)
SEP 6 06:12:01 CROND[2065]：(ROOT) CMD (/etc/beanbag/syswatcher.sh 10240)
SEP 6 06:12:31 CROND[2064]:( root )邮件(邮寄14字节的输出,但得到状态0x004e )
9月6日：14：31 hostapd：wlanap1：STA 1a：19：4e：61：56：58 IEEE 802.11：已验证
9月6日：14：31 hostapd：wlanap1：STA 1a：19：4e：61：56：58 IEEE 802.11：Associated (AID 1)
9月6日06：14：31 hostapd：wlanap1：STA 1a：19：4e：61：56：58 WPA：配对密钥握手完成(RSN)
9月6日：15：36 hostapd：wlanap1：STA 84：B8：B8：98：A5：F3 IEEE 802.11：已身份验证
9月6日：15：36 hostapd：wlanap1：STA 84：B8：B8：98：A5：F3 IEEE 802.11：相关(AID 2)
9月6日06：15：36 hostapd：wlanap1：STA 84：B8：B8：98：A5：F3 WPA：配对密钥握手完成(RSN)
SEP 6 06:18:01 CROND[2134]：(ROOT) CMD (/etc/beanbag/syswatcher.sh 10240)
SEP 6 06:18:31 CROND[2133]:(root) mail (邮寄14字节的输出,但得到状态0x004e )
9月6日06：19：18 hostapd：wlanap1：STA 84：B8：B8：98：A5：F3 WPA：组密钥握手完成(RSN)
9月6日：19：48 hostapd：wlanap1：STA 1a：19：4e：61：56：58 IEEE 802.11：已验证
9月6日06：19：48 hostapd：wlanap1：STA 1a：19：4e：61：56：58 IEEE 802.11：相关(AID 1)
9月6日06：19：48 hostapd：wlanap1：STA 1a：19：4e：61：56：58 WPA：配对密钥握手完成(RSN)
SEP 6 06：24：01 CROND [2190]：(ROOT) CMD (/etc/beanbag/syswatcher.sh 10240)

您好、Lokesh。

从日志中可以看到、AP 的频率正在发生变化。 您将 AP 设置为哪个通道？

此外、您能否描述 Motorola 设备？ 是新产品吗？

您好、Sabeeh：

目前我们的设置在自动通道上运行。根据我的观察、它在通道1上运行的最长时间。 如果需要在特定信道上更改配置、我们可以建议我们进行更改。

摩托罗拉设备是我的平板电脑你可以检查它的 Mac 地址,它与我提供给你的 Mac 地址的平板电脑  84：B8：B8：98：A5：F3  

您好！

正如我在呼吁中提到的那样：

1.您可以通过设置 hostapd.conf 中的"WMM_ENABLED=0"来禁用 QoS。

2.要重新启动 WL18x 芯片，可以在 Linux 命令行"echo 1 >/sys/kernel/debug/ieee80211/phy0/wlcore/start_recovery "上执行。

Amrit、您好！

在软件中很难通过 AP 进行检测。 您可能可以检查驱动程序的状态或检查已连接站点的数量。 如果任何站点出现故障、则表示您已检测到故障。  

在软件中、您必须检查是否有一个客户端丢失、因此该数字在理想情况下会递减。  

您好 Sabeeh：

我们再次遇到了这个问题、我已经收集了 Wireshark 和 Wl18x 本身的日志。 我希望我们已收集了正确的 Wl18x 日志、如果需要进行更改、请提供以下建议。   

在 Wireshark 日志中、当客户端完全连接时会生成一些日志。

此处附加了日志文件。  e2e.ti.com/.../8304.log.zip

这是客户端和 DUT 的 Mac 地址、

网关(DUT) MAC 地址= D4：36：39：88：78：e8

客户端 MAC 地址

B2：4F：D3：9d：C3：0A

74：04：f1：9a：D3：0A

5A：D1：1D：3E：dc：09

84：B8：B8：98：A5：F3

ba：9a：7b：1e：11：c0

您好、Lokesh。  

感谢您提供日志、 但似乎只花了2分钟。 是否可以收集客户端断开连接的时间的日志？  

此外、这些日志是否是使用8.9.0.0.90 FW 获取的？  

您好 Sabeeh：

很抱歉由于技术问题导致回复延迟、我无法为您提供 WL18的日志。

现在、我已经收集了 WL18x 本身的日志、某个时候、这个问题出现了一段时间、这就是日志持续时间较短的原因。 我已尝试收集尽可能多的 Wl18日志很长一段时间、并且还将固件更新至8.9.0.0.90。 日志附加在此处 e2e.ti.com/.../2210.log.zip

我对您有一些疑问

1. 有没有任何方法可以找到客户总数或如果任何客户断开连接显示.

2.我们试图通过"ip neigh show"命令检测这个问题,方法是对所有可用的客户端执行 ping 命令,当所有可用的客户端都无法读取,然后我们重新启动 Wi-Fi 模块和 hostapd。  但我们认为"IP neigh show"列表将在重新启动 Wi-Fi 模块后清除,但它没有发生,所以我们如何才能从 IP neigh show 列表清除所有 IP。  

您好、Lokesh。

"IP neigh show"是否显示与"iw wlan1 station dump"相同的信息？ 由于每个客户端都发送去验证消息、因此 AP 应从已连接列表中减去此消息。  

您可能希望定期重新启动 AP、而客户端可能会在重新启动后自动重新连接。  

我还将进一步查看您的日志。

您好、Sabeeh：

"IP neigh show"显示特定客户端的 IP 及其状态。 "iw wlan1 station dump (iw wlan1工作站转储)"显示所有客户端的信息 、如其 Mac 地址、连接时间、信号强度等。它不显示 IP 地址。

在"IP neigh show"中，我们观察到，当客户机的 Wi-Fi 关闭的时候，它也显示客户机可以访问，在重新启动 Wi-Fi 模块和主机后，Deamon 它显示以前的分配 IP，如果这个列表被清除，我们想要的状态是失败或不完整的。 然而,我们再重新启动陷阱,然后我们的问题可能会得到解决。

如果我们 定期重新启动 AP 、所有客户端将需要一些时间才能连接。 而在我们重新启动 AP 的时候、 我们会遇到困难、因为 有时此问题会在 重新启动系统后发生(有时会更晚)。

您好、Lokesh。

除了可在用户空间中使用的命令外、我们无法确定特定器件是否与 AP 失去通信。  

您好 Sabeeh：

您在9月14日建议使用更长持续时间的 WL18日志、因此我们于9月15日向您提供了所需的日志并升级了 FW。

1.请分享您从日志中得到的信息。

2.是否有任何进一步的行动来找出根本原因(如果你仍然没有找到根本原因)我们需要做,让我们知道。

3.何时我们可以从您那里得到任何解决方案?

此致、

洛克什

您好、Lokesh。

与先前共享的 wl18x 日志相比、您共享的日志未正确解析、因此没有显示任何有用的内容。 所有文件显示"Bad Packet Received"(接收到错误的数据包)。 早期版本  

在调试步骤中、最好使用带有 WL18x 的 AM335x EVM 或 BeagleBone Black 并使用我们的最新软件。 您可以在以下网址找到我们最新软件的指南： https://www.ti.com/lit/ug/swru561a/swru561a.pdf 

如果问题不能重现、那么它将帮助我们开始了解问题是什么。 提醒一下、您当前的软件版本已过时。 让我们反向解决这个问题。  

您好、Sabeeh：

今天,我也收集了一些更多的 Wl18本身的日志。 我在创建问题时突出显示了时间戳、并且在模块 FW 崩溃时以红色突出显示了时间戳、我希望这将帮助您找到此连接问题的根本原因。

日志已附加 here.e2e.ti.com/.../glogger_5F00_log.zip

我在您的最新固件(8.9.0.0.90)中向您提出了一个查询、其中是否存在任何逻辑、如果我们的客户端无法连接到 AP、则模块固件将崩溃。

您好、Lokesh。

感谢这些日志、我正在积极地审阅此内容。  

我不确定您的问题是什么意思。 在这种情况下、FW 不会崩溃。 hostapd 或 wl18xx Linux 驱动程序似乎出错。 这就是为什么我建议尝试最新的 Linux 软件、以便我们可以确认最新版本不存在相同的问题。  

我在此日志中看到的是客户端尝试连接、然后 WL18x 会立即断开连接。 我仍在研究为什么这可以是

您是否尝试过使用开放网络配置 hostapd？ 问题是否仍然存在？

您好 Sabeeh：

根据建议、当 hostapd 使用开放网络测试完成时、我们将向您更新结果。

此致、

阿米里

您好 Sabeeh：

根据您的建议、我们通过设置 wpa=0为开放网络设置 hostapd.conf。

当我们重新启动 hostapd & udhcpd Linux 进程时、我们发现同样的问题仍然存在、但问题仍然存在。
当我们通过" 回声1 >/sys/kernel/debug/ieee80211/phy0/wlcore/start_recovery "  问题得到解决。

此致、

阿米里

您好 Sabeeh：

根据讨论、我已经收集了 Wireshark 和 WiLink 本身的日志。 此处附加了日志。  e2e.ti.com/.../2746.logs.zip

在 ZIP 文件中、Wireshark 和 WiLink 日志保存的时间相同

此问题发生于2023年10月3日的 IST 14:35-18:00

最后、我手动触发命令以恢复 Wi-Fi 模块  

中设为1  

AP 的 MAC 34：15：13：3e：32：6c

客户端的 MAC 地址

74：04：f1：9a：D3：0A
00：13：E1：12：19：da
BA：43：23：C1：48：91
84：B8：B8：98：A5：F3

您好、Lokesh。

与上一个日志相比、这些日志没有太大的不同。 监听器未捕获足够的数据以进行更好的调试。

请参阅此屏幕截图：  

日志中有多次跳跃、并且它们跳跃多秒！！ AP 每100ms 发送一次信标帧、因此有数千条消息未被捕获。  

您是否有机会获得其他监听器？ 如果不是、 我建议在射频暗室中进行测试。 或者、您可以断开该区域中所有的 WiFi 设备(包括移动设备)、希望监听器可以捕获更多数据。  

您好 Sabeeh：

现在我们正在使用 WLAN 监听器 TP-LINK (型号：TL-WN722N)  

如果我们需要配置一些设置以增加缓冲区大小、然后能够记录更多数据、请提供建议。

我对该器件不是很熟悉。 我鼓励您在网上搜索并了解可能出现的问题。 或者、您可以关闭区域中的其他 WiFi 设备。  

您好 Sabeeh：

根据您的建议、我们也在射频室内制造了问题、我已在此处附加了日志(Wireshark 和 WiLink 两者) e2e.ti.com/.../New-folder.zip
在此日志中、问题发生于10-10-2023 10：50 (IST)、我在 10-10-2023 11：19 (IST)手动恢复此问题

您好、Lokesh。

我需要进一步审查,但不幸的是,这些日志并没有告诉我很多。 请查看下面的 DEAUTH 消息图。 有许多 ACK、然后客户端退出。 无法判断是 WL8还是您的客户端设备出现了问题。  

监听器还提示 AP 位于许多不同的信道上、因此我认为监听器本身存在问题。  

Amrit、您好！

我们需要了解为什么客户端会发送 DEAUTH 或断开连接消息。 不仅仅是缺少信标、还有监听器丢失的许多消息、因此无法了解客户端或 AP 发送 DEAUTH 的原因。 例如、如果 WL18x 向客户端发送了一条消息、而客户端在预期收到但没有接收、则很可能会发送 DEAUTH。 整个事务应该可以在监听器日志中看到。  

您拥有的日志只有来自两个器件的 ACK、两者之间没有数据。 无 DHCP 请求或类似请求。 不是很值得一看  

Amrit、您好！  

它的性能应该比当前的监控硬件好得多、并且注意它最常用于 Ubuntu 计算机。  

如果您正在寻找现成的监听器、请通读该指南： https://wiki.wireshark.org/CaptureSetup/WLAN 您可以在其中找到有关各种适配器以及它们如何与 Wireshark 配合使用的说明。  

Amrit、您好！  

我不知道有什么。 正如我所提到的、如果您正在寻找现成的产品、请通读上面的指南。