what about support wifi in bootloader?

[Mike (mwester)]

Rask Ingemann Lambertsen wrote:
> 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.

And I've explained that I have records documenting double-bit flips in a
commercial TCP network with a specific pattern that slips through the
simple TCP checksum.

And no, I'm not going to dig up those records.  Please spend a few
minutes with the protocol docs, and you can figure out what those
patterns would look like.

>>> 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

So what?  I have several gigabytes of archived data that documents cases
where the checksum remains ok, even though the data was flawed.

>> 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.

Who said anything about deliberate tampering?  Of course that's beyond TCP.

>    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". 

Because, as I've mentioned, I have gigabytes of captured information
from a year-long battle with an ISP that document beyond a shadow of a
doubt that data can be silently corrupted.

>> Not to mention the unknown issues in the Freerunner's kernel,
> 
>    What "unknown issues in the Freerunner's kernel"? FUD?

WTF are you going on about FUD?  Dude, look.  This is pretty easy -- if
the issues are unknown, then how the heck can I tell you about them?
Right?  I merely point out that the wifi driver in the kernel has been a
source of troubles, and that it would be unwise to assume that there are
no more unknown issues in the kernel.  And how is it FUD to mention that
this is a possible source of concern?  That's a very reasonable concern
to have.

>> 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".

Nope, it's not.  These are yet more reasons for being concerned about
the data reliability.  Nowhere in my email did I ever restrict my
comments to be solely about the TCP connection; that's naive thinking.
Data needs to be protected from end to end, if you value that data.

>> 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".

See previous comment.

>>> 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.

Because the likelihood of the system surviving if memory bus has a
problem is reasonably low compared to the likelihood of that data being
damaged in transit, in my experience.  If you have experience that
indicates otherwise, then indeed the CRC on the kernel should be
checked.  That would be a reasonable thing to do.  In fact perhaps one
should check the kexec sources to see if it already does that, and if
not a patch should be sent upstream.  That would be good, as there are a
lot of ways to feed a bad kernel to kexec.

>> [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.

We're splitting hairs here.  You are correct, perhaps my assumption that
TCP messed up the gigabytes of data I captured is incorrect -- it might
be that there is some type of network device between my TCP link and the
other end of the ISP that is damaging the data.  But that's splitting
hairs, because it doesn't change a thing about my argument.  If you are
pulling a kernel down from your tftp server, and it travels through some
broken Wireless Access Point that corrupts the data outside of the
"visibility" of the TCP checksum, you still end up with a
silently-damaged kernel on the device.  So my recommendation, to run an
end-to-end protocol that does not just rely on the TCP checksum remains
a valid and useful recommendation.


Look, I'm getting the impression you just want to argue about this.  I'm
not up for that, I merely offer some suggestions based on my experience.
 If you have experience that would state otherwise, then by all means
offer it -- but there's no call to engage in a argument with me.  So
let's end this ridiculous discussion right here.  Thanks.

-Mike