>I have added my own 16-bit CRC to the packet I am sending (that is how I know that the packet is "distorted" when received by the device). I am not writing the code for the receiving device, so all I know is that the receiving device checks the 16-bit CRC and also 20 other bytes to validate the packet. If it is a valid packet a ACK message is sent back to me and if the packet is invaild an NAK message is sent to me.

From what I have studied (general overview, no specific details), I understand that the ACK also tells the sender you to continue transmitting from byte #x. For example, if each packet has 1000 bytes (to simplify calculations), and you send three packets, you might receive an ACK, which tells you to continue sending from byte #4001. On the other hand, if packet #2 is lost, the ACK will tell you to continue sending from byte #2001.

I don't remember reading anything about a NAK, and a quick search in the document RFC 793 (TCP) shows that, apparently, NAK isn't mentioned.

>The receiving device is using an embedded device from Lantronix to communicate over the TCP or UDP protocol. I guess I should check into more how the embedded device handles a command packet.
>

>No I do not want to create my own TCP implementation!!! lol

That is what it looks like, if you are creating your own CRC, and send an ACK!

Anyway, I would search if there is a possibility of handling TCP at a higher-level, which doesn't force you to analyze or assemble the bytes in the individual packages.