Thread 中讨论的其他器件：WL1835
提供案例详细信息或注释：我们的器件正在设置无线网状网络、其中 wl1835通过 SDIO 与 i.mx 6处理器进行连接。
我们的平台是基于 Linux 4.9的平台。 driver/net/wireless/ti 目录似乎与 Linux 稳定4.9标签中的版本同步。
用于所有附加日志的固件版本为：
[171.7880] wlcore：PHY 固件版本：版本8.2.0.240
[171.851427] wlcore：固件已启动(版本8.9.0.0.76)
但是、最新固件版本的问题似乎也是重复出现的：
git.ti.com/.../
附件中固件配置文件(wlconf -i /lib/firmware/ti-connectivity/wl18xx-conf.bin -g >./wlconf.txt)的文本转储(作为 wlconf.txt)。 它是使用 TI 提供的 configure_devices.sh 脚本进行配置的。 该器件安装了2根天线。
我们使用 WPA 请求程序来设置网格、该程序是从 git.ti.com/.../的 Upstream _29_rebase 分支构建的 TI R8.8版本
在附件中找到 wpa-supplicant conf 文件，作为 wpa_supplicant_mesh.conf。 该网络是通道6上没有启用 SAE 的网状网络。
我们将一个节点配置为网状网关、其中 DHCP 服务器运行、NAT 规则连接到以太网接口、其余节点运行 DHCP 客户端、没有以太网接口。 DHCP 由 systemd-networkd 配置处理
网状网关设置为启用根模式和栅极抖动。
> iw dev st_wlan0设置 mesh_param mesh_hwmp_rootmode 4.
> iw dev st_wlan0设置 mesh_param mesh_gate_announcements 1
我们还禁用所有设备上的节电功能、并为所有数据包设置 RTS：
> iw phy `ls /sys/class/ieee80211` set RTS 0
> iw dev st_wlan0将 power_save 设置为 off
这种方法可以正常工作、直到我们启动了许多相对接近的节点... 即、足够接近10个峰值链路限值、以便一个或多个节点达到该限值。
在这种情况下、wl1835固件似乎有时会卡住、其中 stuck 被定义为 cat /sys/kernel/debug/ieee80211/phy/wlcore/tx_queue_len 在一分钟左右内连续到达数百条队列消息。
该器件似乎没有进入 ELP 模式、即/sys/kernel/debug/ieee80211/phy/wlcore/sleep_auth 始终指示0x0。
通过使用以下命令触发 wl1835恢复、可以手动恢复此情况：
> cat 0x1 >/sys/kernel/debug/ieee80211/phy/wlcore/sleep_auth
但恢复不会自动启动。
只需重新启动网关或重新启动其请求、这种情况就会变得非常可重现。
在其中一个再现中、我提高了 wlcore 驱动程序的动态调试级别、在此复制过程中、内核日志作为 wlcore_part.XT 附加。 在启动请求程序之前应用了 debug_level 更改、使用了以下设置：
> echo -n 'module wlcore +p'>/sys/kernel/debug/dynamic_debug/control
> echo -n 'module wl18xx +p'>/sys/kernel/debug/dynamic_debug/control
> echo -n 'module mac80211 +p'>/sys/kernel/debug/dynamic_debug/control
> echo -n 'module cfg80211 +p'>/sys/kernel/debug/dynamic_debug/control
> echo 0x1840 >/sys/module/wlcore/parameters/debug_level
> echo 8 >/proc/sys/kernel/printk
在其中一个再现中、我启用了无线电上方的监视器接口、并使用 tcpdump 进行了数据包捕获(仅在启动请求程序之前启动)；捕获作为 wireless.ca .p.附加
> iw phy phy 添加接口 mon0类型监控器
> ifconfig mon0 up
>tcpdump -i mon0 -n -w /data/wireless.cape2e.ti.com/.../data.tar.gz
