LCP packet identifier - PPP

This is a discussion on LCP packet identifier - PPP ; Hello all! I would like to know if it is possible that both parts of a ppp connection uses the same identifier for the LCP packets. Ie : client send a ConfReq with id 1, and server does the same. ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: LCP packet identifier

  1. LCP packet identifier

    Hello all!

    I would like to know if it is possible that both parts of a ppp
    connection uses the same identifier for the LCP packets. Ie : client
    send a ConfReq with id 1, and server does the same. I read that
    packets with invali identifier must be silently sicarded. What is an
    invalid id?

    I have been able to establish ppp connection with different servers,
    but not a test server. I would like to know where is the problem (who
    is not following the standards). I am using pppd on Linux (Mandrake).
    Below is the log of one session. Connecting to the server using
    Windows interface was succesfull.

    Does anyone have any idea on what is going wrong?
    Do someone know how to force pppd to use another identifier?

    Thanks,
    Schmeldric

    =================
    Jul 23 12:33:34 localhost pppd[2533]: pppd 2.4.1 started by root, uid
    0
    Jul 23 12:33:54 localhost pppd[2533]: Serial connection established.
    Jul 23 12:33:54 localhost pppd[2533]: using channel 5
    Jul 23 12:33:54 localhost pppd[2533]: Using interface ppp0
    Jul 23 12:33:54 localhost pppd[2533]: Connect: ppp0 <--> /dev/modem
    Jul 23 12:33:54 localhost pppd[2533]: rcvd [LCP ConfReq id=0x1 1500> ]
    Jul 23 12:33:54 localhost pppd[2533]: sent [LCP ConfReq id=0x1
    ]
    Jul 23 12:33:54 localhost pppd[2533]: sent [LCP ConfAck id=0x1 1500> ]
    Jul 23 12:33:57 localhost pppd[2533]: sent [LCP ConfReq id=0x1
    ]
    Jul 23 12:34:21 localhost last message repeated 8 times
    Jul 23 12:34:24 localhost pppd[2533]: Connection terminated.
    Jul 23 12:34:41 localhost pppd[2533]: Hangup (SIGHUP)
    Jul 23 12:34:42 localhost pppd[2533]: Exit.
    =================

  2. Re: LCP packet identifier

    Schmeldric wrote:

    > I would like to know if it is possible that both parts of a ppp
    > connection uses the same identifier for the LCP packets. Ie : client
    > send a ConfReq with id 1, and server does the same. I read that
    > packets with invali identifier must be silently sicarded. What is an
    > invalid id?


    The LCP requests from both sides can use the same ID.

    The identifier to which you refer must mean the type of LCP message.
    An invalid LCP message type would be silently discarded.

    > I have been able to establish ppp connection with different servers,
    > but not a test server. I would like to know where is the problem (who
    > is not following the standards). I am using pppd on Linux (Mandrake).
    > Below is the log of one session. Connecting to the server using
    > Windows interface was succesfull.


    There are no servers or clients defined in the PPP, which is a peer-to-peer
    protocol. Servers and clients are business-oriented concepts in regard
    to the purpose each of the PPP end points have in establishing the link.

    > Does anyone have any idea on what is going wrong?


    See in-line comments below.

    > Do someone know how to force pppd to use another identifier?


    No change is necessary and there is no way to force it to change
    identifiers.

    > Thanks,
    > Schmeldric


    > =================
    > Jul 23 12:33:34 localhost pppd[2533]: pppd 2.4.1 started by root, uid
    > 0
    > Jul 23 12:33:54 localhost pppd[2533]: Serial connection established.
    > Jul 23 12:33:54 localhost pppd[2533]: using channel 5
    > Jul 23 12:33:54 localhost pppd[2533]: Using interface ppp0
    > Jul 23 12:33:54 localhost pppd[2533]: Connect: ppp0 <--> /dev/modem
    > Jul 23 12:33:54 localhost pppd[2533]: rcvd [LCP ConfReq id=0x1 > 1500> ]


    The peer is a piece of junk. The default PPP MRU is 1500 so there
    is no need to request that pppd set it to 1500. I've been told that
    it is actually illegal per RFC 1661, although I've never checked to
    be sure.

    > Jul 23 12:33:54 localhost pppd[2533]: sent [LCP ConfReq id=0x1
    > ]


    You can try using the pppd option "asyncmap a0000" which might work.
    If it does then the peer is real piece of junk.

    > Jul 23 12:33:54 localhost pppd[2533]: sent [LCP ConfAck id=0x1 > 1500> ]
    > Jul 23 12:33:57 localhost pppd[2533]: sent [LCP ConfReq id=0x1
    > ]
    > Jul 23 12:34:21 localhost last message repeated 8 times
    > Jul 23 12:34:24 localhost pppd[2533]: Connection terminated.
    > Jul 23 12:34:41 localhost pppd[2533]: Hangup (SIGHUP)
    > Jul 23 12:34:42 localhost pppd[2533]: Exit.
    > =================


    There was only one LCP message from the peer, a Configure-Request.

    That implies LCP messages you send somehow get broken, perhaps at
    the peer because you don't request asyncmap a0000 as the peer does,
    or perhaps the UART configured for the serial device file is wrong and
    they don't get sent - usually it should be a 16550A. Check the UART
    with setserial /dev/ttySx, x = whatever is appropriate for the modem's
    serial device.

    If you are using a winmodem, or relative thereof, then that's the most
    likely place where negotiation messages you send would be broken, or are
    simply not sent, period.

    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads: http://ckite.no-ip.net/

  3. Re: LCP packet identifier

    In article <5400716.0407270915.9201786@posting.google.com>,
    Schmeldric wrote:
    >Hello all!
    >
    >I would like to know if it is possible that both parts of a ppp
    >connection uses the same identifier for the LCP packets. Ie : client
    >send a ConfReq with id 1, and server does the same.


    Yes, that's valid.

    >I read that
    >packets with invali identifier must be silently sicarded. What is an
    >invalid id?


    In this context, it means if you sent out your last Configure-Request with
    an ID of xyz, any Configure-Ack/Nak/Reject that doesn't have that exact
    ID should be tossed.

    >I have been able to establish ppp connection with different servers,
    >but not a test server. I would like to know where is the problem (who
    >is not following the standards). I am using pppd on Linux (Mandrake).
    >Below is the log of one session. Connecting to the server using
    >Windows interface was succesfull.
    >
    >Does anyone have any idea on what is going wrong?
    >Do someone know how to force pppd to use another identifier?
    >
    >Thanks,
    >Schmeldric
    >
    >=================
    >Jul 23 12:33:34 localhost pppd[2533]: pppd 2.4.1 started by root, uid
    >0
    >Jul 23 12:33:54 localhost pppd[2533]: Serial connection established.
    >Jul 23 12:33:54 localhost pppd[2533]: using channel 5
    >Jul 23 12:33:54 localhost pppd[2533]: Using interface ppp0
    >Jul 23 12:33:54 localhost pppd[2533]: Connect: ppp0 <--> /dev/modem
    >Jul 23 12:33:54 localhost pppd[2533]: rcvd [LCP ConfReq id=0x1 >1500> ]
    >Jul 23 12:33:54 localhost pppd[2533]: sent [LCP ConfReq id=0x1
    > ]
    >Jul 23 12:33:54 localhost pppd[2533]: sent [LCP ConfAck id=0x1 >1500> ]
    >Jul 23 12:33:57 localhost pppd[2533]: sent [LCP ConfReq id=0x1
    > ]
    >Jul 23 12:34:21 localhost last message repeated 8 times
    >Jul 23 12:34:24 localhost pppd[2533]: Connection terminated.
    >Jul 23 12:34:41 localhost pppd[2533]: Hangup (SIGHUP)
    >Jul 23 12:34:42 localhost pppd[2533]: Exit.
    >=================


    Can you log the packets at the byte level? Show us exactly what bytes are
    going back and forth across the wire. There may be some hidden problem
    these logs don't show.

    ========= For LAN/WAN Protocol Analysis, check out PacketView Pro! =========
    Patrick Klos Email: patrick@klos.com
    Klos Technologies, Inc. Web: http://www.klos.com/
    ==================== What goes around, comes around... =====================

  4. Re: LCP packet identifier

    Clifford Kite writes:
    > The identifier to which you refer must mean the type of LCP message.
    > An invalid LCP message type would be silently discarded.


    No -- LCP has both a Code (message type) number and an Identifier (ID)
    number. The ID number just identifies the Configure-Request message
    so that stale replies can be discarded. "Invalid" means only "reply
    doesn't match last request sent."

    > > Jul 23 12:33:54 localhost pppd[2533]: rcvd [LCP ConfReq id=0x1 > > 1500> ]

    >
    > The peer is a piece of junk. The default PPP MRU is 1500 so there
    > is no need to request that pppd set it to 1500. I've been told that
    > it is actually illegal per RFC 1661, although I've never checked to
    > be sure.


    It's not "illegal" -- merely discouraged and a bit silly. From
    section 5.1 of RFC 1661:

    An implementation wishing to open a connection MUST transmit a
    Configure-Request. The Options field is filled with any desired
    changes to the link defaults. Configuration Options SHOULD NOT be
    included with default values.

    --
    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

  5. Re: LCP packet identifier

    James Carlson wrote:
    > Clifford Kite writes:
    >> The identifier to which you refer must mean the type of LCP message.
    >> An invalid LCP message type would be silently discarded.


    > No -- LCP has both a Code (message type) number and an Identifier (ID)
    > number. The ID number just identifies the Configure-Request message
    > so that stale replies can be discarded. "Invalid" means only "reply
    > doesn't match last request sent."


    Right. Shooting from the hip is dangerous (as a certain disc jockey in
    south-east Texas found out long ago by actually shooting himself in the
    foot while practicing quick-draw).

    >> > Jul 23 12:33:54 localhost pppd[2533]: rcvd [LCP ConfReq id=0x1 >> > 1500> ]

    >>
    >> The peer is a piece of junk. The default PPP MRU is 1500 so there
    >> is no need to request that pppd set it to 1500. I've been told that
    >> it is actually illegal per RFC 1661, although I've never checked to
    >> be sure.


    > It's not "illegal" -- merely discouraged and a bit silly. From
    > section 5.1 of RFC 1661:


    >From a post by you in September 2000:


    (Why is the peer requesting the default MRU? That's illegal per RFC 1661.)

    Serves me right for not checking the RFC for MUST NOT.

    > An implementation wishing to open a connection MUST transmit a
    > Configure-Request. The Options field is filled with any desired
    > changes to the link defaults. Configuration Options SHOULD NOT be
    > included with default values.


    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads: http://ckite.no-ip.net/
    /* Speak softly and carry a +6 two-handed sword. */

  6. Re: LCP packet identifier

    Thanks to both of you, Kite and Patrick, for confirming that LCP
    identifiers can be the same for both side.

    As I do not have direct acces to the server, I cannot test the
    asyncmap option for now. For next test session I will also prepare a
    spy on serial link between PC and modem. Hope all this information
    will suffice.
    I do use a winmodem (Conexant Ambit SoftK56 HSF on a Sony laptop PCG
    FX401 with Mandrake 10.0) but I got the same result with an external
    Olitec modem.

    Thanks for your advices,
    Schmeldric

  7. Re: LCP packet identifier

    Clifford Kite writes:
    > >From a post by you in September 2000:

    >
    > (Why is the peer requesting the default MRU? That's illegal per RFC 1661.)


    Sigh. OK, yeah, I should have said "not recommended practice, a
    stupid thing to do in general, and often indicative of deeper
    implementation flaws."

    It's probably a mistake to say "legal" or "illegal" in that context
    anyway. RFCs aren't exactly conformance statements.

    > Serves me right for not checking the RFC for MUST NOT.


    ;-}

    --
    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