[参考译文] WL1831MOD：WiFi 闲置一段时间后、TI 定制主机 apd 消失

admin

Other Parts Discussed in Thread: WL1831, WILINK8-WIFI-NLCP

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

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/946545/wl1831mod-ti-custom-hostapd-disappears-after-wifi-is-idle-for-a-while

器件型号：WL1831MOD
Thread 中讨论的其他器件：WL1831

我们注意到有 R8.8固件和 hostapd 版本、并更新了固件和 hostapd：

版本8.9.0.0.0.85

hostapd v2.9-R8.8+
用户空间守护程序、用于 IEEE 802.11 AP 管理、
IEEE 802.1X/WPA/WPA2/EAP/RADIUS 验证器
版权所有(c) 2002-2019、Jouni Malinen 和贡献者

在使用过程中、AP 看起来比以前更稳定。但我们现在面临的问题是它始终消失
在夜间、没有任何设备连接到 AP。

当 AP 处于"显示"状态时、hostapd 服务会认为一切正常、并且我们知道要检查的任何日志中也没有任何内容。

为了防止这种"睡眠"或发生任何事情、我们尝试阻止芯片进入睡眠状态、但行为没有变化：

$ iw dev wlan0设置 power_save off
$ echo 0 >/sys/kernel/debug/ieee80211/phy0/wlcore/sleep_aut

我们拥有的 hostapd 配置为：
----

interface=wlan0
driver=nl80211
channel=4
ssid=APAP-VAR-default

# g = IEEE 802.11g (2.4GHz)
HW_mode=g
#允许两种类型的身份验证(开放系统、共享密钥)。 仅在
auth_algs=3
#仅 WPA、无 WPA2 (2位)的情况下支持两者
wpa=2
#必需 bu wpa=1根据



超时禁用轮询以断开工作站更有可能
跳过不活动_poll=1







启用配对80211n -提高速度 ie80211n=1 WME_ENABLED WP=1 WMP=WMP_ENABLED PAL=1启用无线密码
RSN/WPA2的密码(默认：使用 wpa_pairwise 值)
RSN_pairwis=CCMP

logger_syslog=-1
logger_syslog_level=1
ctrl_interface=/var/run/hostapd

_________

总之、在几个小时内未连接任何设备后、AP 消失。我们无法检测到这一点、因为 hostapd 状态已全部启动并正在运行。调用 hostapd restart 时、AP 会再次出现。

我们希望保持接入点可用、以便用户能够在早上进行连接。
您是否对如何解决此问题有任何想法？或者至少如何检测情况、以便我们可以使用看门狗重新启动 hostapd。

我们开始探索/sys/kernel/debug/ieee80211/phy0/wlcore 中的内容、看看我是否可以从那里的统计数据和文件中提取任何潜在的提示。到目前为止、潜在的候选对象是
'driver_state'中的'flags'字段、我们注意到它从0x1变为0x19、但我们需要确认这一点并进一步探索。

5 年多前

0 admin 5 年多前

TI__Guru**** 2524460 points

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

您好，

我们不知道这个问题。在夜间测试后运行"iw wlan1 info"后、您会得到什么？您是直接还是直接使用 ap_stop.sh？

谢谢

Saurabh

0 admin 5 年多前

TI__Guru**** 2524460 points

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

我无法确定这个问题以前是否存在(R8.7)、因为我们始终存在 WiFi 不稳定问题、我们必须在凌晨4点实施看门狗重启主机。但在 R8.8之前、AP 几乎始终可用、因此我们容忍"错误"问题-主要是偶尔出现的 TX 超时。

但现在(R8.8固件和 hostapd)、它在闲置一段时间后始终消失。

我怀疑探测请求(Wifi 扫描？) 使其保持活动状态的时间更长、因为我们编写了一个脚本、循环检查另一台计算机上的 SSID 是否仍然有效、如果该脚本正在运行、则该脚本会减少消失的频率。

夜间、或当 SSID 处于无法检测的状态且 hostapd 状态为 OK 时、`iw wlan0 info`返回。我们的所有测试设备的妻子都在早上死亡：

iw wlan0信息
接口 wlan0
ifIndex 6.
WDEV 0x1
地址78：04：73：ed：dd：B7
SSID SSID 名称
键入 AP
wiphy 0
通道4 (2427MHz)、宽度：20MHz、中心1：2427MHz
Txpower 20.00 dBm

