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 (it should already have been at 1.6).

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!

0 files changed, 0 insertions, 0 deletions