[参考译文] CC3200：DHCP 偶尔超时

C é dric、您好！

您是否能够捕获工作案例和非工作案例的 NWP 日志？

从监听器捕获中、在故障情况下似乎没有发送 DHCP 发现消息。 查看 NWP 日志将帮助我们了解这种情况的原因。 在该主题中附加完整的监听器日志也非常有用。 如果您能给我提供这些信息、那将会很好。

至于与我最近帮助的另一个主题的相似之处、可能有一些链接。 Cisco AP 是否也是 DHCP 服务器？ 从监听器捕获屏幕截图中看不出这种情况、但我想确认一下。

此致、

Michael

您好！  

我已检测到设备并进行了记录。 您能否确认这是预期的格式和内容？  

 /cfs-file/__key/communityserver-discussions-components-files/968/1440.putty.log

谢谢、

C é dric

您好！

日志看起来正常。 ~~~~=~=~=~=~=~=~=~==~= PuTTY 日志2020.07.02 13：27：06 =~=~=~=~=Δ=Δ=Δ=Δ=Δ=Δ=Δ=Δ=Δ=Δ=Δ=~=Δ=Δ=Δ=~~~~~

1月

C é dric、您好！

感谢您捕获这些日志。 遗憾的是、它们看起来并不完整、因为日志中缺少消息。 您能否仔细检查您的记录软件并确保它捕获 CC3200的完整二进制数据输出？

我们还可以尝试其他几个调试步骤：

1. 请尝试降级 CC3200上的服务接收器。 如果安装了旧版本的服务包，则可以使用这些旧的服务包，并查看是否遇到相同的 DHCP 问题。 该线程中的另一位客户注意到、使用旧的服务接收器会有所帮助、因此了解它是否会导致您的设置中的行为发生变化也很有用。
2. 请尝试将 AP 设置为开放安全、而不是 WPA2、仅用于此测试。 在更新的服务接收器中执行了一些功能更改、以修复可能影响此 DHCP 序列的某些 WPA2行为。 如果未使用 WPA2安全性、我们将能够查看这些更改是否会对 DHCP 序列产生某种影响。

此致、

Michael

您好！

感谢您的反馈！

我正在使用 PuTTY、如链接 https://processors.wiki.ti.com/index.php/CC3100_%26_CC3200_Capture_NWP_Logs 中所述 

和 CC31XXEMUBOOST 用于 串行转 USB 部件。

我想这是可以的。 但是、我们的唤醒周期非常短。 通常在3或4秒内、器件将恢复休眠状态。 这是否会阻止日志完全输出？ 我应该在某个地方添加一些延迟吗？

ServicePack_1.0.1.131-2.11.0.1存在相同的问题。  以及 OTA_1.0.1.6-2.6.0.5。

C é dric

C é dric、您好！

如果器件进入休眠状态、则 UART 外设也将停止运行。 因此、插入延迟以完成打印将非常有用。

有趣的是、对于您的设置、降级服务攻击似乎不会导致行为发生变化。 当其他客户看到类似问题时、降级服务接收器似乎会产生一些效果。

不过、根据开放模式下设置的 AP 进行测试对于验证还是很有用的。

此致、

Michael

您好、Michael、

这是一个文件、我在其中添加了几秒钟的延迟。 您能否确认这次是否已完成？ (是否有办法让我知道它是完整的？)

/cfs-file/__key/communityserver-discussions-components-files/968/3858.putty.log

编辑：ARF、我看到两个文件完全相同...

在以下过程中、我通常应在何处添加睡眠：

sl_start

sl_WlanRxStatStart

http_connect

http 请求

http 断开

sl_WlanRxStatStop

sl_Stop (sl_stop_timeout)；

MAP_PRCMHibernateEnter 

注意：我使用 MAP_UtilsDelay 进行睡眠。 我添加了5秒睡眠。

您是否看到任何其他原因可以解释日志中缺少的部分？

对于开放模式、它将变得复杂、因为它是我们客户提供的实时环境。 我们将看到。

谢谢！

C é dric

C é dric、您好！

