I purchased a BB8 a little while ago because of the larger screen than my chumby classic, and as expected it wanted to update to the newest software.  However, every time I tried to perform the update, it failed.

I eventually traced it down to the fact that the update file it was retrieving from amazon via wget was corrupt.  I repeated the wget command several times, and always got corrupted versions of the update file.  The md5sum was always different, but never correct.  The length was always correct.

I could retrieve the file with my notebook correctly, and was able to perform the update via a USB drive, but even after the update I cannot perform the wget successfully.

I had been having trouble downloading the control panel with the previous software version, but that seems to be much better with the current software, so it appears that something has changed to improve the situation.

If I put the update file onto an http server on my network, I can successfully wget it on the infocast.

Now, my network connection is through a community 802.11 network (I live out in the boonies), and it is entirely possible that there is occasional corruption to packets being sent through the radios to get to me.  I believe that I am seeing similar problems with another system, that
was definitely running with IP checksum calculation offloaded to the driver.  I am trying to determine if turning that off affects its problems, but it does point to a possible problem with the infocast..

Is there an option with the sd8xxx driver to offload IP checksum calculation to the firmware?  If so, is this known to work correctly?  I am thinking that somehow my infocast is accepting TCP packets that are corrupt, which is causing the updates to fail.  When I wget the file on a system
that performs the checksum correctly, I can get the file, or if I retrieve it from a source with a low probability of corrupt packets, I can get it correctly to the infocast (or so this theory would state, at least).  Is there any other likely explanation?

It appears that ethtool is not present on the infocast, which is how I am looking at the one system in question.  I've poked a little in /sys but haven't found anything to tweak there (yet).  Is there any way to force checksum checking in the stack, or am I chasing a red herring with this?

Any suggestions on what to try next?

Thanks!

Marcus Hall
marcus@tuells.org