(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!
When CCP is originally negotiated, the only thing we can be
sure about is that we've started adding data to the inflate
dictionary either before or at the same time as the peer. This
is ok, 'cos DEFLATE is a `sliding window' compressor.
We must call inflate again in case there's any pending output
despite our input buffer being empty. If the output buffer
is in fact already flushed, inflate() returns Z_BUF_ERROR.
There isn't really an error !
(I *really* meant to do this *before* committing the
deflate changes in the first place - oops).
Pppd is horribly broken in this respect - refer to the
ppp man page for details. Ppp *WON'T* negotiate deflate
with pppd by default - you must ``enable'' and ``accept''
``pppd-deflate'' in your config.
While I'm in there, update the cftypes in ccp.c so that
we recognise some more protocols (we don't actually do
anything with them - just send a REJ).
