how-to block ads
|
FromSnowLand
@comcast.net
| reply to xfezz2
Re: Problems loading google (DNS issues possibly?)
I have been having the same problem for over a week. Here is what I have found:
1) it only happens between 7 pm and midnight
2) only happens if I have been downloading for over an hour (news-reader - no impact on downloads)
3) only impacts iGoogle, Google search & Google Reader (gmail & google news work fine)
I did some testing and if I go through a HTTP Proxy service, I can access the 3 google services just fine, even though at the same time I get the connection resets directly.
I have heard the Comcast is using the Sandvine service to manage traffic, that these devices are internal to the Comcast network (not at the edge) and are responsible for the resets. I suspect that Sandvine has determined certain Google services are p2p and is issuing resets to slow them down, but since they are really web applications, they die when reset (conjecture on my part).
| |
Nubiatech
soy capitan
join:2007-09-02
Illinois
| reply to xfezz2
Thanks clayjar  and svideo for providing packet captures.
Here are my observations:
1. After google recieves an SYN from clayjar 's computer, it replies with SYN/ACK
Pay attention to the following:
-- time to live (ttl 53) (it means google is 11 hops away, but we are not concerned about the exact number).
-- the tcp timestamp (28289791)
-- the tcp window size (win 5672). Note that OS defaults differ on this value (check dslreports.com speed tweaks faqs).
2. After the computer completes the handshake by sending an ACK and start the connection(PSH), here come the mysterious RSTs:
Here we have a ttl 51 which indicates that these packet are not from the original source (Google). Another clue is the tcp window size (win 10240), which can not be that high without scaling after a connection is established. It is clear that this a different host sitting in the middle. Also note that the 2 RST packets were sent 0.0017 seconds in between! This is very unusual.
And tcp timestamp 28290791, although optional, but decreased!?
3.
The computer upon recieving the RST, replies with an RST and closes its side of the connection:
4. And finally, ffw, Google upon recieving RSTs from the host in the middle, closes its side of the connection. Note here we confirm it is google: (ttl 53), a consistent tcp timestamp (28289791), and a low (win 6432). No need to go into window scaling discussion.
Conclusion: there is something out there resetting tcp connection to that ip address.
Now, the question is: how come it is possible to use the ip address directly to connect to Google?
My answer: most likely a DNS issue. It could be that at certain times of the day, Google.com DNS entries change to ip addresses that "the host in the middle" above does not like. Keep in mind that, as mentioned in this thread, that Google's DNS entries have very short TTLs:
| |
SuperNet33
Go Ninja,Go Ninja Go..
Premium
join:2002-10-08
Harwood Heights, IL
clubs:   
 ·AT&T CallVantage
| reply to FromSnowLand
said by FromSnowLand :
I have been having the same problem for over a week. Here is what I have found:
1) it only happens between 7 pm and midnight
2) only happens if I have been downloading for over an hour (news-reader - no impact on downloads)
3) only impacts iGoogle, Google search & Google Reader (gmail & google news work fine)
Almost the same thing but my speeds drop down to 2megs
--
Comcast HSI 8.0-768 / ATT CV - VoIP / »www.TalkAboutVoIP.COM - VoIP news & help / »www.ChicagoMaximaClub.net - My Website ! | |
clayjar
join:2007-10-30
Plainfield, IL | reply to Nubiatech
Thanks, Nubiatech. That was the best detailed explanation/interpretation offered so far. Someone from Comcast needs to look into this and fix it. | |
espaeth
Digital Plumber
Premium,MVM
join:2001-04-21
Minneapolis, MN
·voip.ms
·Vitelity VOIP
·Callcentric
·VoiceStick
·ViaTalk
 ·Comcast
 ·Embarq
| said by clayjar :Thanks, Nubiatech. That was the best detailed explanation/interpretation offered so far. Someone from Comcast needs to look into this and fix it. Actually that analysis would tend to suggest it's something on Google's side. The resets are coming from too far out to be Comcast. | |
Nubiatech
soy capitan
join:2007-09-02
Illinois
| said by espaeth :said by clayjar :Thanks, Nubiatech. That was the best detailed explanation/interpretation offered so far. Someone from Comcast needs to look into this and fix it. Actually that analysis would tend to suggest it's something on Google's side. The resets are coming from too far out to be Comcast. Although the ttl's suggest the resets are coming from further up (ttl 51 = 13 hops), it is not necessarily so. TTLs could easily be manipulated or setup to suggest just that.
It gets even more interesting,
Can't get to www.google.com? then try:
»google.navigation.opendns.com
This opens a new can of worms: is Comcast also trying to redirect and cache Google traffic just like OpenDNS is doing? (Ref: »forums.opendns.com/comments.php?···1#Item_0) | |
espaeth
Digital Plumber
Premium,MVM
join:2001-04-21
Minneapolis, MN
·voip.ms
·Vitelity VOIP
·Callcentric
·VoiceStick
·ViaTalk
·Comcast
·Embarq
| said by Nubiatech :Although the ttl's suggest the resets are coming from further up (ttl 51 = 13 hops), it is not necessarily so. TTLs could easily be manipulated or setup to suggest just that. Agreed. All things being equal though, Comcast isn't the only ISP having this problem, which would also tend to suggest something closer to Google's network. | |
scottwed
join:2005-06-23
Lehi, UT
| Just curious, does anyone have a list of other ISPs with the same issue?
I'm also perplexed as to how Hamachi is also having the same issue (the packet traces are identical in regards to the odd resets).
For the record, I haven't had the issue for 3 days now, but I've also scheduled any significant traffic to occur after midnight. | |
espaeth
Digital Plumber
Premium,MVM
join:2001-04-21
Minneapolis, MN | ATT and Sonic.net have been reported here.
»Can't access Google domains.
»Can't access google.com? | |
|
