Re: core dump with PPP messages 1 byte long.

[Motonori Shindo <mshindo () mshindo net>]

From: Guy Harris <guy () alum mit edu>
Subject: Re: [tcpdump-workers] core dump with PPP messages 1 byte long.
Date: Wed, 7 Jul 2004 00:56:38 -0700

> On Wed, Jul 07, 2004 at 04:21:39PM +1000, Darren Reed wrote:
> > IP 1.1.1.1.1701 > 2.2.2.2.1701: l2tp:[TLS](24460/3222)Ns=23239,Nr=647
> >    *MSGTYPE(ICCN) *TX_CONN_SPEED(156000) *FRAMING_TYPE(A)
> >    *VENDOR0c7f:ATTR0066(00000000000000000000000000) RX_CONN_SPEED(156000)
>
> I'm not sure what the "framing type" in an L2TP session signifies - does
> it signify what framing is used for the PPP traffic once it leaves the
> L2TP tunnel, or does it (for some not-entirely obvious reason) signify
> what framing is used *inside* the tunnel?

In ICCN/OCCN case, Framing Type AVP is used by LAC to indicate which
framing (i.e. Synchronous or Asynchronous) is being used *outside* the
tunnel so that LNS can do the right job (e.g. ACCM negotiation).

As defined as follows,

> RFC 2661 says
>
>    Once tunnel establishment is complete, PPP frames from the remote
>    system are received at the LAC, stripped of CRC, link framing, and
>    transparency bytes, encapsulated in L2TP, and forwarded over the
>    appropriate tunnel. The LNS receives the L2TP packet, and processes
>    the encapsulated PPP frame as if it were received on a local PPP
>    interface.
>
> which sounds as if you're *not* supposed to send PPP frames over the
> wire in RFC 1662 byte-stuffed form.

byte-stuffing should not be used inside the tunnel. However, I've come
across an implementation (l2tpd) that does byte-stuffing inside the
L2TP tunnel. This happens when the peer insists that only Asynchronous
Framing is supported by Framing Capabilities AVP present in
SCCRQ/SCCRP message. There may be other implementations that do
something similar to this.

-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.