LCP Strange Option Length - PPP

This is a discussion on LCP Strange Option Length - PPP ; Hi, (Following on from my previous post) I have an LCP packet contained within a PPP packet using (I think) "HDLC-Like" framing with the "Address and Control Compression" negotiated on. I am seeing the following packet: 7E C0 21 07 ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: LCP Strange Option Length

  1. LCP Strange Option Length

    Hi,

    (Following on from my previous post)

    I have an LCP packet contained within a PPP packet using (I think)
    "HDLC-Like" framing with the "Address and Control Compression"
    negotiated on. I am seeing the following packet:

    7E C0 21 07 02 00 16 02 76 5B 50 4D 53 52 41 53 56 35 2E 31 30 66 56
    7E

    This appears to be an LCP packet within a PPP packet (protocol number
    C0 21)
    And the LCP packet breaks down as follows:
    07 = Code Reject
    02 = Identifier
    00 16 = Length (22)
    02 76 = Option 2, length 76 ???
    The data from "5B" to "30" is ASCII and decodes to "[PMSRASv5.10"
    66 56 = FCS?

    Firstly the packet length appears to be wrong, the packet seems to be
    only 18 bytes.
    Secondly what is this option 2 with a length of "76" ?

    Thanks
    O.C.

  2. Re: LCP Strange Option Length

    In article ,
    Old Codger wrote:
    >Hi,
    >
    >(Following on from my previous post)
    >
    >I have an LCP packet contained within a PPP packet using (I think)
    >"HDLC-Like" framing with the "Address and Control Compression"
    >negotiated on. I am seeing the following packet:
    >
    >7E C0 21 07 02 00 16 02 76 5B 50 4D 53 52 41 53 56 35 2E 31 30 66 56
    >7E


    When dumping packets in hex, it's best to either include all bytes that
    were on the wire (before unescaping), or not "add" the flag bytes after
    unescaping. Once you've removed the escapes, you should also remove
    the flags. Anyway, the CRC (66 56) on the above packet looks good.

    >This appears to be an LCP packet within a PPP packet (protocol number
    >C0 21)
    >And the LCP packet breaks down as follows:
    >07 = Code Reject
    >02 = Identifier
    >00 16 = Length (22)
    >02 76 = Option 2, length 76 ???
    >The data from "5B" to "30" is ASCII and decodes to "[PMSRASv5.10"
    >66 56 = FCS?


    Not exactly. Let me take this apart for you:

    C0 21 = LCP
    07 = Code-Reject (see RFC1661 section 5.6)
    02 = identifier
    00 16 = length (this SHOULD be 00 12 for this packet)
    02 76 5B 50 4D 53 52 41 53 56 35 2E 31 30 = rejected packet (section 5.6)
    66 56 = CRC (correct for the bytes presented in this packet)

    Now, the "rejected packet" portion of the Code-Reject packet should be the
    beginning of the (if not entire) packet that contained the unknown code:

    (from RFC1661)
    The Rejected-Packet field contains a copy of the LCP packet which
    is being rejected. It begins with the Information field, and does
    not include any Data Link Layer headers nor an FCS. The
    Rejected-Packet MUST be truncated to comply with the peer's
    established MRU.

    That would imply that the packet with the unknown code was:

    02 76 5B 50 4D 53 52 41 53 56 35 2E 31 30

    This is not a valid PPP packet as it clearly doesn't start with a valid
    protocol field. I'm guessing this is the tail end of an Identification
    packet (see RFC1570) where the magic number is 02765B50 and the message
    is "MSRASV5.10". The peer that sent the Code-Reject appears to be
    broken in that it didn't build the Code-Reject packet properly, nor
    did it set the length field properly.

    The Code-Reject packet should have looked like this:

    C0 21 07 02 00 18 C0 21 0C ii 00 12 02 76 5B
    50 4D 53 52 41 53 56 35 2E 31 30 cc cc

    (where 'ii' is an Identifier number, and 'cc cc' is the new frame's CRC)

    >Firstly the packet length appears to be wrong, the packet seems to be
    >only 18 bytes.


    Yes.

    >Secondly what is this option 2 with a length of "76" ?


    As you see, the packet was improperly formed, so the contents cannot
    be reasonably decoded.

    Hope this helps!

    =========== For PPP 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... =====================

  3. Re: LCP Strange Option Length

    OldCodger101@hotmail.com (Old Codger) writes:
    > 7E C0 21 07 02 00 16 02 76 5B 50 4D 53 52 41 53 56 35 2E 31 30 66 56
    > 7E
    >
    > This appears to be an LCP packet within a PPP packet (protocol number
    > C0 21)
    > And the LCP packet breaks down as follows:
    > 07 = Code-Reject
    > 02 = Identifier
    > 00 16 = Length (22)
    > 02 76 = Option 2, length 76 ???


    No ... see RFC 1661 section 5.6. The next field after Length is
    "Rejected-Packet," not an option. It starts with the PPP Information
    field, so that decodes as:

    Rejected-Packet:
    02 Configure-Ack
    76 Identifier
    5B 50 Length (apparently garbled)
    4D 53 52 41 53 56 35 2E 31 30 66 56 Nonsense data

    There appear to be a fair number of bugs here. No implementation
    should ever be sending Code-Reject in reply to Configure-Ack -- it's
    claiming that it doesn't know how to handle Configure-Ack!

    It's _probably_ complaining about the rest of the data, which appear
    to be garbled badly.

    It'd be really helpful to see the entire exchange, rather than just
    this snippet. It'd also be helpful to know some details about what
    sort of device you're talking to.

    (And is that packet really being sent as you show them? If so, and if
    LCP itself isn't in Opened state, then that's likely to be the
    problem. The default ACCM in effect when LCP isn't Opened is
    FFFFFFFF, which means that *ALL* values from hex 00 through 1F must be
    escaped. See RFC 1662.)

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

  4. Re: LCP Strange Option Length

    In article , wrote:
    >The Code-Reject packet should have looked like this:
    >
    >C0 21 07 02 00 18 C0 21 0C ii 00 12 02 76 5B
    >50 4D 53 52 41 53 56 35 2E 31 30 cc cc
    >
    >(where 'ii' is an Identifier number, and 'cc cc' is the new frame's CRC)


    Oops... I mis-spoke a little. Here's what the packet should have looked like:

    C0 21 07 02 00 16 0C ii 00 12 02 76 5B 50 4D 53
    52 41 53 56 35 2E 31 30 cc cc

    (where 'ii' is an Identifier number, and 'cc cc' is the new frame's CRC)

    I got Code-Reject and Protocol-Reject mixed up. Protocol-Rejects include
    the protocol field of the frame in question. Code-Reject does not.

    Given that, the original length field would have been correct if only
    the 4 byte LCP header were included with the packet.

    =========== For PPP 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... =====================

  5. Re: LCP Strange Option Length

    Thanks again James and Patrick for your help with this one. I am
    looking at the LCP Code-Reject section of the RFC now so I can
    correctly decode this packet.
    O.C.

+ Reply to Thread