我想问题是否可能是由于使用了新固件+hostapd 和以前版本的：

- wl18xx.ko
- wlcore.ko
- mac80211.ko
- cfg80211.ko

我使用内核4.9.88 (variscite SOM)编译了新版本(当前主版本、因为并非所有版本都具有 R8.8标签)、但如果我们只是替换它们、则 WiFi 不会启动、因此我们将这些内容保持不变。这可能是由于驱动程序/固件不兼容造成的问题吗？我的想法不是这样、因为自2012年以来这里没有任何变化？： https://git.ti.com/cgit/wilink8-wlan/wl18xx

我们不使用`ap_stop.sh`或`ap_start.sh`、但我们已将其设置为服务、在这里我们用全新的 TI 版本替换了原始/usr/sbin/hostapd。此外、我们从不停止 hostapd、我们希望 AP 始终处于该位置。

0 admin 5 年多前

TI__Guru**** 2524460 points

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

在周末、我们进行了大量测试、并获得了一些新的见解。

1. wlcore 和 wl18xx 在一段时间内没有发生变化，因此，重新编译它们与内核分开是没有意义的(对我们来说很困难)，或者重新编译整个内核。是这样吗？

2.使用相同的固件配置、将 hostapd 和 hostapd.conf 与旧固件(.79)一起使用时会起作用、而(.85) AP 会在大约30分钟的空闲时间内进入睡眠状态。空闲表示没有连接客户端、也没有过多的探测请求。当我们编写一个脚本扫描循环中的可用网络时、为了检测何时它将消失、AP 不会消失、或者它会在太晚后消失。我们需要仔细检查这一点-如果没有连接任何设备、AP 也可能会存活下来、而在连接客户端后、AP 很快就会消失、然后断开连接。
要重现此问题：与客户端连接到 AP、断开连接、使 AP 有0个客户端、请等待...

3.当(.85)固件进入睡眠状态时、通常甚至"服务 hostapd 重新启动"都不起作用、因为它完全崩溃。这就是我们在"hostapd 服务重新启动"后在/var/log/messages 中获得的内容：

rack nf_conntrack iptable_filter wl18xx wlcore mac80211 cfg80211 mxc_v4l2_capture IPU_bg_overlay_sdc IPU_still v4l2_int_device IPU_prp_enc IPU_CSI_IPU_已污染 IPU_CFG_overlcore_sdc wlcore_sdio mxc_sdc