新日志实际上与以前提供的日志相同。 我想知道将 UART 信号从 CC3200传出并传输到您的 PC 是否存在硬件问题。 如果您可以将 CC3200 Launchpad 与基本代码示例结合使用、并查看您是否获得了与有用的调试信息相同的输出。

在延迟方面、最有用的可能是在 sl_Start()之后、因为这将允许 CC3200在不中断的情况下初始化并重新连接到 Wi-Fi。

此致、

Michael

您好、Michael、

我们的客户发现他们的 Cisco Meraki AP 的固件版本存在已知错误，AP 未发送 EAPOL 密钥消息3。 现在、他们安装了最新版本候选版本、似乎有所帮助、但仍然存在问题。

在接入点上看到新的 Wireshark 捕获。 似乎 cc3200没有回复"压缩的阻塞请求"。

/cfs-file/__key/communityserver-discussions-components-files/968/Failed_5F00_7c010a78fabe.zip

对于 NWP 日志、这是一次使用 TeraTerm 时使用的新日志、延迟越大、文件越大。 您能否确认是否已完成？

/cfs-file/__key/communityserver-discussions-components-files/968/6177.teraterm2.log

谢谢、

C é dric

C é dric、您好！

提供的日志看起来更完整。 但是、在捕获的日志中、CC3200实际上设法通过 DHCP (192.168.1.207)获取 IP 地址。

监听器捕获的 CC3200器件的 MAC 地址是什么？ NWP 日志在引导时将其报告为7c：01：0A：75：53：1D、但我在日志中看不到该 MAC 地址。

此致、

Michael

您好、Michael、

NWP 日志记录在我们的工作环境中。 这主要是为了确保我能够在去客户之前提取数据。

监听器捕获在我们的客户环境中完成、 器件的 Mac 地址为7c：01：0A：78：fa：be

如果我下周与我们的客户交流、我们是否可以使用更直接的方式来交换日志和进行讨论？ 只是为了确保我了解问题所需的所有内容？

谢谢、

C é ric

C é dric、您好！

对于更直接的沟通、您有什么想法？

通常、最好将内容保留到 E2E 中、因为我们在论坛上的通信可帮助 CC32xx 的所有用户。 但是、如果有具体原因不使用该论坛、例如需要交换敏感数据、则可以使用更直接的通信。 如需更多信息、请联系您分配的 TI 现场销售团队。

此致、

Michael

主要原因是我必须旅行4个小时才能到达那里。 我无法知道提取的 NWP 日志是否有用。 因此、直接验证日志可能会节省几天的差旅/工作时间、因为 E2E 上的典型问题/回答需要1天时间。

我正在考虑电子邮件或任何其他直接沟通。 虽然相关问题可能是我们各自的时区、但我必须在您的工作时间内联系我们的客户。

如果无法实现。 请确认我可以在此处执行的所有操作、以帮助您了解不发送 DHCP 发现的原因。  

我的计划：

• 同时在接入点和 NWP 日志上进行网络捕获。
• 确保捕获失败的尝试和成功的尝试
• 尝试使用我将随附的 cc3235
• 检查是否可以使用开放网络进行测试(可能不可能)
• 使用 always_on 策略和常规策略进行检查
• ？？？

您是否看到任何其他有助于诊断的东西？

谢谢、

C é dric

您好！

您可以在收集的日志上执行完整性检查、然后再将其提供给我。 如果从冷启动成功捕获 NWP 日志、则应在原始日志中看到一些 ASCII 明文、尤其是/sys/servicepack.ucf NWP SP 文件。 此外、该字符串前面的3个字节的二进制数据将为0x27 0xCA 0x2F。 如果您检查字符串+这3个字节并在日志中看到它、则应正确捕获该字符串并由我的工具解码。

您建议的调试步骤是合理的、我建议这样做、以便为我提供调试问题所需的信息。

至于调试期间的电子邮件或其他直接通信、我们可能能够通过电子邮件安排一些事情。 实际上、我们以前就去年的快速连接问题通过电子邮件进行了回复、因此您应该已经收到了我的电子邮件。 请向我发送一封电子邮件、其中包含您建议的访问计划、我们可以在此处继续讨论。

此致、
Michael

您好、Michael、

感谢这些信息！

我现在将通过电子邮件与您联系。

C é dric