BS> I have a few users who get heeps of errors while uploading
 BS> or downloading..

 BS> + 07 Jul 22:03:15 MAX  Connected at 14400 bps (V42BIS)
[..]
 BS> ! 07 Jul 22:07:35 MAX  Retry 1: Bad CRC at 18432
 BS> ! 07 Jul 22:08:00 MAX  Retry 2: Bad escape sequence 8
 BS> ! 07 Jul 22:08:00 MAX  Retry 3: Bad data subpacket
 BS> ! 07 Jul 22:08:02 MAX  Retry 4: Bad CRC at 37888
 BS> ! 07 Jul 22:08:13 MAX  Retry 5: Bad CRC at 53248
 BS> ! 07 Jul 22:08:15 MAX  Retry 6: Bad CRC at 53248
 BS> ! 07 Jul 22:08:28 MAX  Retry 7: Bad escape sequence 31

Argh, 27 bloody kilobytes of this junk - totally unnecessary, Brendan,
we've got the picture already, after this much.  Please don't do that to us
again; there's a good chance your monster msg won't even make it to some
systems ..

 BS> ! 07 Jul 23:05:42 MAX  Retry 493: Bad CRC at 3980928
 BS> + 07 Jul 23:05:50 MAX  CPS: 1137 (3989102 bytes)  Efficiency: 78%
 BS> = 07 Jul 23:05:50 MAX  UL-Z File\Uncheck\tyrian.arj

 BS> This happens all the time.. apart from the dropping
 BS> carrier.. Its really anoying..

Indeed.  It's a flow control problem, probably on the caller's end (if it
only happens with one or two people), and/or on your end.  Your caller's
modem (or software, or both) is probably not set up properly for RTS/CTS
handshaking, and so is streaming data at your system faster than it can
take it in.

The modems usually say 'hang on a tick' when this happens, and the caller's
end should stop sending till its CTS signal becomes true again, but this
obviously isn't happening, hence the CRC errors, bad packets, etc.

If these callers use Rockwell-based modems, have them set it to &K3,
and also set their software to use hardware (CTS/RTS) handshaking.

Ian

--- MaltEd 1.0.b5