• 状态 Resolved
  • 已锁定 已锁定
  • 回复 6 回复
  • 订户 0 订户
  • 视图 233 视图
  • 用户 0 会员在此处
选项
选项
相关

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.

[参考译文] RTOS/TM4C129ENCPDT：PPP 堆栈中可能存在错误

admin
Guru**** 2481465 points


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

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/685671/rtos-tm4c129encpdt-possible-bug-in-ppp-stack

器件型号：TM4C129ENCPDT

工具/软件：TI-RTOS

我认为 NDK 2_25_00_09的 PPP 堆栈中可能存在错误

在 lcp.c 函数文件中“void lcpInput( ppp_ssession *p，PBM_Pkt* pPktt”

当前正在处理身份验证协议的 LCPCODE_CFGNAK 

案例 LCPOPT_AUTH：
/*在服务器模式下无法协商验证*/
if (p->Flags & PPPFLG 服务器)
｛
//如果这是 NAK，并且我们设置为 CHAP，则我们*/
/*将接受 PAP，我们将尝试切换到 PAP */
if (PHDR->Code = LCPCODE_CFGNAK &&
P->auth.Protocol =PPPPROT_CHAP &&
(P->Flags & PPPFLG_OPT_AUTH_PAP))
｛
P->auth.Protocol = PPPPROT_PAP；
中断；
｝
转至 StopConnect；
}

我本想客户还应该允许将 CHAP 请求更改为 PAP 吗？

该函数处理为响应客户端配置请求而以不同身份验证而不是 NAK 为客户端提供配置请求的客户端。

这是正确的行为吗？

查看 ESP32 PPP 堆栈、他们似乎也使用 NAK 来更改协议。

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

    您好 Barry、

    感谢您提出这个问题。 我需要回顾一下这一点、然后返回给您。

    Steve

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

    您好 Barry、

    首先、让我确保我了解您的用例：

    1. 您作为 PPP 客户端运行，并且最初已将其配置为使用 CHAP 进行身份验证(但您也将接受 PAP)。
    2. 您的客户端向 PPP 服务器发送了配置请求，但服务器拒绝了 CHAP
    3. 因此，您希望客户机将其身份验证降级为 PAP，然后发送新的配置请求(用于 PAP)

    对吗？ 这对您不起作用、因为您指出的代码仅适用于服务器案例？

    无论如何，特别是 PPP 和 LCP 的刷牙，就我所能说的 LCP 中没有客户端或服务器的概念而言。 两侧都可以发送配置请求、因此两侧都必须处理配置 NACK。 因此，我很难看到 if 语句限制服务器对 PAP 的更改的原因。

    我认为 RFC 1548中的以下 tidbit 涉及相关代码(5.3 Configure-Nak、第32页)：

    "接收到一个有效的 Configure-Nak 表示一个新的
         可以使用配置选项发送配置请求
         已按照 Configure-Nak 中的指定进行修改。"

    我猜测、由于上述内容为"可能"、因此在实施中它被视为可选、因此未进行编码(或者至少、不适用于客户案例)。

    在我看来、正如您提到的、客户应该能够做到这一点。 至于服务器是否允许它，是另一个问题...

    Steve

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

    您好 Steve

    是的，您回答正确，我正在查询客户机和服务器为何未正确处理请求。

    在我的情况下，特定服务器无法正确处理此问题，但这并不是 PPP 堆栈不能同时处理客户端和服务器的情况的原因。

    此致

    Barry

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

    您好 Barry、

    我为此提出了一项改进请求：

    NDK-258 -如果服务器请求，LCP 应允许从 CHAP 降级到 PAP

    您是否能够修改代码以通过此操作？

    Steve

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

    Barry、

    这是否得到了解决？

    Todd

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

    你好 Todd

    我通过不启用任何身份验证来管理工作。

    我连接到的调制解调器很满意、没有身份验证、因此一切都正常。

    从对 TM4C129的 NDK 的其他问题的回答中、我要说 PPP 堆栈本身发生任何变化的机会基本上是没有的。

    因此我的问题得到解决，PPP 堆栈中可能仍存在错误。

    此致

    Barry