• 状态 Resolved
  • 已锁定 已锁定
  • 回复 10 回复
  • 订户 0 订户
  • 视图 318 视图
  • 用户 0 会员在此处
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] CC3220MOD：DHCP 服务器

admin
Guru**** 2563430 points


请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/802336/cc3220mod-dhcp-server

器件型号：CC3220MOD

您好、社区

在连接许多客户端时重新启动设备时，DHCP 服务器出现问题。 为了更详细地解释我们的应用、我们使用两个 cc3220、一个用作 AP 一、充当具有静态 IP 的客户端。 然后、我们为剩余的点连接三个 I 焊盘。 两个单元都将 UDP 数据发送到三个 I-pad。 因此、我们让 AP 将其客户端列表发送到另一个 cc3220。 我们将 SDK3.10与 FreeRTOS 配合使用。

我们看到两个问题：  

在关闭和打开 AP 时、我们看到一些 I-pADS 会自动重新连接到接入点、但未列在已连接的客户端列表中(sl_NetCfgGet (sl_netcfg_AP_STATIONS_INFO_LIST))。 从 WiFi 断开 I-pad 并重新连接时、一切都正常。 通过单击"续订租赁"也有效！

2.同样、当关闭和打开 AP 时、另一个 cc3220设备将继续扫描、并在 AP 再次显示时重新连接。 收到后(正确！) 列出了 AP 中的列表并正确地将 sl_SendTo 调用到所有已连接的 IP，我们看到(有时(很难重现))消息没有到达 i-pad！ 就像 AP 不知道该 IP 已连接。  

3.侧面问题：我们还观察到、即使在硬复位之后、I-pADS 也往往会获得相同的 IP。 这是否意味着 CC3220 DHCP 服务器将 MAC 地址存储在 NVM 中存储的表中？ 这似乎与上述问题相关、因为它看起来始终是不接收数据的同一 IP (和设备)。  

为解决此问题，我们尝试将租用时间设置为0，但我们遇到参数错误(SL_ERROR_INVALID_PARAM)！ 最小值似乎是60。 是否可以通过其他方式将租用时间设置为0？

5.它是否可以是您在 SDK3.10中更改的内容？ 因为在更新到 SDK3.10之前、我们没有看到此问题。 (我们将进行更多测试以确认这一点...)

非常感谢！

