What LCP packets are acceptable when PAP then IPCP has been negotiated? - PPP

This is a discussion on What LCP packets are acceptable when PAP then IPCP has been negotiated? - PPP ; I am using a proprietry TCP/IP Stack that I have access to the source code. I am using PPP to connect to a SAGEM MOD170 GPRS Modem. I can see that LCP packets have negotiated to the PAP authentication stage. ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: What LCP packets are acceptable when PAP then IPCP has been negotiated?

  1. What LCP packets are acceptable when PAP then IPCP has been negotiated?

    I am using a proprietry TCP/IP Stack that I have access to the source
    code.

    I am using PPP to connect to a SAGEM MOD170 GPRS Modem.

    I can see that LCP packets have negotiated to the PAP authentication
    stage.
    At this point, the far-end returns a CONF_REJ message to a previous
    request. The stack tears the link down. I reckon that this "stale"
    packet should be ignored?

    So the question is, when you have negotiated a link using LCP and move
    up a layer to start talking NCP and IPCP packets, what LCP packets
    should you be taking note of?

    RFC 1332 states "The link will remain configured for communications
    until explicit LCP or NCP packets close the link down."

    But what are these packets?

  2. Re: What LCP packets are acceptable when PAP then IPCP has been negotiated?

    rombomb@hotmail.com (Jas) writes:
    > I am using a proprietry TCP/IP Stack that I have access to the source
    > code.
    >
    > I am using PPP to connect to a SAGEM MOD170 GPRS Modem.
    >
    > I can see that LCP packets have negotiated to the PAP authentication
    > stage.


    Posting a trace would be helpful. Without a trace, all anyone can
    give is very general (and vague) advice.

    > At this point, the far-end returns a CONF_REJ message to a previous
    > request.


    I assume you mean LCP Configure-Reject here.

    That's pretty broken. A _working_ system should not be sending LCP
    Configure-Reject after LCP Configure-Ack.

    > The stack tears the link down. I reckon that this "stale"
    > packet should be ignored?


    That's also broken. The right actions are documented in RFC 1661 --
    event RCN in Opened state tears down protocols above LCP (such as PAP)
    and sends a new LCP Configure-Request.

    It's not uncommon, though. There are a lot of fragile PPP
    implementations that will roll over when the peer is doing something
    absurd. (As in this case.) It's also true that an implementation can
    give up at any time it likes. The errant LCP Configure-Request is a
    good clue that the peer is junk, and it's possible that attempting to
    continue will lead to more harm than good. (If it has this bug, what
    other bugs does it have?)

    > So the question is, when you have negotiated a link using LCP and move
    > up a layer to start talking NCP and IPCP packets, what LCP packets
    > should you be taking note of?


    You should be able to accept and process all LCP messages at all
    times.

    > RFC 1332 states "The link will remain configured for communications
    > until explicit LCP or NCP packets close the link down."
    >
    > But what are these packets?


    1332? That's not involved here. Try RFCs 1661 and 1334.

    The explicit messages that close a link down are (technically)
    specific to the layer, but they're commonly the Terminate-Request and
    Terminate-Ack messages.

    --
    James Carlson, IP Systems Group
    Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

+ Reply to Thread