• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 552 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: Possible bug in PPP Stack

Barry Andrews
Genius 3450 points
Part Number: TM4C129ENCPDT

Tool/software: TI-RTOS

I think there is a possible bug in the PPP stack for NDK 2_25_00_09

In the file lcp.c function "void lcpInput( PPP_SESSION *p, PBM_Pkt *pPkt )"

The handling of a LCPCODE_CFGNAK for the Authentication protocol is currently

            case LCPOPT_AUTH:
                /* Can't negotiate authentication much in server mode */
                if( p->Flags & PPPFLG_SERVER )
                {
                    /* If this is a NAK and we're set to CHAP, and we */
                    /* will accept PAP, we'll try switching to PAP */
                    if( pHdr->Code == LCPCODE_CFGNAK &&
                            p->auth.Protocol == PPPPROT_CHAP &&
                            (p->Flags & PPPFLG_OPT_AUTH_PAP) )
                    {
                        p->auth.Protocol = PPPPROT_PAP;
                        break;
                    }
                    goto StopConnect;
                }

I would have thought the client should also allow it's request for CHAP to be changed to PAP?

The function handles a client being given a config request with a different authentication but not a NAK in response to the clients config request.

Is this correct behaviour?

Looking at ESP32 PPP stack, they seem to use the NAK to also change the protocol.

  • 0
    TI__Mastermind 45025 points

    Hi Barry,

    Thanks for bringing this up. I will need to review this and get back to you.

    Steve

  • 0
    TI__Mastermind 45025 points

    Hi Barry,

    First, let me make sure I understand your use case:

    1. You are running as a PPP client and have initially configured it to use CHAP for authentication (but you will also accept PAP).
    2. Your client sent the configuration request to the PPP server, but the server rejected CHAP
    3. Due to this, you want your client to downgrade its authentication to PAP and then send a new configuration request (for PAP)

    Is that right? And this isn't working for you, because the code that you pointed out only does that for the server case?

    Anyway, brushing up on PPP and LCP in particular, as far as I can tell there is no notion of client or server in LCP. Either side can send a configuration request and therefore either side must handle a configuration NACK. So, I'm struggling to see the reason for the if statement that limits the change to PAP for servers.

    I think the following tidbit in RFC 1548 touches on the code in question (5.3 Configure-Nak, page 32):

    "Reception of a valid Configure-Nak indicates that a new
          Configure-Request MAY be sent with the Configuration Options
          modified as specified in the Configure-Nak."

    I'm guessing that because the above says "MAY", it was viewed as optional in the implementation and so wasn't coded (or at least, not for the client case).

    It seems to me that the client should be able to do this, as you mention. As to whether or not the server would allow it, is another issue ...

    Steve

  • 0 in reply to Steven Connell
    Genius 3450 points

    Hello Steve

    Yes you are correct, I am querying why the request is not correctly handled for the Client as well as the server.

    In my case the particular server didn't handle this correctly, but that's no reason the PPP stack shouldn't handle the situation for both Client and server.

    Regards

    Barry

  • 0 in reply to Barry Andrews
    TI__Mastermind 45025 points

    Hi Barry,

    I filed an enhancement request for this:

    NDK-258 - LCP should allow downgrade to PAP from CHAP if requested by server

    Were you able to modify the code to get past this?

    Steve

  • 0 in reply to Steven Connell
    TI__Guru* 96960 points

    Barry,

    Did this get resolved?

    Todd

  • 0 in reply to ToddMullanix
    Genius 3450 points

    Hello Todd

    I managed a work around by simply not enabling any authentication.

    The modem I was connecting to was happy with no authentication so all okay.

    From answers to other questions regard the NDK for TM4C129 I would say the chances of anything being changed in the PPP stack itself are basically none.

    So my issue is resolved, possible error in PPP stack remains.

    Regards

    Barry