Julian makes a good point, but we're not going to use MD5. The intel hex format contains sufficient internal integrity checks that we can very likely tell that it has been corrupted. It has a line-by-line star character, a per-line checksum byte, and it has a definite end of file record. The sorts of corruption that we'll see in file transfer operations will most likely be caught by the existing verification.
However the K3 Utility wasn't verifying the file until the MCU load had started. This is inconvenient, because the error recovery then consists of erasing the corrupt file from your PC, re-doing the FTP, and trying it again. If the FTP operation is at some distance from the radio, it becomes more inconvenient. The current DSP files are in a binary format, and the load process depended on a post-load internal verification, plus a command query to see that the processor was healthy enough to respond to a few simple commands. Based on K0PP's experience, the next revision of the K3 Utility (being evaluated by Field Test now) will verify Intel Hex files right after FTP copy, repeating the file copy if necessary. It will be verified again by a pre-pass before beginning the MCU load. The loader contains changes that permit the DSPs to be loaded in either binary or intel hex format. Subsequent revisions of DSP firmware will be released in intel hex format to permit this verification. The DSP firmware files are larger (> 2 times larger), but the load time to the K3 isn't increased dramatically. It will be slightly slower. Use of MD5 would have required us to maintain a side file of MD5 hashes or create a new variant of the intel hex file format with an internal digest. I suggested that keeping the side files in sync with the distribution of the firmware would be a continuing distribution problem. I did use an internal digest technique (with a CRC-32) for the configuration file save format, but that format was one of my creation. intel hex files are processed by a fair number of existing tools, not all of which are easily modified. 73 de Dick, K6KR -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Woolley Sent: Friday, December 07, 2007 12:40 AM To: elecraft Subject: Re: [Elecraft] K3 problem with logging program after download upgrade Julian G4ILO wrote: > Surely the uploader should do some kind of integrity check, instead of > attempting to upload a duff file to the radio? It's not exactly rocket > science. There's a thing called MD5 that's very good for this... MD5 is overkill. It's intended to detect deliberate tampering, although it's also useful as a fast way of comparing multiple files, as there is a high level of confidence that files with the same MD5 digest have the same content, given the presumption that they might. It's origins are in encryption, rather than in error detection. CRC codes are faster to compute and give good protection against random errors. In general, all the high risk steps in getting the firmware from Elecraft to the K3 are protected by error detection codes already, with the exception of the final hop, over the serial link. Typically the hex file is going to be processed incrementally as it arrives over that link, so most of the protection at that stage has to by short check codes that can be applied frequently, not a long one for the whole file. The other high risk area is probably the PC memory, if it doesn't have parity, which most, for cost, and speed reasons, doesn't. However, if the PC memory unreliable, you cannot trust that error detection code is being run correctly, or that errors won't be introduced after the check. Similarly for CPU faults, although these should be less likely for a system running within specification. Incidentally, there are known problems in MD5's tamper detection credentials and best current practice, at least in the open literature, is to use both MD5 and another cryptographic checksum algorithm called SHA (secure hash algorithm). > -- David Woolley Emails are not formal business letters, whatever businesses may want. RFC1855 says there should be an address here, but, in a world of spam, that is no longer good advice, as archive address hiding may not work. _______________________________________________ Elecraft mailing list Post to: Elecraft@mailman.qth.net You must be a subscriber to post to the list. Subscriber Info (Addr. Change, sub, unsub etc.): http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/subscribers.htm Elecraft web page: http://www.elecraft.com _______________________________________________ Elecraft mailing list Post to: Elecraft@mailman.qth.net You must be a subscriber to post to the list. Subscriber Info (Addr. Change, sub, unsub etc.): http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/subscribers.htm Elecraft web page: http://www.elecraft.com
