*Summary:* Google WiFi TCP packets are getting corrupted but protocol layer is not detecting it at Node MAC-00:0D:97:03:24:5C BSSID-00:0D:97:00:50:62 (Corner of Ada Ave & Brenton Ct)
*My background:* I am a SW engineer who is helping out some people who are in the same complex that I am. *Location: * Free Google Node :MAC-00:0D:97:03:24:5C BSSID-00:0D:97:00:50:62 (Corner of Ada Ave & Brenton Ct)
*Details*: What I have found is that every so often (about ones(1) for every 100MB) a corrupted TCP packet comes in that the protocol layer does not detect as being invalid (pass TCP CRC check). Typically it will add a bit and remove a bit from some where in the TCP packet. I have found it happens more at peak-usage than at other times. It is happening on a every system, I have looked at. (Win XP SP3, Win7 x64, and Win7 x32)
*How to check to see if you are having a same problem:* Step 1) Download a large file. An example of a Large file (Linux ISO:700 MB): http://releases.ubuntu.com/precise/ubuntu-12.04-desktop-amd64.iso Step 2) Do a MD5 check-sum on the file. (Freeware MD5 check-sum software: http://www.winmd5.com/) Step 3) The Linux ISO MD5 Check-sum are located at: http://releases.ubuntu.com/precise/MD5SUMS - File:ubuntu-12.04-desktop-amd64.iso MD5 Check-sum:128f0c16f4734c420b0185a492d92e52 Step 4) If they match then there is no issue, if they don't match you have the corruption issue
We have discussed the issue with several folks around here and there are several things to note....
1) Data corruption happens quite often (unfortunately) in WiFi and even more in large area (i.e. city-wide) WiFi due to interference or noise. The FCS in each WiFi frame is designed to detect these problems and correct them -- but it is not mathematically 100% guaranteed. There are, as you have discovered, corner cases which will result in an acceptance of a packet which is technically corrupted.
2) Our radios (the Tropos radios) do not do TCP checksums on user payloads. This is part of the TCP control layer and is handled by each end point separately. We do do packet level checks to verify the integrity of the packets.
I am surprised at your reported prevalence....we certainly have users of run at the maximum data rate (3 Mbps down and 1 Mbps up) for 24 hours a day and we pass close to 600 GB of traffic a day -- but this is the first we have heard of this.
On Sunday, July 22, 2012 11:13:35 PM UTC-7, niemic wrote:
> *Summary:* > Google WiFi TCP packets are getting corrupted but protocol layer is not > detecting it at Node MAC-00:0D:97:03:24:5C BSSID-00:0D:97:00:50:62 (Corner > of Ada Ave & Brenton Ct)
> *My background:* I am a SW engineer who is helping out some people who > are in the same complex that I am. > *Location: * Free Google Node :MAC-00:0D:97:03:24:5C > BSSID-00:0D:97:00:50:62 (Corner of Ada Ave & Brenton Ct)
> *Details*: > What I have found is that every so often (about ones(1) for every 100MB) a > corrupted TCP packet comes in that the protocol layer does not detect as > being invalid (pass TCP CRC check). Typically it will add a bit and remove > a bit from some where in the TCP packet. I have found it happens more at > peak-usage than at other times. It is happening on a every system, I have > looked at. (Win XP SP3, Win7 x64, and Win7 x32)
> *How to check to see if you are having a same problem:* > Step 1) Download a large file. An example of a Large file (Linux ISO:700 > MB): http://releases.ubuntu.com/precise/ubuntu-12.04-desktop-amd64.iso > Step 2) Do a MD5 check-sum on the file. (Freeware MD5 check-sum software: > http://www.winmd5.com/) > Step 3) The Linux ISO MD5 Check-sum are located at: > http://releases.ubuntu.com/precise/MD5SUMS > - File:ubuntu-12.04-desktop-amd64.iso MD5 > Check-sum:128f0c16f4734c420b0185a492d92e52 > Step 4) If they match then there is no issue, if they don't match you have > the corruption issue
I have had a similar problem - but only with Ubuntu derivates. I have not downloaded Ubuntu, so I would not know. I know that it happened for Bodhi Linux, MacPup and Puppy Linux, and repeatedly. The MD5SUM was different every time the file was downloaded, and never the same as the correct md5sum
It did not happen with crunchbang, Antix and Mepis which are also Debian derivates.
Other very large files (>500M) appear to have come through unscathed and repeatedly so.
I do not know if the corner cases are dependent on some element inside the file itself.
On Sunday, July 22, 2012 11:13:35 PM UTC-7, niemic wrote:
> *How to check to see if you are having a same problem:* > Step 1) Download a large file. An example of a Large file (Linux ISO:700 > MB): http://releases.ubuntu.com/precise/ubuntu-12.04-desktop-amd64.iso > Step 2) Do a MD5 check-sum on the file. (Freeware MD5 check-sum software: > http://www.winmd5.com/) > Step 3) The Linux ISO MD5 Check-sum are located at: > http://releases.ubuntu.com/precise/MD5SUMS > - File:ubuntu-12.04-desktop-amd64.iso MD5 > Check-sum:128f0c16f4734c420b0185a492d92e52 > Step 4) If they match then there is no issue, if they don't match you have > the corruption issue
Second, I believe your analysis is missing a few parts of the picture. Let me explain more.
When you have TCP checksum issue, you can see if that the case by looking at the Ethernet statistics (on windows command prompt type: netstat -e ). There is a field called "Errors". When there is a TCP checksum mismatch happen, the statistics will record an error and issue a resend of the TCP packet. On my system, and my neighbor systems the number of "Errors" where very small. They where in the order of 0 or 1. Also, the chances that there a bad TCP packet and the TCP Checksum didn't catch it is 1/2^16 (1 in 65,536 corrupted packages) if all failures are equally likely.
Let me explain what we are seeing in more details. Let me talk about what bytes are different when you look at the difference of a larger file like the Linux ISO.
From above you can see bit 0x20 is sometimes remove or added. This is signs of a flaky bit on a DRAM chip.
Next question is where is this flaky DRAM located. We believe, this can not be in the DRAM of our WiFi cards because the problem happens they same way on neighbors and my system. From above, we know that if the TCP checksum is in place and as you said there is other protect to make sure the RF side of the WiFi has no issue. Therefore, the place to look is where the TCP checksum is being re-calculated on the system. This normally happens on the system when the system splits or combines TCP packets together. My guess is the AP node, has the flaky DRAM. I am assuming it does the splitting or combining TCP packets together before sending them out.
*Note: *a side effect of flaky DRAM is that if you reboot the system, the problem may move or change. This is because memory allocation and what part of the system using the flaky bit of the DRAM will have problems . If this location on the DRAM is not touching anything important, you will not see any issue.
On Wednesday, July 25, 2012 2:05:35 PM UTC-7, wifi4all wrote:
> Hi,
> Thanks for the detailed analysis.
> We have discussed the issue with several folks around here and there are > several things to note....
> 1) Data corruption happens quite often (unfortunately) in WiFi and even > more in large area (i.e. city-wide) WiFi due to interference or noise. The > FCS in each WiFi frame is designed to detect these problems and correct > them -- but it is not mathematically 100% guaranteed. There are, as you > have discovered, corner cases which will result in an acceptance of a > packet which is technically corrupted.
> 2) Our radios (the Tropos radios) do not do TCP checksums on user > payloads. This is part of the TCP control layer and is handled by each end > point separately. We do do packet level checks to verify the integrity of > the packets.
> I am surprised at your reported prevalence....we certainly have users of > run at the maximum data rate (3 Mbps down and 1 Mbps up) for 24 hours a day > and we pass close to 600 GB of traffic a day -- but this is the first we > have heard of this.
> Not sure what the next step is....
> WiFi4All
> On Sunday, July 22, 2012 11:13:35 PM UTC-7, niemic wrote:
>> *Summary:* >> Google WiFi TCP packets are getting corrupted but protocol layer is not >> detecting it at Node MAC-00:0D:97:03:24:5C BSSID-00:0D:97:00:50:62 (Corner >> of Ada Ave & Brenton Ct)
>> *My background:* I am a SW engineer who is helping out some people who >> are in the same complex that I am. >> *Location: * Free Google Node :MAC-00:0D:97:03:24:5C >> BSSID-00:0D:97:00:50:62 (Corner of Ada Ave & Brenton Ct)
>> *Details*: >> What I have found is that every so often (about ones(1) for every 100MB) >> a corrupted TCP packet comes in that the protocol layer does not detect as >> being invalid (pass TCP CRC check). Typically it will add a bit and remove >> a bit from some where in the TCP packet. I have found it happens more at >> peak-usage than at other times. It is happening on a every system, I have >> looked at. (Win XP SP3, Win7 x64, and Win7 x32)
>> *How to check to see if you are having a same problem:* >> Step 1) Download a large file. An example of a Large file (Linux ISO:700 >> MB): http://releases.ubuntu.com/precise/ubuntu-12.04-desktop-amd64.iso >> Step 2) Do a MD5 check-sum on the file. (Freeware MD5 check-sum software: >> http://www.winmd5.com/) >> Step 3) The Linux ISO MD5 Check-sum are located at: >> http://releases.ubuntu.com/precise/MD5SUMS >> - File:ubuntu-12.04-desktop-amd64.iso MD5 >> Check-sum:128f0c16f4734c420b0185a492d92e52 >> Step 4) If they match then there is no issue, if they don't match you >> have the corruption issue
On Saturday, July 28, 2012 11:20:15 PM UTC-7, niemic wrote:
> Hi WiFi4All,
> First, sorry for not getting back to you sooner.
> Second, I believe your analysis is missing a few parts of the picture. > Let me explain more.
> When you have TCP checksum issue, you can see if that the case by looking > at the Ethernet statistics (on windows command prompt type: netstat -e ). > There is a field called "Errors". When there is a TCP checksum mismatch > happen, the statistics will record an error and issue a resend of the TCP > packet. On my system, and my neighbor systems the number of "Errors" where > very small. They where in the order of 0 or 1. Also, the chances that > there a bad TCP packet and the TCP Checksum didn't catch it is 1/2^16 (1 in > 65,536 corrupted packages) if all failures are equally likely.
> Let me explain what we are seeing in more details. Let me talk about what > bytes are different when you look at the difference of a larger file like > the Linux ISO.
> From above you can see bit 0x20 is sometimes remove or added. This is > signs of a flaky bit on a DRAM chip.
> Next question is where is this flaky DRAM located. We believe, this can > not be in the DRAM of our WiFi cards because the problem happens they same > way on neighbors and my system. From above, we know that if the TCP > checksum is in place and as you said there is other protect to make sure > the RF side of the WiFi has no issue. Therefore, the place to look is > where the TCP checksum is being re-calculated on the system. This normally > happens on the system when the system splits or combines TCP packets > together. My guess is the AP node, has the flaky DRAM. I am assuming it > does the splitting or combining TCP packets together before sending them > out.
> *Note: *a side effect of flaky DRAM is that if you reboot the system, the > problem may move or change. This is because memory allocation and what > part of the system using the flaky bit of the DRAM will have problems . If > this location on the DRAM is not touching anything important, you will not > see any issue.
> Thanks again for looking in to the issue
> On Wednesday, July 25, 2012 2:05:35 PM UTC-7, wifi4all wrote:
>> Hi,
>> Thanks for the detailed analysis.
>> We have discussed the issue with several folks around here and there are >> several things to note....
>> 1) Data corruption happens quite often (unfortunately) in WiFi and even >> more in large area (i.e. city-wide) WiFi due to interference or noise. The >> FCS in each WiFi frame is designed to detect these problems and correct >> them -- but it is not mathematically 100% guaranteed. There are, as you >> have discovered, corner cases which will result in an acceptance of a >> packet which is technically corrupted.
>> 2) Our radios (the Tropos radios) do not do TCP checksums on user >> payloads. This is part of the TCP control layer and is handled by each end >> point separately. We do do packet level checks to verify the integrity of >> the packets.
>> I am surprised at your reported prevalence....we certainly have users of >> run at the maximum data rate (3 Mbps down and 1 Mbps up) for 24 hours a day >> and we pass close to 600 GB of traffic a day -- but this is the first we >> have heard of this.
>> Not sure what the next step is....
>> WiFi4All
>> On Sunday, July 22, 2012 11:13:35 PM UTC-7, niemic wrote:
>>> *Summary:* >>> Google WiFi TCP packets are getting corrupted but protocol layer is not >>> detecting it at Node MAC-00:0D:97:03:24:5C BSSID-00:0D:97:00:50:62 (Corner >>> of Ada Ave & Brenton Ct)
>>> *My background:* I am a SW engineer who is helping out some people who >>> are in the same complex that I am. >>> *Location: * Free Google Node :MAC-00:0D:97:03:24:5C >>> BSSID-00:0D:97:00:50:62 (Corner of Ada Ave & Brenton Ct)
>>> *Details*: >>> What I have found is that every so often (about ones(1) for every 100MB) >>> a corrupted TCP packet comes in that the protocol layer does not detect as >>> being invalid (pass TCP CRC check). Typically it will add a bit and remove >>> a bit from some where in the TCP packet. I have found it happens more at >>> peak-usage than at other times. It is happening on a every system, I have >>> looked at. (Win XP SP3, Win7 x64, and Win7 x32)
>>> *How to check to see if you are having a same problem:* >>> Step 1) Download a large file. An example of a Large file (Linux ISO:700 >>> MB): http://releases.ubuntu.com/precise/ubuntu-12.04-desktop-amd64.iso >>> Step 2) Do a MD5 check-sum on the file. (Freeware MD5 check-sum >>> software: http://www.winmd5.com/) >>> Step 3) The Linux ISO MD5 Check-sum are located at: >>> http://releases.ubuntu.com/precise/MD5SUMS >>> - File:ubuntu-12.04-desktop-amd64.iso MD5 >>> Check-sum:128f0c16f4734c420b0185a492d92e52 >>> Step 4) If they match then there is no issue, if they don't match you >>> have the corruption issue
I think I am seeing the same thing with the node at 178 Centre.
I have been trying to download two 350MB files of types I have downloaded successfully many times before.
One is a magazine from the Apple Newsstand. It would stop with a message that the download failed - try any later. Retrying would restart from where it left off (sometimes dropping the last 20 MB or so) so eventually it finished.
The other is an app from the Apple Store. It fails on both my iPad and iMac with an error that the file appears to be corrupted. Since retries here start over, I have been unable to download it. If it was really corrupted, nobody would be able to download it and Apple would fix it. Since both my computers are acting the same, I doubt it is them. This seems to leave the transmission path.
On Sunday, July 22, 2012 11:13:35 PM UTC-7, niemic wrote:
> *Summary:* > Google WiFi TCP packets are getting corrupted but protocol layer is not > detecting it at Node MAC-00:0D:97:03:24:5C BSSID-00:0D:97:00:50:62 (Corner > of Ada Ave & Brenton Ct)
> *My background:* I am a SW engineer who is helping out some people who > are in the same complex that I am. > *Location: * Free Google Node :MAC-00:0D:97:03:24:5C > BSSID-00:0D:97:00:50:62 (Corner of Ada Ave & Brenton Ct)
> *Details*: > What I have found is that every so often (about ones(1) for every 100MB) a > corrupted TCP packet comes in that the protocol layer does not detect as > being invalid (pass TCP CRC check). Typically it will add a bit and remove > a bit from some where in the TCP packet. I have found it happens more at > peak-usage than at other times. It is happening on a every system, I have > looked at. (Win XP SP3, Win7 x64, and Win7 x32)
> *How to check to see if you are having a same problem:* > Step 1) Download a large file. An example of a Large file (Linux ISO:700 > MB): http://releases.ubuntu.com/precise/ubuntu-12.04-desktop-amd64.iso > Step 2) Do a MD5 check-sum on the file. (Freeware MD5 check-sum software: > http://www.winmd5.com/) > Step 3) The Linux ISO MD5 Check-sum are located at: > http://releases.ubuntu.com/precise/MD5SUMS > - File:ubuntu-12.04-desktop-amd64.iso MD5 > Check-sum:128f0c16f4734c420b0185a492d92e52 > Step 4) If they match then there is no issue, if they don't match you have > the corruption issue
It looks like I'm having the same issue at 1874 Elsie. The errors aren't detected until zip or rar tries to unarchive it and finds a dozen or so CRC errors. If I redownload the file I get CRC errors in a different place. This has been happening at least since last week, 8/13.
I reported earlier on my problems downloading a large (355mb) app that kept failing when it tried to install. iMac message was that the file appeared to be garbled. Tried several times over many days with the same result. Earlier this week I was traveling and succesfully downloaded the app to my IPad with no problems. Therefore it would appear to be a network problem, not one with my computers or the source of the file.
After returning home, last night my iMac tried to download a new version of adobe acrobat and it failed part way through. Don't know if it is the same problem.
Additional information. I currently have two large magazines and 3 iPad apps to download and am getting errors on all of them. This is with the radio at 178 Centre and GoogleWifiSecure, but it appears from this thread that people are having problems at other places also.
1. I had no problems downloading files until I returned from a two week trip the end of last month, so the problem is 4-6 weeks old.
2. Cannot download on either my iPad or iMac, so it is not the computers.
3. I can successfully download the files using wifi networks that are not part of Google wifi.
4. I just sat on the curb across the street from 178 Centre and tried to download using GoogleWiFi. Got the same result, so it is not my in-house network equipment.
My conclusion is that there is a new problem with the system as of the last month, affecting several radios. I hope I am not going to have to find a friend in another town to do all my downloads from now on. If I get a chance next week I may go to the MV library and try there.
On Sunday, July 22, 2012 11:13:35 PM UTC-7, niemic wrote:
> *Summary:* > Google WiFi TCP packets are getting corrupted but protocol layer is not > detecting it at Node MAC-00:0D:97:03:24:5C BSSID-00:0D:97:00:50:62 (Corner > of Ada Ave & Brenton Ct)
> *My background:* I am a SW engineer who is helping out some people who > are in the same complex that I am. > *Location: * Free Google Node :MAC-00:0D:97:03:24:5C > BSSID-00:0D:97:00:50:62 (Corner of Ada Ave & Brenton Ct)
> *Details*: > What I have found is that every so often (about ones(1) for every 100MB) a > corrupted TCP packet comes in that the protocol layer does not detect as > being invalid (pass TCP CRC check). Typically it will add a bit and remove > a bit from some where in the TCP packet. I have found it happens more at > peak-usage than at other times. It is happening on a every system, I have > looked at. (Win XP SP3, Win7 x64, and Win7 x32)
> *How to check to see if you are having a same problem:* > Step 1) Download a large file. An example of a Large file (Linux ISO:700 > MB): http://releases.ubuntu.com/precise/ubuntu-12.04-desktop-amd64.iso > Step 2) Do a MD5 check-sum on the file. (Freeware MD5 check-sum software: > http://www.winmd5.com/) > Step 3) The Linux ISO MD5 Check-sum are located at: > http://releases.ubuntu.com/precise/MD5SUMS > - File:ubuntu-12.04-desktop-amd64.iso MD5 > Check-sum:128f0c16f4734c420b0185a492d92e52 > Step 4) If they match then there is no issue, if they don't match you have > the corruption issue
Total system failure at 2309 Rock St today since 8AM again, once again. Only able to send this from my iPhone.
Serious system failure going on here "Sending trucks out" will not fix this system wide issue, nor will 'adjustments' to Google servers.
Interesting that no complaints from downtown MV users.
Who's being served here, wifi4all?
Cheers
Sent from my iPhone
On Aug 31, 2012, at 2:44 PM, pingle <pin...@earthlink.net> wrote:
> Additional information. I currently have two large magazines and 3 iPad apps to download and am getting errors on all of them. This is with the radio at 178 Centre and GoogleWifiSecure, but it appears from this thread that people are having problems at other places also.
> 1. I had no problems downloading files until I returned from a two week trip the end of last month, so the problem is 4-6 weeks old.
> 2. Cannot download on either my iPad or iMac, so it is not the computers.
> 3. I can successfully download the files using wifi networks that are not part of Google wifi.
> 4. I just sat on the curb across the street from 178 Centre and tried to download using GoogleWiFi. Got the same result, so it is not my in-house network equipment.
> My conclusion is that there is a new problem with the system as of the last month, affecting several radios.
> I hope I am not going to have to find a friend in another town to do all my downloads from now on.
> If I get a chance next week I may go to the MV library and try there.
> On Sunday, July 22, 2012 11:13:35 PM UTC-7, niemic wrote:
> Summary:
> Google WiFi TCP packets are getting corrupted but protocol layer is not detecting it at Node MAC-00:0D:97:03:24:5C BSSID-00:0D:97:00:50:62 (Corner of Ada Ave & Brenton Ct)
> My background: I am a SW engineer who is helping out some people who are in the same complex that I am.
> Location: Free Google Node :MAC-00:0D:97:03:24:5C BSSID-00:0D:97:00:50:62 (Corner of Ada Ave & Brenton Ct)
> Details:
> What I have found is that every so often (about ones(1) for every 100MB) a corrupted TCP packet comes in that the protocol layer does not detect as being invalid (pass TCP CRC check). Typically it will add a bit and remove a bit from some where in the TCP packet. I have found it happens more at peak-usage than at other times. It is happening on a every system, I have looked at. (Win XP SP3, Win7 x64, and Win7 x32)
> How to check to see if you are having a same problem:
> Step 1) Download a large file. An example of a Large file (Linux ISO:700 MB): http://releases.ubuntu.com/precise/ubuntu-12.04-desktop-amd64.iso > Step 2) Do a MD5 check-sum on the file. (Freeware MD5 check-sum software: http://www.winmd5.com/)
> Step 3) The Linux ISO MD5 Check-sum are located at: http://releases.ubuntu.com/precise/MD5SUMS > - File:ubuntu-12.04-desktop-amd64.iso MD5 Check-sum:128f0c16f4734c420b0185a492d92e52
> Step 4) If they match then there is no issue, if they don't match you have the corruption issue
> -- > You received this message because you are subscribed to the Google Groups "Google WiFi Network" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/google-wifi-network/-/WQtHM2wiZJIJ.
> To post to this group, send email to google-wifi-network@googlegroups.com.
> To unsubscribe from this group, send email to google-wifi-network+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-wifi-network?hl=en.
It seems as if its time for me to chime in here as well. The node info I connect to:
SSID: GoogleWiFiSecure BSSID: 00:0d:97:14:0a:dc Uplink SNR: 46 dB Node Noise: -93 dBm Uplink Bit Rate: 54 Mbps Downlink Bit Rate: 54 Mbp
For several weeks we have experienced slow speeds, data corruption, failed installs, failed down loads, unable to connecst. I have to agree that it appears to be bad check sums. Since these issues are relatively recent, and others have expressed similar issues, I have to conclude its neither the source or the destination devices but on GoogleWiFi. If not the radios as wifi4all has said then somewhere within the infrastructure.
On Friday, August 31, 2012 3:04:46 PM UTC-7, GREGORY NELSON wrote:
> Total system failure at 2309 Rock St today since 8AM again, once again. > Only able to send this from my iPhone. > Serious system failure going on here > "Sending trucks out" will not fix this system wide issue, nor will > 'adjustments' to Google servers. > Interesting that no complaints from downtown MV users. > Who's being served here, wifi4all? > Cheers
> Sent from my iPhone
> On Aug 31, 2012, at 2:44 PM, pingle <pin...@earthlink.net <javascript:>> > wrote:
> Additional information. I currently have two large magazines and 3 iPad > apps to download and am getting errors on all of them. This is with the > radio at 178 Centre and GoogleWifiSecure, but it appears from this thread > that people are having problems at other places also.
> 1. I had no problems downloading files until I returned from a two week > trip the end of last month, so the problem is 4-6 weeks old.
> 2. Cannot download on either my iPad or iMac, so it is not the computers.
> 3. I can successfully download the files using wifi networks that are not > part of Google wifi.
> 4. I just sat on the curb across the street from 178 Centre and tried to > download using GoogleWiFi. Got the same result, so it is not my in-house > network equipment.
> My conclusion is that there is a new problem with the system as of the > last month, affecting several radios. > I hope I am not going to have to find a friend in another town to do all > my downloads from now on. > If I get a chance next week I may go to the MV library and try there.
> On Sunday, July 22, 2012 11:13:35 PM UTC-7, niemic wrote:
>> *Summary:* >> Google WiFi TCP packets are getting corrupted but protocol layer is not >> detecting it at Node MAC-00:0D:97:03:24:5C BSSID-00:0D:97:00:50:62 (Corner >> of Ada Ave & Brenton Ct)
>> *My background:* I am a SW engineer who is helping out some people who >> are in the same complex that I am. >> *Location: * Free Google Node :MAC-00:0D:97:03:24:5C >> BSSID-00:0D:97:00:50:62 (Corner of Ada Ave & Brenton Ct)
>> *Details*: >> What I have found is that every so often (about ones(1) for every 100MB) >> a corrupted TCP packet comes in that the protocol layer does not detect as >> being invalid (pass TCP CRC check). Typically it will add a bit and remove >> a bit from some where in the TCP packet. I have found it happens more at >> peak-usage than at other times. It is happening on a every system, I have >> looked at. (Win XP SP3, Win7 x64, and Win7 x32)
>> *How to check to see if you are having a same problem:* >> Step 1) Download a large file. An example of a Large file (Linux ISO:700 >> MB): http://releases.ubuntu.com/precise/ubuntu-12.04-desktop-amd64.iso >> Step 2) Do a MD5 check-sum on the file. (Freeware MD5 check-sum software: >> http://www.winmd5.com/) >> Step 3) The Linux ISO MD5 Check-sum are located at: >> http://releases.ubuntu.com/precise/MD5SUMS >> - File:ubuntu-12.04-desktop-amd64.iso MD5 >> Check-sum:128f0c16f4734c420b0185a492d92e52 >> Step 4) If they match then there is no issue, if they don't match you >> have the corruption issue
>> -- > You received this message because you are subscribed to the Google Groups > "Google WiFi Network" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/google-wifi-network/-/WQtHM2wiZJIJ. > To post to this group, send email to google-wi...@googlegroups.com<javascript:> > . > To unsubscribe from this group, send email to > google-wifi-network+unsubscribe@googlegroups.com <javascript:>. > For more options, visit this group at > http://groups.google.com/group/google-wifi-network?hl=en.
So frustrated with this Google non-response. Unable to connect since Friday @ 8AM - have reconfigured my Ruckus multiple times, as well as my AirPort Express - all to no avail.
Calling Comcast tomorrow to pay for a reliable WiFi connection.
GOOGLE SUCKS - what else do you envision screwing up in our connected world, cable TV ... And of course all things Apple!
GOOGLE IS USELESS and SHAMELESSLY SELFSERVING0 - no advertising money in free WiFi.
Sent from my iPhone
On Sep 2, 2012, at 1:04 PM, jxramos <jaime.x.ra...@gmail.com> wrote:
> I too have experienced failed downloads, updates, and installers that did manage to completely download ultimately reveal themselves as being corrupt.
> What's the bottom line with all this ? The radios are busting? This seems more pervasive than I originally imagined. Oh boy >< sure is frustrating.
> ~JXR
> -- > You received this message because you are subscribed to the Google Groups "Google WiFi Network" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/google-wifi-network/-/UZQmj6hvNIsJ.
> To post to this group, send email to google-wifi-network@googlegroups.com.
> To unsubscribe from this group, send email to google-wifi-network+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-wifi-network?hl=en.
I can't help but respond to your post. As for me, I am grateful for Google's FREE Wifi service. Can't beat the price. I believe that wifi4all and Google staff do their best to solve system problems. I'm sure that it was difficult for you to encounter these problems on a holiday weekend. It is frustrating when problems occur on weekends and holidays. According to every statistic, I live below the poverty level. I can't afford Comcast and I certainly can't afford the data plan to maintain an iPhone. (Unfortunately. I would really like one.) I'm sure that you will enjoy Comcast and that it won't strain your pocketbook.
The network has gone through a patch of problems in the last week or so. One of our sector antennas is down on the Google building. It is the sector which services the Rock street neighborhood -- as well as others in the area. We are actively working to fix the problem, and have replaced the antenna, the cabling, the electronic components, etc. but have not been able to restore service. We understand this outage is causing problems for our users and we are working to correct the problem.
We get that people rely on this service and we know we are letting people down when it fails.
We have to do better and we are planning to make some changes to improve our service. Thanks for your patience with this rough spot we are in.
WiFi4All
P.S. We are still figuring out what to do about the packet corruption issue.... once the network is whole again.
On Tuesday, September 4, 2012 1:34:15 AM UTC-7, spike wrote:
> Dear Gregory,
> I can't help but respond to your post. As for me, I am grateful for > Google's FREE Wifi service. Can't beat the price. I believe that wifi4all > and Google staff do their best to solve system problems. I'm sure that it > was difficult for you to encounter these problems on a holiday weekend. It > is frustrating when problems occur on weekends and holidays. According to > every statistic, I live below the poverty level. I can't afford Comcast and > I certainly can't afford the data plan to maintain an iPhone. > (Unfortunately. I would really like one.) I'm sure that you will enjoy > Comcast and that it won't strain your pocketbook.
This morning I went to the Mtn. View library and tried downloading using GoogleWiFi. Got the same problems I have at home, so the
problem is there also.
BTW: The file I am currently trying to download is the latest version of the Weather Channel app for the iPad. It is about 100MB. It is free
so anyone with an iPad can try it. It always loads to the same point on the progress bar, which I suspect is where the download is done and the
system is starting to decompress and install the program. At that point on the iPad it starts over. On the iMac it gives a message that the file
appears to be damaged.
> The network has gone through a patch of problems in the last week or so. One of our sector antennas is down on the Google building. It is the sector which services the Rock street neighborhood -- as well as others in the area. We are actively working to fix the problem, and have replaced the antenna, the cabling, the electronic components, etc. but have not been able to restore service. We understand this outage is causing problems for our users and we are working to correct the problem.
> We get that people rely on this service and we know we are letting people down when it fails.
> We have to do better and we are planning to make some changes to improve our service. Thanks for your patience with this rough spot we are in.
> WiFi4All
> P.S. We are still figuring out what to do about the packet corruption issue.... once the network is whole again.
> On Tuesday, September 4, 2012 1:34:15 AM UTC-7, spike wrote:
> Dear Gregory,
> I can't help but respond to your post. As for me, I am grateful for Google's FREE Wifi service. Can't beat the price. I believe that wifi4all and Google staff do their best to solve system problems. I'm sure that it was difficult for you to encounter these problems on a holiday weekend. It is frustrating when problems occur on weekends and holidays. According to every statistic, I live below the poverty level. I can't afford Comcast and I certainly can't afford the data plan to maintain an iPhone. (Unfortunately. I would really like one.) I'm sure that you will enjoy Comcast and that it won't strain your pocketbook.
> Spike
> -- > You received this message because you are subscribed to the Google Groups "Google WiFi Network" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/google-wifi-network/-/CRV64qfeK-IJ.
> To post to this group, send email to google-wifi-network@googlegroups.com.
> To unsubscribe from this group, send email to google-wifi-network+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-wifi-network?hl=en.
Thanks for the effort and thanks for a reproducible instance. We will try this and I will discuss with our engineers. From all the reports in this group, it seems there is something wrong. We will get back to you all after we have looked into it.
On Wednesday, September 5, 2012 11:33:01 AM UTC-7, pingle wrote:
> This morning I went to the Mtn. View library and tried downloading using > GoogleWiFi. Got the same problems I have at home, so the > problem is there also.
> BTW: The file I am currently trying to download is the latest version of > the Weather Channel app for the iPad. It is about 100MB. It is free > so anyone with an iPad can try it. It always loads to the same point on > the progress bar, which I suspect is where the download is done and the > system is starting to decompress and install the program. At that point > on the iPad it starts over. On the iMac it gives a message that the file > appears to be damaged.
> Karl
> On Sep 4, 2012, at 9:18 PM, wifi4all wrote:
> Hi all,
> The network has gone through a patch of problems in the last week or so. > One of our sector antennas is down on the Google building. It is the > sector which services the Rock street neighborhood -- as well as others in > the area. We are actively working to fix the problem, and have replaced > the antenna, the cabling, the electronic components, etc. but have not been > able to restore service. We understand this outage is causing problems > for our users and we are working to correct the problem.
> We get that people rely on this service and we know we are letting people > down when it fails.
> We have to do better and we are planning to make some changes to improve > our service. Thanks for your patience with this rough spot we are in.
> WiFi4All
> P.S. We are still figuring out what to do about the packet corruption > issue.... once the network is whole again.
> On Tuesday, September 4, 2012 1:34:15 AM UTC-7, spike wrote:
>> Dear Gregory,
>> I can't help but respond to your post. As for me, I am grateful for >> Google's FREE Wifi service. Can't beat the price. I believe that wifi4all >> and Google staff do their best to solve system problems. I'm sure that it >> was difficult for you to encounter these problems on a holiday weekend. It >> is frustrating when problems occur on weekends and holidays. According to >> every statistic, I live below the poverty level. I can't afford Comcast and >> I certainly can't afford the data plan to maintain an iPhone. >> (Unfortunately. I would really like one.) I'm sure that you will enjoy >> Comcast and that it won't strain your pocketbook.
>> Spike
> -- > You received this message because you are subscribed to the Google Groups > "Google WiFi Network" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/google-wifi-network/-/CRV64qfeK-IJ. > To post to this group, send email to google-wi...@googlegroups.com<javascript:> > . > To unsubscribe from this group, send email to > google-wifi-network+unsubscribe@googlegroups.com <javascript:>. > For more options, visit this group at > http://groups.google.com/group/google-wifi-network?hl=en.
After seeing this issue from the 698 West Dana Street node for while, I've resorted to sneaker-net from work for large/important files.
I've also tried to do some concrete analysis of the issue. This is going to get a bit technical...
I put some known large test files with complex random data on an Amazon EC2 node (from work) and wrote a fairly simple test tool that pulls a nominated reference file using HTTP and performs MD5 checksums every N bytes in addition to an overall MD5 checksum. The resulting set of checksums can then be compared to a reference set allowing detection of corruption at a "block" level as well as at an overall file level.
Testing with a 10Mbyte test file and 128byte blocks, while I can periodically get successful test runs, I also see frequent failures. When I do get failures, very few of the blocks are corrupt. I've seen as few as 1, and as many as 6 (which is a maximum of 0.007% of the blocks in the file; likely a lot less of the file itself), and usually there is slight clumping of the corruption in the HTTP stream.
Each run I see in netstat statistics output hundreds of packets discarded due for bad checksums (although I don't have any reference for this, and I'm not 100% sure I'm looking at the right counter).
Hopefully this is useful information. It would be great to see progress on this issue, as it makes any kind of software upgrade impossible, downloads that don't have checksum checks dangerous.
Tom
On Sep 5, 2012, at 12:42 PM, wifi4all <wifi4...@gmail.com> wrote:
> Thanks for the effort and thanks for a reproducible instance. We will try this and I will discuss with our engineers. From all the reports in this group, it seems there is something wrong. We will get back to you all after we have looked into it.
> WiFi4All
> On Wednesday, September 5, 2012 11:33:01 AM UTC-7, pingle wrote:
> This morning I went to the Mtn. View library and tried downloading using GoogleWiFi. Got the same problems I have at home, so the
> problem is there also.
> BTW: The file I am currently trying to download is the latest version of the Weather Channel app for the iPad. It is about 100MB. It is free
> so anyone with an iPad can try it. It always loads to the same point on the progress bar, which I suspect is where the download is done and the
> system is starting to decompress and install the program. At that point on the iPad it starts over. On the iMac it gives a message that the file
> appears to be damaged.
> Karl
> On Sep 4, 2012, at 9:18 PM, wifi4all wrote:
>> Hi all,
>> The network has gone through a patch of problems in the last week or so. One of our sector antennas is down on the Google building. It is the sector which services the Rock street neighborhood -- as well as others in the area. We are actively working to fix the problem, and have replaced the antenna, the cabling, the electronic components, etc. but have not been able to restore service. We understand this outage is causing problems for our users and we are working to correct the problem.
>> We get that people rely on this service and we know we are letting people down when it fails.
>> We have to do better and we are planning to make some changes to improve our service. Thanks for your patience with this rough spot we are in.
>> WiFi4All
>> P.S. We are still figuring out what to do about the packet corruption issue.... once the network is whole again.
>> On Tuesday, September 4, 2012 1:34:15 AM UTC-7, spike wrote:
>> Dear Gregory,
>> I can't help but respond to your post. As for me, I am grateful for Google's FREE Wifi service. Can't beat the price. I believe that wifi4all and Google staff do their best to solve system problems. I'm sure that it was difficult for you to encounter these problems on a holiday weekend. It is frustrating when problems occur on weekends and holidays. According to every statistic, I live below the poverty level. I can't afford Comcast and I certainly can't afford the data plan to maintain an iPhone. (Unfortunately. I would really like one.) I'm sure that you will enjoy Comcast and that it won't strain your pocketbook.
>> Spike
>> -- >> You received this message because you are subscribed to the Google Groups "Google WiFi Network" group.
>> To view this discussion on the web visit https://groups.google.com/d/msg/google-wifi-network/-/CRV64qfeK-IJ.
>> To post to this group, send email to google-wi...@googlegroups.com.
>> To unsubscribe from this group, send email to google-wifi-network+unsubscribe@googlegroups.com.
>> For more options, visit this group at http://groups.google.com/group/google-wifi-network?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "Google WiFi Network" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/google-wifi-network/-/6qGYNO9cC-0J.
> To post to this group, send email to google-wifi-network@googlegroups.com.
> To unsubscribe from this group, send email to google-wifi-network+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-wifi-network?hl=en.
> After seeing this issue from the 698 West Dana Street node for while, I've resorted to sneaker-net from work for large/important files.
> I've also tried to do some concrete analysis of the issue. This is going to get a bit technical...
> I put some known large test files with complex random data on an Amazon EC2 node (from work) and wrote a fairly simple test tool that pulls a nominated reference file using HTTP and performs MD5 checksums every N bytes in addition to an overall MD5 checksum. The resulting set of checksums can then be compared to a reference set allowing detection of corruption at a "block" level as well as at an overall file level.
> Testing with a 10Mbyte test file and 128byte blocks, while I can periodically get successful test runs, I also see frequent failures. When I do get failures, very few of the blocks are corrupt. I've seen as few as 1, and as many as 6 (which is a maximum of 0.007% of the blocks in the file; likely a lot less of the file itself), and usually there is slight clumping of the corruption in the HTTP stream.
> Each run I see in netstat statistics output hundreds of packets discarded due for bad checksums (although I don't have any reference for this, and I'm not 100% sure I'm looking at the right counter).
> Hopefully this is useful information. It would be great to see progress on this issue, as it makes any kind of software upgrade impossible, downloads that don't have checksum checks dangerous.
> Tom
> On Sep 5, 2012, at 12:42 PM, wifi4all <wifi4...@gmail.com> wrote:
>> Hi,
>> Thanks for the effort and thanks for a reproducible instance. We will try this and I will discuss with our engineers. From all the reports in this group, it seems there is something wrong. We will get back to you all after we have looked into it.
>> WiFi4All
>> On Wednesday, September 5, 2012 11:33:01 AM UTC-7, pingle wrote:
>> This morning I went to the Mtn. View library and tried downloading using GoogleWiFi. Got the same problems I have at home, so the
>> problem is there also.
>> BTW: The file I am currently trying to download is the latest version of the Weather Channel app for the iPad. It is about 100MB. It is free
>> so anyone with an iPad can try it. It always loads to the same point on the progress bar, which I suspect is where the download is done and the
>> system is starting to decompress and install the program. At that point on the iPad it starts over. On the iMac it gives a message that the file
>> appears to be damaged.
>> Karl
>> On Sep 4, 2012, at 9:18 PM, wifi4all wrote:
>>> Hi all,
>>> The network has gone through a patch of problems in the last week or so. One of our sector antennas is down on the Google building. It is the sector which services the Rock street neighborhood -- as well as others in the area. We are actively working to fix the problem, and have replaced the antenna, the cabling, the electronic components, etc. but have not been able to restore service. We understand this outage is causing problems for our users and we are working to correct the problem.
>>> We get that people rely on this service and we know we are letting people down when it fails.
>>> We have to do better and we are planning to make some changes to improve our service. Thanks for your patience with this rough spot we are in.
>>> WiFi4All
>>> P.S. We are still figuring out what to do about the packet corruption issue.... once the network is whole again.
>>> On Tuesday, September 4, 2012 1:34:15 AM UTC-7, spike wrote:
>>> Dear Gregory,
>>> I can't help but respond to your post. As for me, I am grateful for Google's FREE Wifi service. Can't beat the price. I believe that wifi4all and Google staff do their best to solve system problems. I'm sure that it was difficult for you to encounter these problems on a holiday weekend. It is frustrating when problems occur on weekends and holidays. According to every statistic, I live below the poverty level. I can't afford Comcast and I certainly can't afford the data plan to maintain an iPhone. (Unfortunately. I would really like one.) I'm sure that you will enjoy Comcast and that it won't strain your pocketbook.
>>> Spike
>>> -- >>> You received this message because you are subscribed to the Google Groups "Google WiFi Network" group.
>>> To view this discussion on the web visit https://groups.google.com/d/msg/google-wifi-network/-/CRV64qfeK-IJ.
>>> To post to this group, send email to google-wi...@googlegroups.com.
>>> To unsubscribe from this group, send email to google-wifi-network+unsubscribe@googlegroups.com.
>>> For more options, visit this group at http://groups.google.com/group/google-wifi-network?hl=en.
>> -- >> You received this message because you are subscribed to the Google Groups "Google WiFi Network" group.
>> To view this discussion on the web visit https://groups.google.com/d/msg/google-wifi-network/-/6qGYNO9cC-0J.
>> To post to this group, send email to google-wifi-network@googlegroups.com.
>> To unsubscribe from this group, send email to google-wifi-network+unsubscribe@googlegroups.com.
>> For more options, visit this group at http://groups.google.com/group/google-wifi-network?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "Google WiFi Network" group.
> To post to this group, send email to google-wifi-network@googlegroups.com.
> To unsubscribe from this group, send email to google-wifi-network+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-wifi-network?hl=en.
Hi! I'm on San Antonio Circle. I've been having problems trying to install downloaded files and software updates only to realize that they are corrupted. Unfortunately I don't have the analysis tools that some of you have. The file sizes have been 60-80 MB. The statistics package that I was trying to download is necessary for my class tomorrow. I hope that this problem is resolved soon. Thanks wifi4all!
I am traveling enough to find wifi hotspots to get my iPad data downloaded, but the only way I can download larger files to my iMac would be to subscribe to Comcast, or carry my 28" iMac to a friend's house in another town.
Currently, I am waiting to be able to download a security patch for Adobe, a large pdf with investment information, and a new release of my bookkeeping software. The next IOS release is coming out and requires a new iTunes version on my iMac that I cannot download .This has been going on since the beginning of July. WE NEED A FIX (shouting deliberate).
On Sunday, July 22, 2012 11:13:35 PM UTC-7, niemic wrote:
> *Summary:* > Google WiFi TCP packets are getting corrupted but protocol layer is not > detecting it at Node MAC-00:0D:97:03:24:5C BSSID-00:0D:97:00:50:62 (Corner > of Ada Ave & Brenton Ct)
> *My background:* I am a SW engineer who is helping out some people who > are in the same complex that I am. > *Location: * Free Google Node :MAC-00:0D:97:03:24:5C > BSSID-00:0D:97:00:50:62 (Corner of Ada Ave & Brenton Ct)
> *Details*: > What I have found is that every so often (about ones(1) for every 100MB) a > corrupted TCP packet comes in that the protocol layer does not detect as > being invalid (pass TCP CRC check). Typically it will add a bit and remove > a bit from some where in the TCP packet. I have found it happens more at > peak-usage than at other times. It is happening on a every system, I have > looked at. (Win XP SP3, Win7 x64, and Win7 x32)
> *How to check to see if you are having a same problem:* > Step 1) Download a large file. An example of a Large file (Linux ISO:700 > MB): http://releases.ubuntu.com/precise/ubuntu-12.04-desktop-amd64.iso > Step 2) Do a MD5 check-sum on the file. (Freeware MD5 check-sum software: > http://www.winmd5.com/) > Step 3) The Linux ISO MD5 Check-sum are located at: > http://releases.ubuntu.com/precise/MD5SUMS > - File:ubuntu-12.04-desktop-amd64.iso MD5 > Check-sum:128f0c16f4734c420b0185a492d92e52 > Step 4) If they match then there is no issue, if they don't match you have > the corruption issue
> data corruption started happening quite often at Bryant & Villa in the
> past week or so. By quite often I mean every every 10MB or so.
> I have been using this node for years with no problems like this. Since
> last week it's almost unusable for downloading medium size files.
> thanks
> Oggie
> On Saturday, July 28, 2012 11:20:15 PM UTC-7, niemic wrote:
>> Hi WiFi4All,
>> First, sorry for not getting back to you sooner.
>> Second, I believe your analysis is missing a few parts of the picture.
>> Let me explain more.
>> When you have TCP checksum issue, you can see if that the case by looking
>> at the Ethernet statistics (on windows command prompt type: netstat -e ).
>> There is a field called "Errors". When there is a TCP checksum mismatch
>> happen, the statistics will record an error and issue a resend of the TCP
>> packet. On my system, and my neighbor systems the number of "Errors" where
>> very small. They where in the order of 0 or 1. Also, the chances that
>> there a bad TCP packet and the TCP Checksum didn't catch it is 1/2^16 (1 in
>> 65,536 corrupted packages) if all failures are equally likely.
>> Let me explain what we are seeing in more details. Let me talk about
>> what bytes are different when you look at the difference of a larger file
>> like the Linux ISO.
>> From above you can see bit 0x20 is sometimes remove or added. This is
>> signs of a flaky bit on a DRAM chip.
>> Next question is where is this flaky DRAM located. We believe, this can
>> not be in the DRAM of our WiFi cards because the problem happens they same
>> way on neighbors and my system. From above, we know that if the TCP
>> checksum is in place and as you said there is other protect to make sure
>> the RF side of the WiFi has no issue. Therefore, the place to look is
>> where the TCP checksum is being re-calculated on the system. This normally
>> happens on the system when the system splits or combines TCP packets
>> together. My guess is the AP node, has the flaky DRAM. I am assuming it
>> does the splitting or combining TCP packets together before sending them
>> out.
>> *Note: *a side effect of flaky DRAM is that if you reboot the system,
>> the problem may move or change. This is because memory allocation and
>> what part of the system using the flaky bit of the DRAM will have problems
>> . If this location on the DRAM is not touching anything important, you
>> will not see any issue.
>> Thanks again for looking in to the issue
>> On Wednesday, July 25, 2012 2:05:35 PM UTC-7, wifi4all wrote:
>>> Hi,
>>> Thanks for the detailed analysis.
>>> We have discussed the issue with several folks around here and there are
>>> several things to note....
>>> 1) Data corruption happens quite often (unfortunately) in WiFi and even
>>> more in large area (i.e. city-wide) WiFi due to interference or noise. The
>>> FCS in each WiFi frame is designed to detect these problems and correct
>>> them -- but it is not mathematically 100% guaranteed. There are, as you
>>> have discovered, corner cases which will result in an acceptance of a
>>> packet which is technically corrupted.
>>> 2) Our radios (the Tropos radios) do not do TCP checksums on user
>>> payloads. This is part of the TCP control layer and is handled by each end
>>> point separately. We do do packet level checks to verify the integrity of
>>> the packets.
>>> I am surprised at your reported prevalence....we certainly have users of
>>> run at the maximum data rate (3 Mbps down and 1 Mbps up) for 24 hours a day
>>> and we pass close to 600 GB of traffic a day -- but this is the first we
>>> have heard of this.
>>> Not sure what the next step is....
>>> WiFi4All
>>> On Sunday, July 22, 2012 11:13:35 PM UTC-7, niemic wrote:
>>>> *Summary:*
>>>> Google WiFi TCP packets are getting corrupted but protocol layer is not
>>>> detecting it at Node MAC-00:0D:97:03:24:5C BSSID-00:0D:97:00:50:62 (Corner
>>>> of Ada Ave & Brenton Ct)
>>>> *My background:* I am a SW engineer who is helping out some people who
>>>> are in the same complex that I am.
>>>> *Location: * Free Google Node :MAC-00:0D:97:03:24:5C
>>>> BSSID-00:0D:97:00:50:62 (Corner of Ada Ave & Brenton Ct)
>>>> *Details*:
>>>> What I have found is that every so often (about ones(1) for every
>>>> 100MB) a corrupted TCP packet comes in that the protocol layer does not
>>>> detect as being invalid (pass TCP CRC check). Typically it will add a bit
>>>> and remove a bit from some where in the TCP packet. I have found it
>>>> happens more at peak-usage than at other times. It is happening on a every
>>>> system, I have looked at. (Win XP SP3, Win7 x64, and Win7 x32)
>>>> Step 2) Do a MD5 check-sum on the file. (Freeware MD5 check-sum
>>>> software: http://www.winmd5.com/)
>>>> Step 3) The Linux ISO MD5 Check-sum are located at:
>>>> http://releases.ubuntu.com/**precise/MD5SUMS<http://releases.ubuntu.com/precise/MD5SUMS>
>>>> - File:ubuntu-12.04-desktop-**amd64.iso MD5 Check-sum:**
>>>> 128f0c16f4734c420b0185a492d92e**52
>>>> Step 4) If they match then there is no issue, if they don't match you
>>>> have the corruption issue
>>>> --
> You received this message because you are subscribed to the Google Groups
> "Google WiFi Network" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/google-wifi-network/-/qJCV2pAhxNgJ.
> To post to this group, send email to google-wifi-network@googlegroups.com.
> To unsubscribe from this group, send email to
> google-wifi-network+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-wifi-network?hl=en.
