Question reguarding When to apply Config Req options - PPP

This is a discussion on Question reguarding When to apply Config Req options - PPP ; Hello - I am implementing a very simple light weight PPP stack, and have a question reguarding where/when to execute LCP Configuration commands (Or any other LCP command). I have a state machine that matches the table in the RFC ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Question reguarding When to apply Config Req options

  1. Question reguarding When to apply Config Req options

    Hello -

    I am implementing a very simple light weight PPP stack, and have a
    question reguarding where/when to execute LCP Configuration commands
    (Or any other LCP command).

    I have a state machine that matches the table in the RFC (1661) and am
    filling in the surrounding logic.

    So taking the ConfigurationRequest Command as an example:

    My code does the following (Assume frame has been decoded (HDLC-like)
    already).

    Detect that it is an LCP Frame
    Detect that it is a ConfigRequest
    Validate that the ConfigRequest paramaters are valid (i.e. we support
    them)

    If (Valid)
    Send RCR+ Event to LCP state machine
    else
    Send RCR- Event to LCP State Machine


    My question is when should I oficially "Accept" and apply those config
    options. My choices are

    1. Once I have determined that they are all supported, but before
    passing the RCR+ to the machine

    2. Apply the changes in the FSM function that sends the Configure-Ack
    packet (Thus applying inside the FSM).

    It would make sense to me to officially "Accept" the changes right
    before sending the Ack. I'm not sure it it really matters

    Thoughts ?


    Thanks

    -Chris


  2. Re: Question reguarding When to apply Config Req options

    "Chris" writes:
    > I am implementing a very simple light weight PPP stack, and have a
    > question reguarding where/when to execute LCP Configuration commands
    > (Or any other LCP command).


    Step 1: don't. Just get yourself a copy of the freely-available
    ppp-2.4 source code, and use that instead.

    > My question is when should I oficially "Accept" and apply those config
    > options.


    There's a book I can recommend that covers these sorts of matters in
    great detail.

    > My choices are
    >
    > 1. Once I have determined that they are all supported, but before
    > passing the RCR+ to the machine
    >
    > 2. Apply the changes in the FSM function that sends the Configure-Ack
    > packet (Thus applying inside the FSM).
    >
    > It would make sense to me to officially "Accept" the changes right
    > before sending the Ack. I'm not sure it it really matters


    In general, except for a handful of incorrectly-designed PPP
    extensions, the things you set based on a Configure-Request you
    receive are your transmit-side parameters, and the things you set
    based on the Configure-Request accepted by your peer are your
    receive-side parameters.

    The RFC says that you must set these things only when the state
    machine goes to Opened state. I disagree.

    The right thing to do is to be liberal in what you expect, and
    conservative in what you send. Thus, for many things (but not all!),
    the best answer is to set your receive side parameter 'early' (when
    you would expect Configure-Ack in return), and set your transmit side
    parameter 'late' (after you're sure the peer must have gotten
    Configure-Ack).

    There are a lot of details here because there are many implementations
    that have both small and large bugs in this area. If you insist on
    redesigning the wheel, well, all I can recommend is that you do a lot
    of interoperability testing. And I wish you luck.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  3. Re: Question reguarding When to apply Config Req options

    > Step 1: don't. Just get yourself a copy of the freely-available
    > ppp-2.4 source code, and use that instead.


    Yeah - Love to do that !

    Unfortunaly my platform/customer wont permit it. The primary issue is
    we are in a very specific embedded environment, with extremely limited
    memory constraints (Thus the need for very light weight stack). Throw
    in a limitied custom operating system, a requirement not to use Open
    Source and that defines my platform !

    Basically, my customer wants to be able to speak IP to their custom
    devices over a direct serial cable usinng a custom client.

    On the good side, we have complete control over who/how we will be
    connected to (Totally closed system) so I am hoping it wont be too bad
    ! Our customer has a custom PPP client, that they use. So in many
    respects, I know what to expect from the client.

    I have been browsing the Linux pppd source for examples/etc to fill in
    gaps in the RFC (Very helpful) but any other sources of information
    would be greatly apreciated. (i.e. The book you mention ?)

    Thanks !

    -Chris


  4. Re: Question reguarding When to apply Config Req options

    "Chris" writes:
    > > Step 1: don't. Just get yourself a copy of the freely-available
    > > ppp-2.4 source code, and use that instead.

    >
    > Yeah - Love to do that !
    >
    > Unfortunaly my platform/customer wont permit it. The primary issue is
    > we are in a very specific embedded environment, with extremely limited
    > memory constraints (Thus the need for very light weight stack). Throw
    > in a limitied custom operating system, a requirement not to use Open
    > Source and that defines my platform !


    I've heard that story many times before. In my experience, it's far
    easier to trim down a working implementation (such as ppp-2.4) and
    make it fit into a small space than it is to arrive at the same place
    by designing from scratch.

    > Basically, my customer wants to be able to speak IP to their custom
    > devices over a direct serial cable usinng a custom client.


    No problem.

    > On the good side, we have complete control over who/how we will be
    > connected to (Totally closed system) so I am hoping it wont be too bad
    > ! Our customer has a custom PPP client, that they use. So in many
    > respects, I know what to expect from the client.
    >
    > I have been browsing the Linux pppd source for examples/etc to fill in
    > gaps in the RFC (Very helpful) but any other sources of information
    > would be greatly apreciated. (i.e. The book you mention ?)



    http://www.amazon.com/exec/obidos/ISBN%3D0201700530


    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  5. Re: Question reguarding When to apply Config Req options

    In article <1141941709.771730.50420@u72g2000cwu.googlegroups.c om>,
    Chris wrote:
    >Basically, my customer wants to be able to speak IP to their custom
    >devices over a direct serial cable usinng a custom client.
    >
    >On the good side, we have complete control over who/how we will be
    >connected to (Totally closed system) so I am hoping it wont be too bad
    >! Our customer has a custom PPP client, that they use. So in many
    >respects, I know what to expect from the client.


    Why not just use SLIP instead? It's much easier to implement.

    >I have been browsing the Linux pppd source for examples/etc to fill in
    >gaps in the RFC (Very helpful) but any other sources of information
    >would be greatly apreciated. (i.e. The book you mention ?)


    To answer your initial question, the time to apply the configuration
    options is when you transition your state machine to the Opened state. Of
    course, as James has pointed out, there are exceptions that will make your
    implementation a little more interoperable.

    Patrick
    =========== For PPP Protocol Analysis, check out PacketView Pro! ===========
    Patrick Klos Email: patrick@klos.com
    Klos Technologies, Inc. Web: http://www.klos.com/
    ==================== http://www.loving-long-island.com/ ====================

+ Reply to Thread