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.

[参考译文] WL1835MOD:UDP 广播消息最多可丢弃60秒

Guru**** 2561860 points


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

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/886708/wl1835mod-udp-broadcast-messages-drop-for-up-to-60-seconds

器件型号:WL1835MOD
Thread 中讨论的其他器件:WL1835
我们的工程团队正在开发新产品。 我们注意 到、周期性 UDP 广播偶尔会停止通过 WiFi 传输长达一分钟。 我们将在设计中使用 WiLink 8。
我想简要概述一下我们的产品是如何工作的以及它与我们发现的问题有何关系:
我们的电路板设计基于 BeagleBone Black Wireless。 我们在 Octavo OSD3558上运行 Linux。 TI WL1835连接到 Octavo 芯片。 无线接入点正在通过 hostapd 在设备上运行。
另一个连接到器件的选项是 USB。 我们使用 远程网络驱动程序接口规范(RNDIS)模拟 USB 上的以太网。
USB 和 WiFi 网络接口都连接到桥接接口。 DHCP 服务器在此桥接接口上运行,为客户端提供网络上的 IP 地址。
在 Linux 系统上、有一个正在运行的应用程序提供 TCP 服务器、供用户连接到设备并与设备进行交互。 同一应用程序还以1秒的间隔广播 UDP 消息、其中包含一些器件信息。
现在、我们要解决的问题是:如果用户(PC)通过 WiFi 连接到设备、则 UDP 消息偶尔不会在 PC 上接收到。 有时、所有 UDP 广播消息都将丢失长达60秒。
我确认消息是由我们的应用程序创建和发送的、还确认消息是由网络接口使用 Wireshark 发送的。 我很确定问题与 WiLink 8固件有关、稍后将对此进行详细介绍。
如果设备通过 USB 连接到 PC、则不会出现此问题。 测试证实了这一点。
如果频繁断开/连接到设备的 WiFi 接入点、则问题会更频繁地发生。 我编写了一个 Python 脚本、每30秒重新连接一次、并监听 UDP 消息。 我能够非常一致地重现此问题。
这就是我认为问题与 WiLink 8固件有关的原因:行为因固件版本而异。
我最初使用 Rev 开始测试  8.9.0.0.69。每当 UDP 消息开始丢失时、我都会尝试通过 SSH 发送字符、以查看这是否是常规连接问题、或者问题是否仅与 UDP 广播有关。 我完成此操作后、WiLink 驱动程序的软件看门狗将触发并重新启动器件。 硬件恢复后、我会一次接收所有之前缺失的 UDP 消息。 以下是错误日志:
[2508.883177] wlcore:收到错误 SW 看门狗中断! 正在开始恢复。
[2508.890336]------ [在此处剪切]-----
[2508.895295]警告:CPU:0 PID:138 at drivers/net/wireless/ti/wlcore/main.c:796 wl12xx_queue_recovery_work +0x80/0x84 [wlcore]
[2508.906893]链接的模块:CCM ARwlcore_SDIO wl18xx wlcore 18xx wlcore_work +0x802438437:c4 CCS_c38802438437_c4
:g_c4:c3880248024802410_g_g_g_g_g_g_g_cp80248024802410 W 4.9.56-AML #1
[2508.924856]硬件名称:通用 AM33XX (平展设备树)
[2508.931033][ ](展开回扫)从[ ](show_stack+0x20/0x24)
[ 2508.938839][ ](show_stack)从[ ](dump_stack+0x24/0x28)
[2508.946121][ ](dump_stack)从[ ](__warn+0xec/0x110)
[2508.953139][ ](__warn)从[ ](warn_slespath_null+0x30/0x38)
[2508.960900][ ](warn_slowpath_null)、来自[ ](wl12xx_queue_recovery_work + 0x80/0x84 [wlcore])
[2508.971304][ ](wl12xx_queue_recovery_work [wlcore])、来自[ ](wlcore_IRQ+0x1F4/0x238 [wlcore])
[2508.981824][ ](wlcore_IRQ [wlcore])、来自[ ](IRQ_thread_fn+0x2C/0x64)
[2508.990165][ ](IRQ_THREAD_Fn)、来自[ ](IRQ_THREAD+0x14c/0x20c)
[2508.997886][ ](IRQ_THread)、来自[ ](kthread+0x120/0x128)
[ 2509.005077][ ](kthread)、来自[ ](RET_FAND_FANK+0x14/0x3c)
[2509.012347]--[结束跟踪49f3e48f119ca9fd ]--
[2509.018638] wlcore:正在进行硬件恢复。 固件版本:版本8.9.0.69
2725 [2509.026791] wlcore:PC:0x109650、HINT_STS:0x00000000计数:3
[ 2509.033557] wlcore:down
[ 2509.037593] ie80211 phy0:已请求硬件重新启动
[2509.469982] wlcore:PHY 固件版本:版本2509.0.20.936.12.9982]
(版本:版本2508.0.20.00.236.00.0) 
我注意到、有一个新的在线固件版本可修复频繁的软件看门狗中断。 我更新为修订版  8.9.0.0.79。
新固件版本未解决 UDP 广播的问题、但行为现在发生了变化。 周期性 UDP 消息仍然会丢失、但通过 SSH 发送数据不会再触发 SW 看门狗。 此外、丢失的 UDP 消息现在会丢失、并且在恢复后不会立即发送所有消息。 当没有发送 UDP 广播时、SSH 将继续工作。
我执行了另一项测试、在该测试中、我将相同的 UDP 消息发送到 PC 的 IP 地址、而不是广播它。 这种情况很好、流从未下降。
这是 TI 的已知问题吗? 是否有任何已知的修复程序?
如果需要更多详细信息、请告知我。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!  

    感谢您发送信息!! 更新固件的详细信息。 您是否还更新了驱动程序? 请告诉我。  

    如果我正确理解这一说法、您将 WL8器件用作 AP、每秒向连接的客户端发送一次广播 UDP 消息? 此外、请告诉我们有多少客户已连接。 如果有多个客户端、是否所有客户端都丢失了数据包?  

    此致、  

    Sudharshan K N

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

    您好、Sudharshan、

    不、我没有更新驱动程序。 我正在尝试了解我的驱动程序版本、但就我所见、除非我使用 TI 提供的构建脚本构建它、否则无法实现该版本?

    我正在使用4.9.56 Linux 内核中的树内驱动程序。

    我不确定应该如何更新我的驱动程序版本、因为编译脚本似乎不支持内核版本4.9。

    您对我的问题的总结是正确的。 只有一个客户端连接到设备。 我尚未对多个连接的客户端进行任何测试、但必要时可以进行测试。

    谢谢、

    Andi

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

    您好!  

    让我检查一下4.9.56是否需要更新驱动程序。 您能告诉我们流量是如何生成的、以查看我们设置中的行为吗?  

    此致、  

    Sudharshan K N

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

    您好、Sudharsan、

    我们的应用每秒通过套接字将 UDP 广播发送到255.255.255.255。

    消息有效载荷与以下内容类似:
    {"仪器":{"WIFI":"172.18.127.2"、"SSID":"AML_BEAG04"}、"位置":{"lon":0.00000、"lat":0.00000、"sat ":6、"HDOP":2.23、"tlf":0}、"time ":"lat":"000"、"AM"、"000"、"AM"、"000":"000"、"000"、"000"、"AM"、"000"、"000":"000"、"000"、"000"、"000"、"000"、"000"、"000"数据:"000"、"000"、"000"、"000"、"000":"000"、"000"、"000"数据:"000"、"000"、"000"、"000":"000"、"000

    您是否需要一些示例代码?

    Andi

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

    您好!  

    让我检查一下我是否可以使用 iPerf 命令获得相同的流量。 我们更喜欢使用 iPerf、因为这在我们结束时更容易 让我返回到您的测试。  

    此致、  

    Sudharshan K N

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

    我还编写了一个 Python 脚本来重现此问题。 它每30秒执行一次到 WiFi AP 的重新连接、侦听 UDP 消息、并在 UDP 消息停止广播时通知用户。

    如果您想使用脚本、我可以向您提供该脚本。 我在 Ubuntu 上使用 nmcli 重新连接 WiFi、因此它可能无法在 Windows 计算机上正常工作。

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

    您好!  

    如果客户端已连接、是否有使用多播消息而不是广播的选项? 可以为两个器件设置桥接器地址、并将消息路由到桥接器地址。 请告诉我您的想法

    此致、  

    Sudharshan K N

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

    您好、Sudharshan、

    我今天将广播更改为多播、并进行了一些测试。

    当我使用多播而不是 WiLink8广播时、存在完全相同的问题。 消息最多可拖放60秒。

    您是否能够在最终重现此问题?

    Andreas

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

    安德烈斯、您好!  

    我使用多播执行了 AP-STA 模式测试。 但我的测试持续了几分钟。 我正在使用 iPerf 进行测试。 下面是测试的详细信息  

    路由添加-host 239255.1.3  

    route add -host 239255.1.3 wlan1 <--对于我在 AP 端的示例

    route add -host 239255.1.3 wlan0 <-在基站侧  

    iperf -s -B 239.255.1.3 -u -f m -i 5和-->在 AP 侧

    iperf -c 239.255.1.3 -u -b 10M -f m -i 5 -t 30 -S 0x10 &-->在站点侧

    这里每5秒发送一次数据。  我可以将其增加到60s 并进行检查。 生成的流量是 UDP。  

    您能告诉我重现此问题需要多长时间吗? 我可以运行更长的测试、并检查我是否看到问题。  

    此致、  

    Sudharshan K N

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

    您好 、Sudharshan、

    此问题主要发生在客户端经常断开并重新连接到工作站的情况下。

    我可以尝试在您的上一个帖子中使用 iperf 命令在我的末尾重现此问题。

    现在、我使用 Python 脚本自动进行 WiFi 重新连接。 我可以改用 bash 脚本。 您在进行测试的机器上是否有 nmcli 可用?

    Andreas

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

    我能够重现与 iperf 相同的问题。 此问题可在运行脚本后的10分钟内重现。

    以下是包丢失的一个示例日志:

    ----------------------------------------
    在 UDP 端口1031上侦听服务器
    绑定到本地地址239.255.1.3
    加入组播组239.255.1.3
    接收1470字节数据报
    UDP 缓冲区大小:208KB (默认值)
    ----------------------------------------
    [3]本地239.255.1.3端口1031与172.18.127.2端口44665相连
    [ ID]间隔传输带宽抖动丢失/总数据报丢失
    [3] 0.0- 1.0秒1.44 KB 11.8千位/秒0.000 ms 215/216 (1e+02%)
    [3] 1.0- 2.0秒1.44 KB 11.8千位/秒0.107 ms 0/1 (0%)
    [3] 2.0- 3.0秒1.44 KB 11.8千位/秒0.117毫秒0/1 (0%)
    [3] 3.0-4.0秒1.44 KB 11.8千位/秒0.134毫秒0/1 (0%)
    [3] 4.0- 5.0秒1.44 KB 11.8千位/秒0.188毫秒0/1 (0%)
    [3] 5.0-6.0秒1.44 KB 11.8千位/秒0.178毫秒0/1 (0%)
    [3] 6.0- 7.0秒1.44 KB 11.8千位/秒0.248 ms 0/1 (0%)
    [3] 7.0- 8.0秒1.44 KB 11.8千位/秒0.239 ms 0/1 (0%)
    [3] 8.0- 9.0秒0.00 KBytes 0.00 KBbits/sec 0.000 ms 0/0 (0%)
    [3] 9.0-10.0秒0.00 KBytes 0.00 KBbits/sec 0.000 ms 0/0 (0%)
    [3] 10.0-11.0秒0.00 KBytes 0.00 KBbits/sec 0.000 ms 0/0 (0%)
    [3] 11.0-12.0秒0.00 KBytes 0.00 KBbits/sec 0.000 ms 0/0 (0%)
    [3] 12.0-13.0秒0.00 KBytes 0.00 KBbits/sec 0.000 ms 0/0 (0%)
    [3] 13.0-14.0秒0.00 KBytes 0.00 KBbits/sec 0.000 ms 0/0 (0%)
    [3] 14.0-15.0秒1.44 KB 11.8千位/秒0.257毫秒6/7 (86%)
    [3] 15.0-16.0秒0.00 KBytes 0.00 KBbits/sec 0.000 ms 0/0 (0%)
    [3] 16.0-17.0秒0.00KBytes 0.00Kbits/sec 0.000 ms 0/0 (0%)
    [3] 17.0-18.0秒0.00 KBytes 0.00 KBbits/sec 0.000 ms 0/0 (0%)
    [3] 18.0-19.0秒0.00 KBytes 0.00 KBbits/sec 0.000 ms 0/0 (0%)
    [3] 19.0-20.0秒0.00 KBytes 0.00 KBbits/sec 0.000 ms 0/0 (0%)
    [3] 20.0-21.0秒0.00 KBytes 0.00 KBbits/sec 0.000 ms 0/0 (0%)
    [3] 21.0-22.0秒0.00 KBytes 0.00 KBbits/sec 0.000 ms 0/0 (0%)
    [3] 22.0-23.0秒0.00 KBytes 0.00 KBbits/sec 0.000 ms 0/0 (0%)
    [3] 23.0-24.0秒0.00 KBytes 0.00 KBbits/sec 0.000 ms 0/0 (0%)
    [3] 24.0-25.0秒0.00 KBytes 0.00 KBbits/sec 0.000 ms 0/0 (0%)
    [3] 25.0-26.0秒0.00 KBytes 0.00 KBbits/sec 0.000 ms 0/0 (0%)
    [3] 26.0-27.0秒0.00 KBytes 0.00 KBbits/sec 0.000 ms 0/0 (0%)
    [3] 27.0-28.0秒0.00 KBytes 0.00 KBbits/sec 0.000 ms 0/0 (0%)

    为了更好地反映我的应用程序、我对 iperf 命令进行了一些小调整。

    这是我在 PC 上运行的 bash 脚本。 它每30秒重新连接到 WiFi AP、并启动将接收 UDP 多播数据包的 iperf 服务器。

    !/bin/bash
    
    wifi AP="AML_BEAG04"
    Iperf_CMD="iperf -s -B 239.255.1.3 -u -f k -i 1 -p 1031"
    wlan_if="wlp2s0"
    
    
    while true
    do
    nmcli 启动${wifi _AP}
    睡眠1
    route add -host 239255.1.3 $WLAN_IF
    $Iperf_CMD 和
    休眠30
    kill -SIGKILL $(ps -a | grep iperf | grep -v "gep"| cut -d "-f1)
    睡眠1
    nmcli con down ${wifi _AP}
    睡眠1
    完成
    

    以下是我使用 WiLink 8在设备上运行的命令:

    route add -host 239255.1.3 wlan0
    iperf -c 239255.1.3 -u -b 1K -f m -i 1 -t 600 -p 1031 -f k

    我先启动 bash 脚本、然后等待连接到 WiFi 且 iperf 正在运行。 然后启动 iperf 客户端。

    iperf 客户端将持续运行、并且在 WiFi 重新连接之前、iperf 服务器将每隔30秒被终止。
    每次 iperf 重新启动时、您将看到服务器报告的数据包丢失、因为客户端持续运行。

    我能够在5分钟内重现这些命令/脚本的问题。

    Andreas

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

    您好!  

    我使用2个 WiLink8设置进行测试。 一个用于 AP 模式、另一个用于基站。流量通过 iPerf 启动。  

    此致、  

    Sudharshan K N

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

    您好 、Sudharshan、

    您是否看到了我的最新帖子? 我提供了有关如何重现此问题的详细说明。

    您是否能够使用我的说明重现问题?

    谢谢、

    Andreas

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

    您好!  

    目前您使用的是 FW 版本8.9.0.0.69。 您能否尝试使用最新版本的 R8.7_SP3。 并检查问题是否仍然存在?  

    是否还有断开连接的原因?  

    此致、  

    Sudharshan K N

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

    您好!

    我使用的固件版本 是最新版本8.9.0.0.79。

    我无法将驱动程序更新为 R8.7_SP3、因为 TI 编译脚本不支持 Linux 内核 4.9.56、正如我之前提到的。 据我所知、TI 为此内核版本推荐了内核驱动程序。

    正如我一开始提到的、这个问题主要发生在频繁的 WiFi 站点重新连接上、并且更容易重现。 这就是断开连接的原因。

    您是否仍在努力重现此问题?

    此致、

    Andreas

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

    您好!  

    很抱歉我没收到上一次答复。 我将深入研究并返回给您。  

    此致、  

    Sudharshan K N

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

    您好!  

    我能够重现此问题、仅凭 ifconfig wlan1向下/向上不足以恢复 AP 接口。 恢复 AP 所需的命令包含在 ap_start.sh 和 ap_stop.sh 脚本中。 这些脚本位于 AM335 SDK Installed 文件夹中的/usr/share/wl18xx 文件夹中。 我已将这些文件的内容附在下面。  

    在 ifconfig wlan1 down 后、运行 ap_start.sh 命令以再次启用 AP。 然后,您可以添加路由并再次启动 iPerf 服务器。 您应该能够看到广播消息。  

    Ap_start.sh  

    root@AM335x-EVM:/usr/share/wl18xx cat ap_start.sh
    !/bin/sh

    ########## 变量########

    wlan=wlan1
    WLAN2=wlan2
    hostapd_proc=/var/run/hostapd
    hostapd_Conf=/usr/share/wl18xx/hostapd.conf
    #hostapd_bin_DIR=/usr/local/bin
    hostapd_bin_DIR=/usr/sbin
    IP_ADDR=192.168.43.1
    IP_ADD2=192.168.53.1
    DHCP_CONF=udhcpd.conf
    DHCP_CONF2=udhcpd2.conf
    DHCP_CONF_PROC=u[d]hcpd.conf
    DHCP_CONF_PROC2=u[d]hcpd2.conf

    ########## 正文######

    ###检查配置文件
    如果[! -f $hostapd_Conf];然后
    如果[! -f /etc/hostapd.conf ]
    然后
    回显"error - no default hostapd.conf file"(错误-无默认 hostapd.conf 文件)
    出口1
    FI
    CP /etc/hostapd.conf $hostapd_Conf
    chmod 777 $hostapd_Conf
    FI

    ###配置 IP 防护
    Echo 1 >/proc/sys/net/ipv4/ip_forward

    ###添加 WLAN 接口(如果不存在)
    如果[! -d /sys/class/net /$wlan ]
    然后
    ECHO "添加$WLAN 接口"
    iw phy `ls /sys/class/ieee80211` interface add $WLAN type managed
    FI

    ###启动 hostapd 接口(如果不存在)
    如果[! -r $hostapd_proc ]
    然后
    $hostapd_bin_DIR/hostapd $hostapd_Conf&
    睡眠1
    FI

    ###配置 IP
    ifconfig $WLAN $IP_ADDR 子网掩码255.255.255.0 up
    如果[-d /sys/class/net /$WLAN2]
    然后
    ifconfig $WLAN2 $IP_ADR2子网掩码255.255.255.0 up
    FI

    ###启动 udhcpd 服务器(如果未启动)
    output=`ps | grep /usr/share/wl18xx \$DHCP_CONF_PROC`
    Set --$output
    ECHO $OUTPUT
    如果[-z "$output"];那么
    udhcpd $DHCP_CONF
    FI

    如果[-d /sys/class/net /$WLAN2]
    然后
    output=`ps | grep /usr/share/wl18xx \$DHCP_CONF_PROC2`
    Set --$output
    ECHO $OUTPUT
    如果[-z "$output"];那么
    udhcpd $DHCP_CONF2
    FI
    FI

    ###配置 NAT
    iptables -t NAT -a POSTROUTING -o eth0 -j 伪装

    root@AM335x-EVM:/usr/share/wl18xx

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

    您好!

    那么、您的建议是、每当 UDP 丢失时、我都会使用提供的脚本重新启动 WiFi AP?

    具有 WiLink8的器件如何确定 WiLink8是否仍在发送多播消息? 驱动程序是否支持此功能?

    终端用户可能连接到我们的设备、但该设备没有 SSH 访问权限、无法重启系统。 在这种情况下、推荐的解决方案是什么?

    固件或驱动程序中是否计划了此问题的修复、固件修复是否有 ETA?

    谢谢你。

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

    您好!  

    此主题中发布的原始日志表示存在 FW 恢复  

    [ 2509.018638] wlcore: Hardware recovery in progress. FW ver: Rev 8.9.0.0.69
    2725 [ 2509.026791] wlcore: pc: 0x109650, hint_sts: 0x00000000 count: 3
    [ 2509.033557] wlcore: down
    [ 2509.037593] ieee80211 phy0: Hardware restart was requested
    [ 2509.469982] wlcore: PHY firmware version: Rev 8.2.0.0.236
    [ 2509.518193] wlcore: firmware booted (Rev 8.9.0.0.69)</span>
    如前所述、请将驱动程序更新为最新的 R8.7_SP3版本(FW - v8.9.0.0.79)、并告知我们问题是否仍然存在。 如果不强制关闭接口并重新启动以重新创建 UDP 丢包问题、我最终无法重现此问题。  
    此致、  
    Sudharshan K N
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

    哦、那时一定会有误解。 正如您在上一篇文章中所述、我对您重现此问题的印象非常深刻。

    原始日志仅适用于 FW 版本8.9.0.0.69、而不适用于8.9.0.0.79。

    您能不能建议我如何使用 Linux 内核版本编译最新的驱动程序版本? TI 编译工具是否有更新?

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

    您好!  

    如果您使用的是 AM335x、则可以从 TI 下载最新的 SDK (http://software-dl.ti.com/processor-sdk-linux/esd/AM335X/latest/index_FDS.html)并使用树内驱动程序。 它们更新为最新的 R8.7_SP3  

    此致、  

    Sudharshan K N

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

    您好!

    我无法使用 SDK。 我们将使用 buildroot 构建我们的定制 Linux 映像。

    是否有其他选择?

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

    您好!  

    您可以在 https://processors.wiki.ti.com/index.php/WL18xx_System_Build_Scripts 上尝试构建脚本中提到的步骤

    此外、请告知我们您的构建的内核版本  

    此致、  

    Sudharshan K N

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

    您好!

    我尝试使用编译脚本、但遇到了问题。

    我在论坛中进行了快速搜索、发现 TI 员工的一些帖子声称他们不支持我的内核版本。

    我正在使用内核  4.9.56.

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

    您好!  

    很抱歉耽误你的回答。  

    对于内核4.9、无需使用反向端口。 您可以通过为单个组件构建构建来尝试构建吗?

    1. sudo_build_wl18xx.sh openssl
    2. sudo_build_wl18xx.sh libnl
    3. sudo_build_wl18xx.sh iw
    4. sudo_build_wl18xx.sh wpa_supplicant
    5. sudo_build_wl18xx.sh hostapd
    6. sudo_build_wl18xx.sh 固件 à 安装固件
    7. sudo_build_wl18xx.sh CRDA

    此致、  

    Sudharshan K N

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

    您好 、Sudharshan、

    我们用 TCP 订阅服务替换了 UDP 广播以解决该问题。

    感谢您在本主题上的帮助。

    Andreas