If we adjust our required ACCMAP due to a more restrictive

ACCMAP being REQuested by the peer, also increment our FSM
id so that we don't end up sending out a new REQ with the
same ID and different data (the changed ACCMAP).

1 files changed, 18 insertions, 2 deletions

diff --git a/usr.sbin/ppp/lcp.c b/usr.sbin/ppp/lcp.c
index 52b0dbf..0c49bb8 100644
--- a/usr.sbin/ppp/lcp.c
+++ b/usr.sbin/ppp/lcp.c
@@ -17,7 +17,7 @@
  * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
  * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
  *
- * $Id: lcp.c,v 1.69 1999/02/26 21:28:12 brian Exp $
+ * $Id: lcp.c,v 1.70 1999/03/01 13:46:45 brian Exp $
  *
  * TODO:
  *	o Limit data field length by MRU
@@ -645,7 +645,23 @@ LcpDecodeConfig(struct fsm *fp, u_char *cp, int plen, int mode_type,
       switch (mode_type) {
       case MODE_REQ:
 	lcp->his_accmap = accmap;
-        lcp->want_accmap |= accmap;	/* restrict our requested map */
+        if ((lcp->want_accmap | accmap) != lcp->want_accmap) {
+          lcp->want_accmap |= accmap;	/* restrict our requested map */
+          lcp->fsm.reqid++;		/* Invalidate the current REQ */
+          /*
+           * If we've already sent a REQ, we want to make sure that
+           * we don't end up sending out a new REQ that doesn't contain
+           * the data that the last one with the same id contained.
+           * This also means that we ignore the peers response to our
+           * last REQ due to an invalid fsm id (even though it's really
+           * correct), probably resulting in a REQ timeout and a resend
+           * with the new accmap and the new id.
+           * If we're already in ST_ACKRCVD at this point, we simply end
+           * up thinking that we negotiated the new accmap - which is ok
+           * as we just end up escaping stuff that the peer probably
+           * can't receive anyway.
+           */
+        }
         if (lcp->want_accmap == accmap) {
 	  memcpy(dec->ackend, cp, 6);
 	  dec->ackend += 6;