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.

[参考译文] WL1837MOD:重新关联请求花费的时间太长

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

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1100883/wl1837mod-reassociation-request-takes-too-long

器件型号:WL1837MOD

您好!

我们使用 的是 WL1837MOD。 我们注意到、发送 重新关联请求需要相当长的时间。

CPU: armv7l

内核: 5.4.47

Wlcore:PHY 固件版本:版本8.2.0.245
wlcore:固件已启动(版本8.9.0.0.86)

我们还将 wpa_supplicant 与 git.ti.com/cgit/wilink8-wlan/hostap/上的 TI 补丁一起使用

我们正在开发 Wi-Fi 漫游速度至关重要的设备。
我们看到、此接口发送 reassoc 请求大约需要500ms、但第一个 assoc 是瞬时的。

从请求中、我可以看到、所有这段时间内的操作都是 netlink 操作状态变为休眠状态
NetLink:操作数:ifIndex=10 linkmode=-1 (无变化)、操作状态=5 (IF_OPER_MANNESS)

我们还听说、这对于 TI Wi-Fi 接口很常见。

您是否知道导致这种情况的原因以及我们如何改进?

最好

Arturs

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

    您好!

    很抱歉、但我不理解。 您能否从屏幕截图中解释一下您在哪里看到了整个500毫秒? 此外、您能否提供这些关联请求的 Linux 内核日志? 因此、我们可以尝试确定减速的位置、无论是 CPU 还是 WL8固件。  

    最后、您好像使用的是旧固件版本、您能否通过此更新?  https://git.ti.com/cgit/wilink8-wlan/wl18xx_fw/ 

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

    您好!

    在屏幕截图中、相对时间列第2行和第3行的差异为0.28s、有时甚至更小。


    2. wpa_supplicant 日志、 dmesg 日志、 崩溃日志

    我附加 wpa_supplicant 日志、可以在" 5月17日15:44:20 imx6slag-mcg wpa_supplicant[239]:1652802260.699903"周围看到问题
    当我启用 wlcore 驱动程序内核消息时、无法重现问题。
    我还附加了一个可能不相关的 wlcore 崩溃。

    请准确指定您对哪些日志感兴趣。


    3.新固件出现相同问题:
    Wlcore:PHY 固件版本:版本8.2.0.246
    wlcore:固件已启动(版本8.9.0.0.90)

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

    Arturs、您好!

    您还可以上传 Wireshark 捕获吗? 我发现一个重新关联请求立即发生是很奇怪的。  

    您能否验证 SDIO 频率是否测量为50MHz? 我想确保不存在数据速率问题。  

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

    1. capture_1_full、 Capture_1_Roam_only
    在 Capture_1_Roam_only 中、您可以看到数据包57、65、76、86、107等发生了问题

    2.

    # cat /sys/kernel/debug/mmc1/ios
    clock: 50000000 Hz
    vdd: 7 (1.65 - 1.95 V)
    bus mode: 2 (push-pull)
    chip select: 0 (don't care)
    power mode: 2 (on)
    bus width: 2 (4 bits)
    timing spec: 2 (sd high-speed)
    signal voltage: 0 (3.30 V)
    driver type: 0 (driver type B)

    或者、您希望我使用示波器测量 SDIO 时钟吗?

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

    Arturs、您好!

    探查 SDIO 时钟也是很好的做法、以确保正确。 我们将查看这些日志并为您提供更新。

    请在下周初之前告知我们。

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

    你好!

    抱歉、我无法探测 SDIO 时钟、我只是一个软件人员。
    您在这种情况下是否取得了任何成功? 如果需要、我可以提供任何其他信息。

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

    Arturs

    供参考-默认情况下,WiLink8不支持快速漫游( 802.11r )。 第三方"intelligraphics"支持 WiLink8上的快速漫游

    由于您担心快速漫游,因此您可能需要联系他们以获取支持。  

    您的 SDIO 总线速度似乎是50MHz,4位宽-因此,除非信号完整性受到影响,否则这不会是问题。

    最好

    序列号

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

    您好!

    感谢您的回答。

    在这种情况下、我们对802.11r 不感兴趣。 此问题与802.11r 无关。

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

    Arturs、

    802.11r 可以帮助您实现更快的漫游速度、以防这是一项优先任务。

    您是否能够确定延迟不在请求方一方? 如果启用 wlcore 日志,结果是什么?

    序列号

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

    当 wpa_supplicant 发出 netlink 命令将操作状态更改为  if_Oper_notant 时、会发生延迟。 完成此更改后(延迟后) 、wpa_supplicant 继续正常运行。

    启用 多个或两个 wlcore 日志主题后、无法重现问题。 您感兴趣的主题是什么?

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

    漫游几乎完全由 WPA 请求者处理,例如扫描、选择 AP、连接到 AP 等。此问题似乎主要与请求者有关  

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

    我们使用的是 TI 从 此处 git.ti.com/.../修补的 wpa_supplicant

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

    大多数请求增补程序都围绕添加802.11s 网状支持。 这些修补程序不会影响漫游时间。