what about support wifi in bootloader?

[Rask Ingemann Lambertsen]

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