So, tonight I started having difficulty getting onto some but not all websites. This happens sometimes, for any of a number of reasons. So I went through my usual troubleshooting.
First, I restarted the bind9 server that runs on my gateway box and provides DNS for our home network. I don't rely on Comcast's DNS, instead using DNS the way it was intended to be used. The server has been known to get fubared, and restarting it is trivial. Anyway, didn't help.
Next, I rebooted my laptop. My laptop runs Windows XP, which is certainly not the world's stablest platform, so restarting might help. But not this time.
So my next consideration is Comcast, who has been known of late to do various high-level traffic mucking. I fire up my Verizon NationalAccess card, and the sites I wasn't able to get to do become available. But this isn't the end of the story.
Comparing DNS from my laptop (on Verizon) and one of my Linux boxes (using Comcast) show identical resolution, and pings to both go through. So, as a test, I use lynx on the Linux box to connect to www.google.com, one of the sites that my laptop couldn't get to. Voila, a connection occurs. Further experimentation shows that I can access www.google.com from my laptop even when connected using Comcast, but only if I use a browser other than Firefox. Sitemeter, a site that I use for analytics on my blog, is showing the same behavior (site loads in IE, but not in Firefox). Both sites load in Firefox if I use Verizon.
Other sites, such as Bloglines, load no matter how I connect to them. I had to post this via Verizon because blogger.com is also affected by whatever this is.
I cannot fathom why Comcast would crap on traffic to Google.com and Sitemeter.com, but not Bloglines.com, but only when using Firefox. I know that Comcast likes to send random RST packets to people, but this combination of factors simply makes no sense to me.
On further research, I have determined that I am getting random RST packets on connections to properties owned by Google. I don't get them from the IE session because I don't have a Google cookie in my IE session, and so the load of www.google.com is too short for Comcast's GoogleWhacker to reset the session. I am signed in in Firefox, and so the complex series of transactions that occurs when I load www.google.com in Firefox gets whacked by a pair of TCP resets.
Sadly, I don't have much of a choice but to use Comcast.
Update: Shortly after I posted this, the situation resolved itself. So it could have been a "technical error", but if so, it's one caused by Comcast's insistence on its right to forge RST packets into TCP sessions it doesn't like. This is just another reason why we need net neutrality.
First, I restarted the bind9 server that runs on my gateway box and provides DNS for our home network. I don't rely on Comcast's DNS, instead using DNS the way it was intended to be used. The server has been known to get fubared, and restarting it is trivial. Anyway, didn't help.
Next, I rebooted my laptop. My laptop runs Windows XP, which is certainly not the world's stablest platform, so restarting might help. But not this time.
So my next consideration is Comcast, who has been known of late to do various high-level traffic mucking. I fire up my Verizon NationalAccess card, and the sites I wasn't able to get to do become available. But this isn't the end of the story.
Comparing DNS from my laptop (on Verizon) and one of my Linux boxes (using Comcast) show identical resolution, and pings to both go through. So, as a test, I use lynx on the Linux box to connect to www.google.com, one of the sites that my laptop couldn't get to. Voila, a connection occurs. Further experimentation shows that I can access www.google.com from my laptop even when connected using Comcast, but only if I use a browser other than Firefox. Sitemeter, a site that I use for analytics on my blog, is showing the same behavior (site loads in IE, but not in Firefox). Both sites load in Firefox if I use Verizon.
Other sites, such as Bloglines, load no matter how I connect to them. I had to post this via Verizon because blogger.com is also affected by whatever this is.
I cannot fathom why Comcast would crap on traffic to Google.com and Sitemeter.com, but not Bloglines.com, but only when using Firefox. I know that Comcast likes to send random RST packets to people, but this combination of factors simply makes no sense to me.
On further research, I have determined that I am getting random RST packets on connections to properties owned by Google. I don't get them from the IE session because I don't have a Google cookie in my IE session, and so the load of www.google.com is too short for Comcast's GoogleWhacker to reset the session. I am signed in in Firefox, and so the complex series of transactions that occurs when I load www.google.com in Firefox gets whacked by a pair of TCP resets.
Sadly, I don't have much of a choice but to use Comcast.
Update: Shortly after I posted this, the situation resolved itself. So it could have been a "technical error", but if so, it's one caused by Comcast's insistence on its right to forge RST packets into TCP sessions it doesn't like. This is just another reason why we need net neutrality.
More proof that we NEED net neutrality. The alternatives are scary bad.
ReplyDeleteWhile y'all wait for net neutrality you could try a VPN (I use OpenVPN) into a colo'd proxy server.
ReplyDeleteWhile y'all wait for net neutrality you could try a VPN (I use OpenVPN) into a colo'd proxy server.
ReplyDeleteand then find yourself blocked on Wikipedia because various people, Kelly included, saw fit to blindly mass-block any colo provider they could find. :(
Good thing I don't edit Wikipedia, then :)
ReplyDeleteVerizon broadband apparently does something similar in DC. At least they're marginally better than Comcrap.
ReplyDelete(I have no problem with verizon wireless, my nationalaccess works great, but their home and business dsl, a separate division entirely, is trash.)