From 4ae29eb73cd2d56104a095eb5a7075715b64d2f8 Mon Sep 17 00:00:00 2001 From: Brian Somers Date: Sun, 11 Apr 1999 08:51:04 +0000 Subject: [PATCH] Revert the ACCMAP changes where we OR the peers accmap with our own if there are differing bits (last two revisions of lcp.c). This change broke at least one negotiation session. Instead, we just use an OR of the two accmap values when we're doing the ASYNC framing. --- usr.sbin/ppp/async.c | 4 ++-- usr.sbin/ppp/lcp.c | 40 +++++----------------------------------- 2 files changed, 7 insertions(+), 37 deletions(-) diff --git a/usr.sbin/ppp/async.c b/usr.sbin/ppp/async.c index ef59427cb15..ff241531f19 100644 --- a/usr.sbin/ppp/async.c +++ b/usr.sbin/ppp/async.c @@ -17,7 +17,7 @@ * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. * - * $Id: async.c,v 1.16 1998/05/21 21:43:55 brian Exp $ + * $Id: async.c,v 1.17 1998/06/16 19:40:34 brian Exp $ * */ #include @@ -57,7 +57,7 @@ void async_SetLinkParams(struct async *async, struct lcp *lcp) { async->my_accmap = lcp->want_accmap; - async->his_accmap = lcp->his_accmap; + async->his_accmap = lcp->his_accmap | lcp->want_accmap; } /* diff --git a/usr.sbin/ppp/lcp.c b/usr.sbin/ppp/lcp.c index 0c49bb87892..55240825e30 100644 --- a/usr.sbin/ppp/lcp.c +++ b/usr.sbin/ppp/lcp.c @@ -17,10 +17,8 @@ * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. * - * $Id: lcp.c,v 1.70 1999/03/01 13:46:45 brian Exp $ + * $Id: lcp.c,v 1.69 1999/02/26 21:28:12 brian Exp $ * - * TODO: - * o Limit data field length by MRU */ #include @@ -645,42 +643,14 @@ LcpDecodeConfig(struct fsm *fp, u_char *cp, int plen, int mode_type, switch (mode_type) { case MODE_REQ: lcp->his_accmap = accmap; - 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; - } else { - /* NAK with what we now want */ - *dec->nakend++ = *cp; - *dec->nakend++ = 6; - ua_htonl(&lcp->want_accmap, dec->nakend); - dec->nakend += 4; - } + memcpy(dec->ackend, cp, 6); + dec->ackend += 6; break; case MODE_NAK: - lcp->want_accmap |= accmap; + lcp->want_accmap = accmap; break; case MODE_REJ: - if (lcp->want_accmap) - log_Printf(LogWARN, "Peer is rejecting our ACCMAP.... bad news !\n"); - else - lcp->his_reject |= (1 << type); + lcp->his_reject |= (1 << type); break; } break;