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

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

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

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.