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.

[参考译文] CC3235MODAS:CC3235s 身份验证随机故障(企业)

Guru**** 2482225 points


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

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1300799/cc3235modas-cc3235s-random-failure-of-authentication-enterprise

器件型号:CC3235MODAS

有时我们会看到身份验证失败、这是一种随机方式。 有时1个纠正1个和2个错误、而其他情况下多次故障的时间更长。

身份验证失败
 

在12301上,RADIUS 服务器请求 PEAP,而不是 NAK 消息。

您可以在12851上看到客户端仍在发送 EAP NAK 消息。

身份验证良好(相同模块、相同配置)

您还可以看到 Radius 服务器在规则12300中请求 PEAP

在规则12302中,您可以看到客户端按照请求使用 PEAP 响应,在规则12318中,已协商的 PEAP 0版已成功。

在 WiFi 模块 CC3235中、我们看到了 PEAP0和 PEAP1

WiFi 模块 CC3235最初使用以下代码进行身份验证:

成功通过身份验证后、它将在下一个会话中使用配置文件0。

我们想知道两者之间的区别是什么、以及使用的是内部 EAP 和外部 EAP 方法。

NAK 只是来自客户端的响应。 客户端似乎正在使用身份验证方法进行切换。 或者、它未准备好进行身份验证、因此无法遵循请求的身份验证方法。

我们还找到了此链接、您可以在其中看到 NAK 消息来自客户端。

EAP 响应-传统 NAK (仅响应)|有线(arubanetworks.com)

在控制器/半径服务器上需要设置哪些不同的设置?

或者、我们是否需要为 CC3235设置不同的设置?

我们已经购买了超过5000个 CC3235并将其推向市场。

此致

马克

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

    CC3235具有 EAP 限制、因为它仅支持 TLS1.0 (如果 Radius 服务器需要 TLS1.2、连接将会失败)。

    另一个故障点可能与服务器证书有关。

    空气监听器日志或 NWP 日志(请参阅 https://www.ti.com/lit/pdf/swru455的第20章) 可以提供更多 详细信息、帮助我们了解根本原因。

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

    尊敬的 Kobi

    非常感谢您的快速回复。 我们将尝试更改 Radius 服务器中的设置。

    我们还有一些问题:

    PEAP0与 PEAP1的区别是什么?

    EAP 配置类型0 / 1 / 2之间有什么区别(如果设置为无、会产生什么影响)?

    非常感谢

    马克

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

    https://en.wikipedia.org/wiki/Protected_Extensible_Authentication_Protocol

    关于 EAP 设置:它与 Phase2身份验证相同(只有一个是获取文本字符串(如 MSCHAPV2),另一个是获取数字(如"1")。 这两种身份验证都是在建立安全会话后执行的 pahse2身份验证。    

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

    尊敬的 Kobi

    非常感谢您的快速回复。

    我们的客户做了一些进一步的测试:他声称他启用了 TLS 1.0、这是合理的、因为有时它会成功验证

    让我们感到困扰的是、使用完全相同的设置时、身份验证过程有时会失败(之后验证过程会再次失败):

    在 Wireshark 帧1716至1730中、身份验证失败、1738至1749是成功的身份验证。  注意:您会看到所有数据包两次,因为我们是在 WLC 的上行链路上捕获的。 因此、请忽略重复数据包。

    首先是帧1720之前的预期身份请求和响应。

    在第1723帧中、客户端要求使用 EAP-PEAP (25)

    在第1725帧中、控制器同意从 CC3235请求的 EAP 25:

    此时、这是正常行为。 我还可以在其他客户端和 Windows 设备上看到这一点。

    下面是有趣的部分:

    在帧1727中、客户端(CC3235)以"Desired Auth Type:unknown (0)"响应我们在此阶段预期客户端 Hello。

    在帧1729中的那一刻,控制器发送 EAP 故障,因为客户端确实发送了未知

    当我们观察第二个验证成功时,客户端没有发送第二个"未知"NAK 消息,而是以客户端 Hello 消息开始。 此外,Windows 客户端的行为也是相同的。

    我们还使用相同的随机行为测试了不同的设置(PEAP0、PEAP1)。

    为什么它有时会正确进行身份验证、有时则不正确?

    此致

    马克

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

    我不知道是什么原因。 它看起来像是一个错误、但我们需要进一步检查一下。

    与总连接尝试相比、失败率是多少?   故障后它是否始终正常工作?

    数据包1725是否与1747完全相似?  您能否提供监听器日志? (至少这样我们才能检查屏幕截图中所示数据包的全部内容)

    您能否提供 NWP 日志(见 https://www.ti.com/lit/pdf/swru455)?中的第20章)

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

    尊敬的 Kobi

    非常感谢。 我们确实观察到、有时几乎每秒钟都无法成功进行身份验证。 通常连续多次失败、直到最后一次失败才会成功。

    关于监听器日志、我已将您的请求转发给客户。 我自己与客户没有相同的环境。

    您能否确认在您的企业环境中每次验证都成功? 您能否对终端进行一些检查?

    附加了一些我尝试从测试 RADIUS 服务器(Linux radiusd)检索的日志。 您能告诉我这是不是您需要的、如果您已经可以检索进一步的信息、是什么错了?

    此致

    马克

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

    如果一切都正确- 身份验证应始终成功。

    您提供的日志是好的,但似乎断开来自 RADIUS 服务器(可能由于 TLS1.0的限制) ,即不像我们以前看到的。

    如果您可以 通过客户设置捕获类似的日志、这将很有帮助。  

    重现企业问题非常困难。 我们需要 使用 客户环境中的确切参数创建设置(许多事情可能会出错或设置不同)。

    通常、问题与客户的设置有关-因此指出确切的问题足以让客户解决问题。

    如果我们 最终证明问题已解决、我们会认为可以解决(与 TLS1.0问题不同)-我们一定会尽力重现问题。

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

    尊敬的 Kobi

    再次感谢您的反馈。

    我已向客户发送具有 NWP 日志功能的修改版本。 我们等待硬件送达、希望收到更多反馈以便进行分析。

    CC3235支持适用于以下套接字的 TLS1.2:

    为什么它仅限于针对 EAP 的 TLS1.0?

    附加了一些我用 FreeRadius (Linux)捕获的日志。 您是否已经了解了它并告诉我这是否也显示了随机未成功的验证? e2e.ti.com/.../teraterm8h.log.zip

    来自客户系统的日志将按照上面所述执行。

    此致 Marc

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

      安全套接字(在内部网络堆栈上工作)和 EAP (通过 hostapd/wap_supplicat 使用)有不同的实现方式。

     EAP 需要在 wpa_supplicant 中添加太多补丁-超出设备所能支持的范围。

    最新日志过长、无法解析。

    请仅捕获连接尝试。

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

    尊敬的 Kobi

    我可以私下向您发送请求和消息吗?

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

    已向您发送私人消息的"友谊请求"。

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

    尊敬的 Kobi

    谢谢。

    此致

    马克

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

    否。 不是这个主题。

    如果您接受"友谊请求",您将能够发送直接消息。