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.

[参考译文] CC3135:在网络旁路模式下没有来自其他节点的 ARP 消息

Guru**** 2562120 points
Other Parts Discussed in Thread: CC3135, CC3135MOD, UNIFLASH, CC3120

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

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/940864/cc3135-no-arp-messages-from-other-nodes-in-network-bypass-mode

器件型号:CC3135
主题中讨论的其他器件:、 UNIFLASHCC3120

您好!

我正尝试在网络旁路模式下使用 CC3135,正如您在“CC3x20、CC3x35、CC3x30 SimpleLinkTmWi-FiRegistered和物联网网络”中所解释的那样。 用户指南”,第106-107页。 使用 sl_Socket (sl_AF_packet、sl_sock_raw、0)打开的原始套接字运行良好、但有一个烦人的问题:我没有从其他节点接收任何 ARP 消息。 根据您的用户手册,NWP 不应在网络旁路模式下阻止 ARP 消息,但出于某种原因,它不允许消息通过。

请向我提供此问题的解决方案。

谢谢、

Olek Bogush

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

    您好、Olek、

    使用 RAW 套接字时是否收到广播 ARP 消息?

    对于不从其他节点接收 ARP 消息的情况、您能否澄清您注意到的不良行为是什么? 当广播 ARP 请求时,其它节点的 ARP 响应将只定向到请求的主机。 因此、除非 CC3135是 ARP 请求的来源、否则其他节点的响应不会发送回 CC3135。 如果您正在观察到这种情况,则这就是 ARP 的预期行为。

    另一方面、如果您没有看到对 CC3135发送的请求的 ARP 响应、我建议您使用此处的 ARP 示例代码尝试在本地网络上进行测试、以确定问题是否与您的应用代码、本地网络有关、 或原始套接字实现:

    https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/p/845693/3134002#3134002

    请告诉我您的问题是否与查看其他节点对 ARP 请求的 ARP 响应有关、以及您是否需要更多帮助才能使 ARP 在您的代码中工作。

    此致、

    Michael

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

    您好、Michael、

    感谢您的快速回复。

    是的、使用原始套接字时、我不接收广播 ARP 消息。 实际上,我没有收到任何 ARP 消息。

    发送 ARP 请求不是问题。

    请修复您的 ARP 示例代码,在 Wireless_Decode_ARP_Packet()中添加条件语句,例如以下方法:

    void Wireless_Decode_ARP_Packet (char* buf){
    struct arp_HDR* arp1;
    struct arp_ETHIP* ETHIP;
    struct arp_eth_HDR* ethhdr1;
    
    ethhdr1 =(struct arp_spa_thr*);
    arp1 =(struct arp_eHp_hr0>eHp_hr_eDRP*);
    
    (struct_e0>ETHp_eHp_eHp_eHp_e0=n_r_eHp_eHp_eHp_eDRP*);[struct_e0_eHp_eHp_eHp_eHp_eHp_eHp_eHp_eHp_eHp_eHp_eHp_r\n[0_eH0>UDR_eH0_eH0>[0_r_eH0_eH0>[r_eH0_eHp_eHp_eHp_
    
    
    
    
    

    此外,在 Wireless_ARP_Test()中,您需要在 sl_Recv()中为缓冲区长度声明至少42个字节。 40字节太短。 我建议在此处设置100字节的实际缓冲器长度:
    RET = sl_Recv (FD、buf、100、0)。

    您可以运行示例代码以查看问题-未收到 ARP 消息。

    谢谢、
    Olek

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

    您好、Olek、

    感谢您对改进 ARP 测试代码的建议。 提供的测试代码是一个非常简单的示例、旨在快速观察第2层 ARP 交换。 因此、有许多区域可以使用一些抛光、包括用于仅尝试解码 ARP 数据包的 eth 类型检查。

    话虽如此、我提供的代码确实起作用、至少在 CC3135设置中是如此。 除了添加类型检查和 sl_Recv()缓冲区更改之外,您是否对我的代码进行了任何修改? 我建议您尝试在诸如 network_terminal 演示之类的准系统演示中运行 Wireless_ARP_Test()函数,以便验证所提供示例代码的行为。

    此致、

    Michael

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

    您好、Michael、

    你错过了我的观点。 为了检测 ARP 消息,您需要使用条件语句过滤这些消息,否则您的 Wireless_ARP_Test()函数将报告设备接收到的所有消息,而不仅仅是 ARP 消息。 我报告了一个错误、而不是代码改进。

    此帖子是关于 CC3135 NWP、而不是 CC3235。 两个单元中的内部代码之间可能存在细微差异。 我建议您先在 CC3135或 CC3135MOD 上进行测试、然后再告诉我它可以正常工作、除非您完全确定 CC3135和 CC3235中的相关固件片段完全相同。

    是的、我在准系统演示中尝试了我的代码。 请检查您的器件。

    谢谢、

    Olek

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

    您好、Olek、

    我在上一篇文章中输入了一个拼写错误。 在我之前的帖子中向您提供我的建议之前、我当然已经测试了 CC3135器件上的代码、以确保其按预期工作。 我已编辑了我之前的帖子以反映这一点。 我还在另一台设备上测试了相同的代码、ARP 功能正常工作、因此我很确定问题出在您的端、而不是我的代码中。

    作为完整性检查、您是否记得修改 Wireless_BUIL_ARP_Packet ()中的 mac[]和 src_IP[]数组、以便它们具有您的 CC3135器件参数? 如果 ARP 数据包包含错误的 src MAC 和 IP、则永远不会返回到 CC3135。

    此致、
    Michael

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

    您好、Michael、

    我已使用其他两个开箱即用的 CC3135 BoosterPack 检查设置。 它们的工作方式略有不同;我收到的是 ARP 消息、但只能持续很短的时间。 在接收 ARP 消息时,我将收到两个 NetApp 事件:第一个#9 (sl_NetApp_EVENT_DHCP_IPv4_Acquire_timeout),然后一段时间后,第一个事件(sl_NetApp_EVENT_IPv4_Acquired)。 之后,没有收到 ARP 消息。

    同时,我的网络应用程序都被禁用。 我正在使用以下命令检查其状态:

    SL_NetAppGet (SL_NetApp_STATUS、SL_NetApp_STATUS_ACTIVE_APP、&u8AppBitMapLength、(_u8 *)&u32AppBitMap);

    它返回 u32AppBitMap 中的所有零、返回代码为零。 如果我发布:

    SL_NetAppStop (SL_NetApp_HTTP_Server_ID | SL_NetApp_DHCP_Server_ID | SL_NetApp_MDNS_ID);

    返回代码为0x183B。 它是正的、这意味着它不是一个误差、也不是 OK 的零。 这意味着什么?

    我的第一个 Booster Pack 使用 UniFlash 在配置中禁用了所有网络应用。 它没有收到任何 ARP 消息,也没有收到任何 NetApp 事件。

    我希望您可以为我提供权变措施或让 TI 解决该问题。

    谢谢、

    Olek

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

    您好、Olek、

    我已使用默认设置对 CC3135进行了编程、仅对最新的服务接收器进行了编程、并且没有更改其他设置。

    能否复制我已经完成的步骤、看看您是否仍然没有收到 ARP 数据包?

    1. 从 SDK 导入 network_terminal 示例
    2. 确保您已完成正确的移植步骤、以便使 network_terminal 示例在您的 plaForm 上正常工作
    3. 通过运行 wlanconnect 命令、ping 命令等测试 network_terminal 示例
    4. 将现有 wlan_cmd.c 替换为以下附加 wlan_cmd.c 文件:/cfs-file/__key/communityserver-discussions-components-files/968/0246.wlan_5F00_cmd.c
    5. 使用设备的 IP 和 MAC 地址修改 Wireless_BUIL_ARP_Packet(),并提供 LAN 上设备(如 AP)的 IP 地址。 您将需要修改 MAC[]、src_IP[]和 dest_ip[]。
    6. 重新构建并运行 network_terminal 示例
    7. 示例运行后、使用 wlanconnect 连接到 Wi-Fi、然后使用'p2pstart'命令执行 ARP 请求

    您是否看到 ARP 请求成功执行? 您是否在 AP WLAN 接口上使用了 Wi-Fi 无线监听器或数据包捕获来确保 AP 正确接收 ARP 流量? 我建议您使用监听器来检查并确保 ARP 被 AP 破解、然后重新广播到您的 LAN。

    如果您仍在处理 ARP 请求时遇到问题、请转至并从设备收集 NWP 日志。 相关说明可在以下网址找到:https://processors.wiki.ti.com/index.php/CC3120_%26_CC3220_Capture_NWP_Logs

    捕获日志的步骤在 CC3120+CC3220和 CC3135之间是相同的。

    拥有这些日志将使我能够查看您的设备的运行状态、如果您能提供这些日志、我将不胜感激。

    此致、
    Michael

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

    您好、Michael、

    我们的对话方向错误。 如果您还没有这样做、请将我的电子邮件转发给 TI 固件团队。

    谢谢、

    Olek

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

    您好、Olek、

    作为此问题的调试过程的一部分、我需要能够重现您看到的问题、或者收集在我的末尾深入了解固件所需的信息以找出根本原因。 到目前为止、我们一直致力于成功复制您的问题、并一直致力于收集我和我团队其他成员所需的信息、以了解我们无法复制您的用例的原因。

    因此、如果您能够提供 NWP 日志、执行调试任务并提供所请求的信息、我将不胜感激。 请放心、您的主题涉及相关团队。

    此致、

    Michael