Subject: Re: l2tp-digest V1000 #171

From: Barney Wolff <[email-masked]>
Date: Tue, 18 Jan 2000 12:44 EST

I guess I don't understand.  You seem to be saying that the LAC acts
on the SLI when received, even though it has an output queue of PPP
frames that were received before the SLI, but have not yet been sent
out on the serial port (or equivalent).  I would call such behavior
a bug.  At any rate, there can be at most one output frame on queue
in the worrisome case, an LCP Conf-Ack, right?  Again, unless I
really don't understand the problem.

Barney

> Date: Wed, 19 Jan 2000 09:20:29 -0800
> From: "W. Mark Townsley" <[email-masked]>
> 
> The problem is that the SLI *is* received. That is, the LNS negotiates
> something other than the default map. When the LAC receives the SLI, it
> blindly applies the new map, causing escaping to cease for some or all
> characters. From this point forward, the strict PPP client will drop all
> packets that do not have default escaping.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 19 Jan 2000 13:19:16 -0800

> really don't understand the problem.

Ensuring your output queue is empty before applying the SLI is a good,
cheap defense, and would probably handle many (if not most) cases. But
we still have the reordering problem. If the SLI is received at the LAC
before the last LCP packet, then it could get applied first. This is the
unrecoverable case.