On Thu, Mar 19, 2009 at 09:21:42AM -0500, Mike (mwester) wrote: > Werner Almesberger wrote: > > Mike (mwester) wrote: > >> I think you have a flawed assumption -- neither ftp or http are reliable.
No, I said: "Please explain why he would need his own checksumming mechanism for reliable downloads over ftp or http." It's reliable in the face of single-bit errors, packet loss and reordered packets at the TCP level. All networks that I know of have a checksum designed to catch single- and multi-bit errors at the link level. > > Hmm, that's why you have CRCs at the layers below. Unless there's > > some specific bug that makes things worse than usual, I wouldn't > > really be concerned about FTP/HTTP/TFTP corrupting data. I know from a bug in my Novell NE3200 driver project[1] from a six years ago that the linux TCP stack does discard packets where the checksum doesn't match. [1] http://nospamnospam.homepage.dk/linux/i82586/ne3200/ne3200-0.02.txt > That's *EXACTLY* the point, though. Even the commercial gear has > issues[1] on this front, be they design flaws or bugs. And home routers > and access points are full of bugs. Outside of your home network, you'll need protection against deliberate tampering with your TCP link. That's beyond the scope of the TCP protocol. I believe you said: "the only concern I would have with wifi would be reliability". Please explain why you think errors at the Wifi level will survive link level checksum, TCP checksum, kernel decompression and kernel checksum. If a man-in-the-middle attack on the network is your worry, use https. Still not "his own checksumming mechanism". > Not to mention the unknown issues in the Freerunner's kernel, What "unknown issues in the Freerunner's kernel"? FUD? > and any problems that might exist in the > busybox utilities that would be part of such a small rootfs/kernel > combo... Nothing to do with your claim "neither ftp or http are reliable". > and then there's the server side and it's handling of the data... Nothing to do with your claim "neither ftp or http are reliable". > > Besides, your kernel generally has its own CRC anyway. > > Sure, if someone wants to implement a utility that would check the > downloaded kernel for consistency post-download and pre-kexec-boot, that > would be a fine solution as well. Hang on a minute. If you don't even check the kernel for correct CRC and successful decompression, why are you questioning reliability of downloads across a TCP link, which at least has a checksum? Such a thing as bit errors in memory are known to happen, and there's rarely any error detection on memory. Likewise for the busses connecting memory to the rest of the system. > [1] > I have a collection of data from a year-long battle with an ISP over TCP > reliability. They insist that TCP is reliable, and that the underlying > layers on their RF links are reliable, etc -- and yet I have numerous > traces that document bit-flips in large TCP downloads on their network. Are you aware that NAT boxes and proxies lose the checksum of the sender TCP host, and that you therefore don't have an end-to-end TCP checksum with such devices in use? If you really have those traces _from both ends_ of a bit-flip, I'd definitely like to see them. If you don't have them, then you don't know that the checksum wasn't tampered with between sender TCP and receiver TCP and thus you have no basis for claiming that TCP messed up. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year