Vincent Vuarnoz

  • 0
    TI__Guru**** 2563430 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    尊敬的 Vincent：

    看到此事件的一些 NWP 日志很有意思。 请尝试此操作(首先在 AP 侧收集日志)。 我还想了解您是否对所有静态 IP 地址都有相同的行为。
    processors.wiki.ti.com/.../CC3120_&_CC3220_Capture_NWP_Logs

    2.您应该使用监听器来尝试捕获 AP 是否实际发送了数据包。 SL_Sendto 用于不是可靠传输方案的无连接套接字。 不保证交货。

    3.不可以，DHCP 服务器不应在 NVM 中存储 MAC 地址和以前租用的 IP ...我的预期是其他 STA 可能会在重新连接时使用 DHCP 快速续订功能来再次获取相同的 IP 地址。

    4、不、没有办法做到这一点。

    5.此 SDK 中的器件的这种行为不应发生任何变化。

    此致、
    本·M
  • 0
    TI__Guru**** 2563430 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好 Ben、

    感谢您的回复！
    我对此问题有一个可能的解释：启动应用程序时、器件会记住其"AP 设置"并立即创建 AP。 然后、我们完成设置过程并重新启动器件、以确保应用所有设置。 因此、可能会有一个 I-pad 连接到"第一个"AP、然后 CC3220重新启动、然后出现上述错误匹配...
    为解决此问题、我们正在考虑在完成 AP 设置(！！)后将角色设置为 STA。 这是因为即使持久性设置设置为0、角色仍是持久的...

    1.是的，唯一的问题是很难重现。 我将看到我可以做什么。 在捕获日志时、UART 0是否可以用于其他目的、或者必须专用于 NWP 日志输出？
    2、我们将在下一次发生时执行该操作。
    3、还可以。
    4.太糟糕了
    5、还可以！

    此致
    文森特五
  • 0
    TI__Guru**** 2563430 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好 Ben、

    我在交通发生时捕获了交通信息。 我在这里附加了这些内容。 或许它可以帮助您了解正在发生的情况...

    SSID：Cat Max (XXXXXXX)、PW：86912255

    提前感谢！

    e2e.ti.com/.../CC3220-sniffing.zip

    编辑：进一步调查显示它可能与租用时间相关。 现在、通过创建 AP、将 I-PAD 连接到 AP (这将获得 DHCP 地址范围内的第一个 IP)、在 I-PAD 上关闭 WiFi、等待租用时间、再次连接新 I-PAD、我能够持续复制 (它将获得与另一个 I-pad 相同的 IP)，然后是！ AP 将其数据发送到 I-PAD、但不会发送另一个使用静态 IP 连接到它的 cc3220。

    现在、神秘部分... ：如果我们关闭并再次打开另一个 cc3220 (具有静态 IP 的客户端)，则一切都将再次正常！ 这对我来说非常奇怪、因为这种"静态客户端"可以向 AP 发送 UDP 消息、同时还会发生错误！！！ 然后、我认为重新启动客户对这种情况产生影响是没有意义的。 但我希望大家对此有一个很好的解释。

    我可以想象这对你们来说是一个有趣的问题，我想帮助你们再现！

  • 0
    TI__Guru**** 2563430 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好 Ben、
    你一定要来看看！

    查看我最后一条消息的"编辑"部分...

    +这是发生的错误的 NWP 日志

    e2e.ti.com/.../8637.reproduce-htcp-bug.log

  • 0
    TI__Guru**** 2563430 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Vincent：

    我已经查看过日志、但老实说、我看不到您描述的整个序列。 我看到网络处理器多次重新启动。 我看到设备以 AP 模式启动、DNS/DHCP/HTTP 服务器已启动并正在运行。 然后、我看到对设备设置进行了一些修改、DHCP 服务器重新启动。

    之后、我看到一组 WLAN 配置和 netconfig get/set 调用。 我看到 HTTP 服务器重新启动(禁用/重新启用)。 然后重新启动整个网络处理器。

    在最后一个序列(重新启动后)中、我看到多个套接字已打开、并且从一个 STA (MAC 以07：E2：1c 结尾)处理验证。 日志似乎在那里停止。

    根据你跑过/观察到的内容、这似乎是正确的吗？ 问题是否在捕捉结束时发生？ 当日志停止时、系统会执行什么操作？

    谢谢、

    本·M

  • 0
    TI__Guru**** 2563430 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好 Ben、

    感谢您对此进行深入研究。

    下面是该过程的更详细版本(我们有两个 cc3220、一个用作 AP、一个用作客户端、这里是所谓的"cc3220-AP"和"cc3220-STA")。 我这次从两侧(AP + STA)创建了新的 NWP 日志。

    cc3220-AP MAC： 98：84：E3：4F：98：A4

    cc3220-STA MAC： 98：84：E3：4F：AC：91

    I-PAD #1 MAC： 34：E2：FD：D5：1B：B5

    I-PAD 2 MAC：78：67：D7：A4：D1：2D

    1.启动 cc3220-AP，创建 AP (IP 192.168.5.100)

    2.启动 cc3220-STA，该器件将使用静态 IP (192.168.5.99)查找并连接到 cc3220-AP 的网络

    3.连接 I-pad #1，从 DHCP 服务器获取地址192.168.5.101。

    4. AP 将通过 UDP 消息将已连接客户端(1个客户端)的列表发送到 cc3220-STA。 (因此 cc3220-STA 知道它必须向哪个 IP 发送数据)

    5.空闲情况：两个 cc3220都向 I-pad 发送 UDP 消息。 ->正常工作！

    6、现在。 断开 I 焊盘#1的连接

    7.等待租用时间(在本例中为60秒)

    8.连接 I-PAD #2！ 因为租用时间已过期，所以它将获得相同的地址(192.168.5.101)

    9. AP 将再次通过 UDP 将连接的客户端列表发送到 cc3220-STA (我们可以看到情况！)

    cc3220-STA 具有正确的已连接设备列表(1个客户端)并尝试向 I-pad #2发送数据、但数据不会经过...

    哇！

    注：重新启动 cc3220-STA 后，它将再次运行！ 这是令人困惑的、因为问题似乎出现在 AP 中、AP 不会转发数据、但显然不...

    e2e.ti.com/.../teraterm-05_2D00_06_2D00_19-AP.log

    e2e.ti.com/.../teraterm-05_2D00_06_2D00_19-STA.log

  • 0
    TI__Guru**** 2563430 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好 Ben、

    您是否能够重现？

  • 0
    TI__Guru**** 2563430 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Vincent：

    我无法设置和复制此内容。 我正在加入另一位团队成员、但我无法对此进行调查。

    此致、
    本·M

  • 0
    TI__Guru**** 2563430 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Vincent：

    我已使用两个 CC3220 LaunchPad + 2个非 CC3220器件重复您的设置、结果相同。 但是、从我的调查来看、CC3220器件似乎按预期工作。

    以下序列是我在重现测试用例时观察到的内容、并对涉及的各种器件的行为进行了解释：

    第一个 CC3220在 AP 模式下启动、并提供 IP 地址10.123.45.1

    2.在 STA 中启动第二个 CC3220 (在后续章节中称为 STA！CC3220)、与 AP 关联并获取 IP 地址10.123.45.2。  

    3.第一个非 CC3220设备(在我的情况下是 Ubuntu 设备)连接到 AP 并获得10.123.45.3。 一旦有 IP、它就启动 UDP 服务器并侦听数据包。

    STA!CC3220将 UDP 流量发送到10.123.45.3。 由于在其 ARP 表中没有该 IP 地址上的设备 MAC 地址、因此它会以广播形式发送 ARP 请求。

    5.具有10.123.45.3的设备使用其 MAC 地址响应 ARP 请求。 STA！CC3220一旦拥有 MAC 地址、就会开始发送定向到该 MAC 地址的 UDP 数据、该地址由 AP 重新传输并在器件端正确接收 到目前为止、一切都按预期工作。

    6.具有10.123.45.3的设备与 AP 断开连接。 AP 立即将该设备的 MAC 地址与 BSS 解除关联。 然后、当60秒的租用时间开始时、AP 还会将 IP 释放到 DHCP 池中以供重复使用。

    7.第一台设备断开连接大约2分钟后、另一台设备(在我的情况下是 Android 手机)连接到 AP。 它获取 IP 地址10.123.45.3。 这是合理的、因为 IP 租赁已过期、可以安全地重复使用。

    8.带有10.123.45.3的新设备启动 UDP 服务器以侦听数据包。

    9. STA！CC3220开始将 UDP 流量发送到10.123.45.3。 它不发送新的 ARP 请求、因为其 ARP 表中的上一个条目尚未过期。 因此、它会将数据发送到上一个器件的 MAC 地址。 由于 UDP 没有反馈机制、因此 STA！CC3220将继续向错误的 MAC 地址发送数据。 但是、这不是意外或错误行为。 设备的802.11堆栈使用 ARP 表来处理 MAC 地址/IP 地址关联、如果没有任何异常行为、它将不需要刷新特定关联、直到其过期。 如果您要手动清空 ARP 表、或只是使用 TCP 发送数据、STA！CC3220会更新该 ARP 表、然后将数据发送到正确的 MAC 地址。

    10.接入点看到来自 STA！CC3220的802.11数据，目标设备与未关联设备的 MAC 地址相连。 由于设备与其网络没有关联、因此不会重新传输数据包。 这是预期行为。 即使是重新传输数据包、新器件也不会接收任何数据、因为 STA 发送的帧中的目标 MAC 地址与自己的 MAC 地址不匹配。

    上述事件的顺序没有任何无法解释的或违反802.11标准的行为。 如果您认为存在问题、请告诉我 CC3220违反了规范的章节、我很乐意再次查看、因为我对规范的理解可能不正确。

    唯一可能的特定于 CC3220实施的问题与 ARP 条目到期条件有关。 CC3220上的 ARP 条目应在几分钟后过期、这通常不会造成问题、除非 IP 地址像在您的用例中那样频繁地重复使用。 但是、如果您怀疑新器件已加入网络、则在执行 UDP 发送之前手动清除 STA！CC3220上的 ARP 表、则可以避免出现此问题。 实际上、通过在测试中重新启动 STA！CC3220、您会意外地执行 ARP 刷新、因为 ARP 表存储在易失性存储器中。

    您可以调用一个 API 来执行 ARP 刷新： sl_NetAppArpFlush()。 此 API 非常安全、不会导致闪存写入、因此如果您愿意容忍 ARP 请求延迟、您甚至可以在每次 UDP 突发传输之前调用它。 刷新 ARP 表后、CC3220将强制发送 ARP 请求以获取最新的 MAC 地址、这将阻止 UDP 数据包发送到错误的 MAC 地址。  

    请告诉我、您是否需要进一步澄清我的解释、或对此问题有进一步的疑问。

    此致、

    Michael

  • 0
    TI__Guru**** 2563430 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    嗨、Michael、

    非常感谢您花时间查看此内容并提供详细的描述！ 我对此表示赞赏。

    这很有意义、一切都很有意义。 我同意、行为完全符合802.11标准。

    您是否知道 ARP 条目的确切到期时间？ (租赁时间为10分钟、我们也看到了同样的行为)。 我们现在已将租赁时间设置为17天...

    好的、我将尝试 SL_NetAppArpFlush API。 这似乎是一种更清洁的方法。  

    再次感谢！