Monthly Archives: December 2009

Leveraging Your Settlement

Comcast owes me money. They owe lots of people money.


In 2007 and 2008 Comcast forged TCP RST packets in order to throttle P2P and other kinds of traffic. This resulted in several class-action lawsuits. They recently settled one of them and agreed to pay each affected customer $16.

From an individual perspective this isn’t a lot. However, for those who are eligible for the settlement I have a proposal: submit your claim form and make it part of a larger donation to your local food bank or homeless shelter.

That’s what I’m going to do.

Holiday Gift Opening Tip

This is a blister pack:

blister pack

We take gift-giving safety seriously here at the CACE Technologies World Domination Headquarters.

These are aviation shears:

aviation shears

This is what you can do to a blister pack in just a few seconds using aviation shears:


The shears were designed to cut sheet metal. They go through annoying packaging with precision and ease. You know those scissors that can cut through a penny? Aviation shears can cut through a penny and through those scissors.

They’re the best thing I’ve found so far for the job.

Troubleshooting A Slow Web Site

A couple of weeks ago we had a strange problem in the CACE Technologies World Domination Secret Lair. Loris was having trouble loading the Wireshark blog. It was working fine on my machine so I checked some of the other machines in the office. I found the same problem on one of the development machines. Loading the page in Firebug showed that the object requests were stalling out every 20 seconds or so:
I fired up Wireshark and captured the browser attempting to connect to the blog:
ipv6 failure
The problem was immediately obvious. The browser attempted to connect to the blog’s IPv6 address (2607:f0d0:2001:e:1::1), timed out, and connected to the blog’s IPv4 address (

As it turns out Loris and I ran some IPv6 tests a long time ago and we added unique local addresses to our machines (mine was fd00:cace::4) . Since each machine had an IPv6 address the TCP stack assumed that there was general IPv6 connectivity. However, our ISP is steadfastly ignoring IPv6 so end-to-end connectivity wasn’t there. After timing out the connection fell back to IPv4 and proceeded normally.

This sort of thing will likely crop up more and more often as we transition to IPv6. If either IPv4 or IPv6 connectivity fails, your applications will still have connectivity so the failure may not be immediately obvious. In this case Firefox stalled out but still managed to connect. If it used a connect-by-name socket API the failure wouldn’t have been evident at all.