Preliminary inspection reveals that this log records all the data passing between the PC and modem at the customer's end, in both hexadecimal and ASCII. The top line of each pair records what the PC sent to the modem, the bottom line records what the modem sent to the PC. The FF bytes are fillers (representing silence whilst the other end is sending). What isn't revealed by this log is periods when both ends were silent.
The modem dials a number and reports a result code of 12 which we presume (as we don't know what modem is involved) to represent a connection with a remote modem at some speed or other, with or without error detection and correction. Anyway, it appears to be a good quality connection as the Order Set reaches the wholesaler without any problems.
But the customer's software negative acknowledges the second out-of-stock frame from the wholesaler (EAU DE TOSPRAY). This is standard procedure when the calculated checksum does not agree with the received checksum, and the wholesaler's software responds correctly by retransmitting the frame. This is how the protocol corrects errors caused by noise on the line, but in this instance an identical frame with checksum is received and again negative acknowledged. The sequence is repeated several times, until the wholesaler's software disconnects the call, after which the customer's modem passes random data to the local PC (for some reason which need not concern us, the modem fails to notice the loss of carrier signal).
As the same data is repeated in the log on each retry, the immediate conclusion is that the software at at least one end is miscalculating the checksum. Pencil, paper and a hexadecimal calculator can be used to determine that the correct checksum for this frame is hex 11, so it looks like the wholesaler's software has got it wrong as the customer is receiving hex 05 every time!
But hang on a moment! I wrote the wholesaler's software many years ago and it's never given any trouble. This is the relevant source code:
; ****************************** Update CRC
crc PROC PRIVATE
or BYTE PTR atcb.crcws+1,al
xor BYTE PTR atcb.crcws,al
ret
crc ENDPCan this really go wrong? Let's suppose not. In that case, the wholesaler is sending hex 11 even though the customer is receiving hex 05 (or so the log tells us).
But of course! Hex 11 is ASCII code DC1, usually the XON character in XON/XOFF handshaking. If this handshaking is activated at the customer's end (it certainly isn't at the wholesaler's end), any XON or XOFF character sent by the wholesaler will not reach the customer's software (it will be absorbed by the handshake mechanism). So what will happen? This depends on the software at the customer's end. A likely possibility is that it will continue to wait for the lost checksum byte. Under the rules of the protocol, if there is no response to a frame within three seconds, the sender (the wholesaler at this point) sends ASCII ENQ, which is hex 05. This is precisely what we find in the log.