From owner-cvs-usrsbin  Fri Jan  9 18:00:12 1998
Return-Path: <owner-cvs-usrsbin>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id SAA08616
          for cvs-usrsbin-outgoing; Fri, 9 Jan 1998 18:00:12 -0800 (PST)
          (envelope-from owner-cvs-usrsbin)
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA08294;
          Fri, 9 Jan 1998 17:55:36 -0800 (PST)
          (envelope-from brian@FreeBSD.org)
From: Brian Somers <brian@FreeBSD.ORG>
Received: (from brian@localhost)
	by freefall.freebsd.org (8.8.6/8.8.5) id RAA03934;
	Fri, 9 Jan 1998 17:55:13 -0800 (PST)
Date: Fri, 9 Jan 1998 17:55:13 -0800 (PST)
Message-Id: <199801100155.RAA03934@freefall.freebsd.org>
To: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-usrsbin@FreeBSD.ORG
Subject: cvs commit: src/usr.sbin/ppp ccp.c ccp.h deflate.c fsm.c fsm.h
         hdlc.c modem.c modem.h vars.c
Sender: owner-cvs-usrsbin@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

brian       1998/01/09 17:55:12 PST

  Modified files:
    usr.sbin/ppp         ccp.c ccp.h deflate.c fsm.c fsm.h hdlc.c 
                         modem.c modem.h vars.c 
  Log:
  Implement Reset{Req,Ack} properly, as per rfc 1962.
  (I completely mis-read the rfc last time 'round!)
  
  This means:
    o Better CCP/WARN Reset diagnostics.
    o After we've sent a REQ and before we've received an ACK, we drop
      incoming compressed data and send another REQ.
    o Before sending an ACK, re-sequence all pending PRI_NORMAL data in
      the modem queue so that pending packets won't get to the peer
      *after* the ResetAck.
    o Send ACKs with the `identifier' from the REQ frame.
    o After we've received a correct ACK, duplicate ACKs are ok (and will
      reset our history).
    o Incorrect ACKs (not matching the last REQ) are moaned about and dropped.
  
  Also,
  
    o Calculate the correct FCS after compressing a packet.  DEFLATE
      *may* produce an mbuf with more than a single link in the chain,
      but HdlcOutput didn't know how to calculate the FCS :-(
    o Make `struct fsm'::reqid a u_char, not an int.
      This fix will prevent us from sending id `255' 2,000,000,000 times
      before wrapping to `0' for another 2,000,000,000 sends :-/
    o Bump the version number a little.
  
  The end result:  DEFLATE now works over an unreliable link layer.
                   I can txfr a 1.5Mb kernel over a (rather bad) null-modem
                   cable at an average of 21679 bytes per second using rcp.
  Repeat after me: Don't test compression using a loopback ppp/tcp setup as
                   we never lose packets and therefore never have to reset!
  
  Revision  Changes    Path
  1.28      +29 -5     src/usr.sbin/ppp/ccp.c
  1.13      +5 -2      src/usr.sbin/ppp/ccp.h
  1.6       +12 -13    src/usr.sbin/ppp/deflate.c
  1.26      +12 -6     src/usr.sbin/ppp/fsm.c
  1.14      +2 -2      src/usr.sbin/ppp/fsm.h
  1.27      +9 -8      src/usr.sbin/ppp/hdlc.c
  1.74      +10 -2     src/usr.sbin/ppp/modem.c
  1.15      +2 -1      src/usr.sbin/ppp/modem.h
  1.43      +3 -3      src/usr.sbin/ppp/vars.c