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

您好、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