d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Revert the ACCMAP changes where we OR the peers accmap

Browse Source 
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.
This commit is contained in:
Brian Somers 1999-04-11 08:51:04 +00:00
parent 41e70f38d2
commit 4ae29eb73c
2 changed files with 7 additions and 37 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
usr.sbin/ppp/async.c
View File

@ -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 <sys/types.h>
@ -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;
}
/*

40
usr.sbin/ppp/lcp.c
View File

@ -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 <sys/param.h>
@ -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;