四核数 v4lid_g_g_fu_fu_fu_cru_r 硬件名称：rg_ipc.h 4 x 4 x 8 rf rg_mcr ef rf rg_g_g_g_g_g
[<8010f508>](elree_backtrace) from [<8010b2b0>](show_stack+0x10/0x14)
[<8010b2b0>](show_stack) from [<803bb5b0>](dump_stack+0x78/0x8c+0x100>[<80512ctrack_clar+0x100>]
[<8024_claw_clarn_w8024>[0x8024_clew_clew_w_track+0x100][<8024][<w8520_clew_clew_clew_w_clew_w8024>[0x8024][0x8024_clew_clew_clew_clew_clew_w_clew_clew_w8024][0x8012_clew_clew_clew_clew_clew_clew_w_clewestreest_cles+0x100][<8024][<8012_clew_clew_clew_cles



从[<80356960>](full_proxy_write+0x4c/0x6c)
[<80356960>](full_proxy_write)从[<80202884>](__vfs_write+0x364c/0x364][<80202884>]
(__vfs_write)[<8020804080401s+[<80401ctrend]


(0x80401c+80401ctry+80401c+80248024_write]+[<80248024_write]+[+[<802480248024]+e]+[+e[<80248024802480e]+e]+e[+e[+e]+end[<80248024802480e]+e[+e]+e[+e[+e[+e]+e[<802480248040e]+[+e]+
固件版本：版本8.9.0.0.85
wlcore：PC：0x0，HINT_STS：0x00000068计数：1
wlcore：Down
ieee80211 phy0：请求硬件重启
wlcore：PHY 固件版本：版本8.2.0.245
wlcore：固件启动(版本8.9.0.0.85)
--- [在此处剪切]-----
警告：CPU：0 PID：9794 at net/mac80211/util.c：1899 ie80211_reconfig+0x458/0xc80 [mac80211]
链接的模块：CDC_querybnet MII acether IPT_masade nf_NAT_masade ipv4 contable_nf_nf_nf_ipt_ipt_g_g_rg_unif_ipt_ipt_g_r_ipt_g_un_ipt_g_un_ipt_ipt_un_ipt_ipt_un_ipt_un_ipt_ipt_r_ipt_ipt_r_un_ipt_ipt_ipt_un_ipt_ipt_un_ipt_ipt_ipt_r_un_ipt_ipt_un_ipt_ipt_un_ipt_ipt_ipt_ipt_ipt_ipt_un_ipt_ipt_ipt_
W 4.9.88 #1
硬件名称：Frebbi.MX6 Quad/DualLite (设备树)
工作队列：Events_freezable ieee80211_restart_work [mac80211]
[<8010f508>](elete_backtrace)、来自[[8010b2b0>](show_stack+0x1020+0x8024_remape8024][<x80211>[<8020_remape0_remape8024][<x8020_remape8024][<x8020_e8024][<xe8020_remape8024][<xe8024_e0_e8024>[<x20[_remape20_e8024][<x20_remape20[<xe20_e8020[_e8020_remapeed_e8024][<xe8024][<xe20[<xe20_e20_e20[_remape20][<xe20_e20_e20[_remape80





从[<80140f0c>](process_One_work+0x1d8/0x3f0)
[<80140f0c>](process_One_work)从[<80141af0>](worker_thread+0x38/0x580)
[<80141af0>](worker_thread)[<801444+0x8014044-e80368]-[<80368]-[<80368+eforthe-e8024]-[<80368]-[<80368+e80368]-[<80368]-[<80368]-[<80368]-[<80368]-[<80368]-[<8014+e000e000-
(0x368]-[<8024]-[<

[在此处剪切]-----
警告：CPU：0 PID：9794 at net/mac80211/driver-ops.h：17 drv_remove_interface+0x64/0x6c [mac80211]
wlan0：检查驱动程序中的数据失败、标志：0x0
链接模块：CDC_ether ipc_maskat_nf_ipt_ipt_r_g_ipt_ipt_ng_un_r_ipt_r_ipt_g_ipt_un_r_ipt_g_un_ipt_r_ipt_ipt_ng_un_ipt_un_r_ipt_ipt_r_ipt_r_ipt_r_r_ipt_ipng_r_un_ipt_ipt_un_r_ipt_ipt_r_un_ipt_ipt_r_ipt_un_r_ipt_ipng_r_un_ipt_ipt_un_r_ipt_ipt_ipt_un_ip
9794 Comm：kwork/0：2污染：g W 4.9.88 #1
硬件名称：Frebbi.MX6 Quad/DualLite (设备树)
工作队列：Events_freezable ieee80211_restart_work [mac80211]
[<8010f508>](elete_backtrace)从[<8010b2b0>](show_stack+0x1010/0x14][<8010b508_brack_0008_0008_[<8020_0008_0008_0008_0005_0005_0005_0005_0005_0005_[<8020_00017_0005_0005_0005_00017_0005_0005_0005_[<8020_0005_0005_0005_0005_[<80_00017_00017_00017_00017_00017_0005_0005_[<80_00017_00017_00017_00017_00017_00017_00017_00017_00017_00017_00017_00017_00017_00017_00017_00017_00017_





从[<7f0a65a0>](ieee80211_stop+0x10/0x18 [mac80211])
[<7f0a65a0>](ieee80211_stop [mac80211])从[<80736418>](_dev_close_0x88/0x73808_close)
[<0x738088_close [<8074_cep_s+807428][_dev_close [<0x7380748088_set](0x738088_set_cep_close


)[<8034_close)


从[<80140f0c>](process_one_work+0x1d8/0x3f0)
[<80140f0c>](process_one_work)从[<80141af0>](worker_thread+0x38/0x580)
[<80141af0>](worker_work)[<80141044+IEEE
802.3bt




●(有时 hostapd.service
已从 ECC+8014368+8024>//lib/systemd/system/hostapd.service e+ ECC+803624](ECC+80368+E803624>重新启动)开始)[<8014803640+130e8024](有时已启用)[<803624+130_e+ Ee+ E240e+ Ee+ ECC+8024](有时已启用)
从 Mon 2020-10-12起激活(自动重启)(结果：退出代码) 13
过程：9944 ExecStart=/usr/sbin/hostapd -B /run/hostapd.pid -B B $daemon_OP

OCT 12 13：22：04 mach hostapd[9944]：1602508923.976288：wlan0：ctrl-event-termina
ocT 12 13：22：0322:04:16024_hostapd:16024_prapd:16024:16024_apd:1609904:16024_mapd:1609904:16024_mapd:16024_apd:16024:16024:16024:16024:16024_apd:16024:16024:16024:16024:16024_host:16024_apd:16024:16024:16024:16024_apd:16024_host:16024_

hostapd_interface_free (0x
ocT 12：22：04 mach hostapd[9944]：1602508923.976456：hostapd_free: F
ocT 12 13：22：04 mach hostapd[9944]：1602508923.976468：hostapd_clean_ace


03 (0x1：0524_mach_prisc：1602413:04_prisc hostapd.service:：1602413_prisc：1602413_apd_prisc：1606413:104213:104213:1013:04_6413:104213:1013_pr_6413:0713:85_mapd_6413:mach_6413:0713:mach_hostapd:16024:mace_hostapd:16024:16024:16024:mace:mace:16024:mace:16024:mace:1085
无法启动高级 IEEE 802.11 AP 和 IEE

如果在这之后重新启动硬件、或者执行'modprobe -r wl18xx'后跟'modprobe wl18xx'、hostapd 将再次开始工作。

4.当它停止工作时，固件统计信息不会告诉我们它正在休眠。
Cat DRIVER_ST态| Grep 标志= 0x01
CAT ./wl18xx/fw_stats/pwr_sleep_time_cout = 0

但是、在'modprobe -r wl18xx'和'modprobe wla18xx'之后、统计数据具有一些见解：
CAT ./wl18xx/fw_stats/pwr_sleep_time_cout = 9.

5.如果使用的是 AP (连接的客户端)，则可以正常工作。它在几天内保持稳定、我们没有发现任何 TX 错误或重新启动。

请建议如何解决此问题。感谢您的帮助

0 admin 5 年多前

TI__Guru**** 2524460 points

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

您好！

如果只将固件版本更新为.85并继续按原样使用 hostapd 驱动程序模块，是否会看到此问题？

谢谢

Saurabh

0 admin 5 年多前

TI__Guru**** 2524460 points

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

您好！

.79固件、完整模块/驱动程序和新 hostapd 不存在问题、或 AP 至少持续18小时、因此我们不会注意到这是因为夜间看门狗重启(由于79的其他问题)。

我们没有使用旧的 hostapd 和新固件进行测试。我们将在明天运行该测试并返回测试结果。

在.85上重现"空闲问题"应该非常容易。
1.将其设置为 AP 模式(可能使用此线程的配置)
2.使用另一个 wifi 设备连接到 AP
3.断开连接，使其没有任何已连接的工作站
4、等待不到1小时、AP 将消失

谢谢、
Luka B

0 admin 5 年多前

TI__Guru**** 2524460 points

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

您好、Luka、

您能否也使用 fwr 81和84对其进行测试、并告诉我们您是否可以重现此问题

https://git.ti.com/cgit/wilink8-wlan/wl18xx_fw/

谢谢

Saurabh

0 admin 5 年多前

TI__Guru**** 2524460 points

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

大家好、我今天对未更新的硬件(之前的 hostapd)进行了一些测试
主机：

~ü# hostapd -v
hostapd v2.10- devel-hostap_2_9-898-g6ea7a152c
用于 IEEE 802.11 AP 管理的用户空间守护程序、
IEEE 802.1X/WPA/WPA2/EAP/RADIUS 验证器
版权所有(c) 2002-2019、Jouni Malinen 和贡献者

固件.79
09：46AM 从 AP 断开连接
11：04AM AP 仍然有效 [测试持续时间1h 18分钟]

固件.81.
上午11：17从 AP 断开
01：19pm AP 仍然有效[测试持续时间1h 58min]

固件.84
01：27AM 从 AP 断开
03：26pm AP 仍然有效[测试持续时间1h 59min]

固件.85.
03：28pm 从 AP 断开
04：53pm 我注意到 AP 已死[测试持续时间1h 25min]。
我不确定它何时消失

如果我让另一个 FW 运行更长时间、可能也会死。请告诉我是否应该切换到特定版本并使其保持运行。我有3个器件设置、可以并行进行测试、但我希望保留一个器件用于其他开发、因此需要连接到它。

0 admin 5 年多前

TI__Guru**** 2524460 points

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

卢卡

因此、它似乎仅在 fwer-85上发生故障。

谢谢

Saurabh

0 admin 5 年多前

TI__Guru**** 2524460 points

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

是的、我认为是这样。

.79还有其他问题，我不确定.85中是否仍然存在。因此、我们非常高兴能够快速切换到.85、因为我们希望能够得到改进。

我们应该等待.85的修复、还是要对我们的 WiFi 看门狗进行其他检查？

谢谢、

Luka B

0 admin 5 年多前

TI__Guru**** 2524460 points

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

您好！

我们使用 fwer-85测试了 R8.8版本，其中没有连接工作站的 AP 的运行时间超过7小时。 AP 按预期工作。

谢谢

Saurabh

0 admin 5 年多前

TI__Guru**** 2524460 points

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

您好、您有什么想法、为什么它会给我们带来问题？在所有使用 wl1831芯片的 Variscite SOM 器件上、问题始终如一。我觉得我们已经使用了所有可以使用的卡、除非我们开始深入研究调试驱动程序、固件或内核、而不是我们更喜欢使用的内核、而是专注于产品的应用部分。

您使用哪种 Linux 内核进行测试？是否有其他可能相关的设置、或者我们应该检查？我们是否缺少一些重要的内核模块？

现在、我们被迫使用看门狗"稳定"它、在这里、我们实验(痛苦地)发现了 AP 的所有可能方法、然后我们重新启动它：
对于.79、我们必须监控在连接站点时是否无响应：

-我们必须更改内核日志记录中的一行以始终报告"wlcore：警告无法清除所有 TX 缓冲区、超时(超时500)、而不是仅一次、因此我们可以在日志中侦听此内容、并在发生时重新启动(使用活动 AP)

对于空闲状态下的85、我们必须：

-监测/sys/kernel/debug/ieee80211/phy0/wlcore/sleep_auth，当我们探测到2时，将其强制为0

-监控已连接的 AP，并在所有站点断开连接时重新启动 AP

-监控空闲时间并每5分钟重新启动一次，因为即使是新重新启动的 AP 也会在更长的空闲时间后消失

－监视/sys/kernel/debug/ieee80211/phy0/wlcore/wl18xx/fw_stats/pwr_ap_sleep_counter 更改，并在开始计数时重新启动

对于.85连接的站点、我们必须(它在几天的持续使用之后也会挂起)：

-监控/sys/kernel/debug/ieee80211/phy0/wlcore/driver_state 中的"^flags = 0x41"

-监控日志消息："检测到信标丢失"

正如您看到的、该列表很长、包含不应该出现的内容。但这就是我们必须提出的让 Wifi 可用的东西。

0 admin 5 年多前

TI__Guru**** 2524460 points

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

你(们)好

我们已在内核4.19 R8.8版上测试了这一点： https://www.ti.com/tool/download/WILINK8-WIFI-NLCP

您可以订购 BeagbleBone Black 和 E14无线 Cape、并将其用作调试此问题的参考。

供参考-为驱动程序应用了以下2个补丁、以解决 5个以上站点连接到 AP 时出现的 AP 问题

https://git.ti.com/cgit/wilink8-wlan/build-utilites/tree/patches/kernel_patches/4.19.38/0004-mac80211-patch.patch?h=r8.8

https://git.ti.com/cgit/wilink8-wlan/build-utilites/tree/patches/kernel_patches/4.19.38/0005-wlcore-patch.patch?h=r8.8

请确保您的驱动程序集成了这些补丁。如果可能，请升级到 R8.8

谢谢

Saurabh

Wi-Fi®︎（参考译文帖）

Wi-Fi®︎（参考译文帖）(Read Only)

[参考译文] WL1831MOD：WiFi 闲置一段时间后、TI 定制主机 apd 消失