recover_special_codes escaping too many sequences

[bgstewart]

The function recover_special_codes can replace too many characters due to the fact that it sequentially replaces FESC_TFESC then FESC_TFEND instead of iterating through the frame.

Consider the following example: If the data contains DB DC, it would be escaped to DB DD DC to remove the special character DB When this is read and the special characters recovered, the DB DD would be recovered to DB with the first string replace The next string replace is then performed which would then replace would replace DB DC with C0

The recovering of special characters needs to be done with an iteration through the packet so that the same data is not escaped multiple times.

Cheers

[xssfox]

I patched this (amongst adding in a TCP server and other enhancements for the freedvtnc project) in my fork here. https://github.com/xssfox/kiss-fix . It's probably not the most elegant patch so I won't lodge a pull request but if you need something that works in the short term it should work.

[jlangvand]

Pull request #27 should fix this. It's similar to @xssfox's method, but follows the KISS spec a little closer:

The reason for both preceding and ending frames with FENDs is to improve performance when there is noise on the asynch line. The FEND at the beginning of a frame serves to "flush out" any accumulated garbage into a separate frame (which will be discarded by the upper layer protocol) instead of sticking it on the front of an otherwise good frame. ... As characters arrive at the receiver, they are appended to a buffer containing the current frame. Receiving a FEND marks the end of the current frame. Receipt of a FESC puts the receiver into "escaped mode", causing the receiver to translate a following TFESC or TFEND back to FESC or FEND, respectively, before adding it to the receive buffer and leaving escaped mode. Receipt of any character other than TFESC or TFEND while in escaped mode is an error; no action is taken and frame assembly continues. A TFEND or TESC (sic) received while not in escaped mode is treated as an ordinary data character.

I believe this method of iterating through the raw data, handling both FEND and FESC in the same loop, is more readable and less error-prone.