Comcast's IPv6 CPE selection

Ted Mittelstaedt tedm at ipinc.net
Mon Apr 26 23:16:45 CEST 2010



On 4/26/2010 12:27 PM, Dave Taht wrote:
> On 04/26/2010 12:58 PM, Doug Barton wrote:
>> On 04/26/10 06:45, Dave Taht wrote:
>>> On 04/24/2010 11:09 PM, Doug Barton wrote:
>>>> And all of this also applies only to the command-line interface
>>>>> to dd-wrt. The GUI interface would have to be modified to support
>>>>> all of the IPv6 utilities (like traceroute6) before you could
>>>>> point to DD-WRT and call it "grandparent ready" and that is not easy
>>>>> as it's written in an obfuscated manner (to prevent copying, the
>>>>> GUI is NOT under the GPL like the rest of DD-WRT is) However, this
>>>>> isn't any different than OpenWRT, which while it has a good
>>>>> command-line implementation of IPv6, none of the GUIs that
>>>>> are out there for OpenWRT support it. (although, those ARE
>>>>> easily modified)
>>>>>
>>>> Agreed on both points. I used to use openwrt, and it has some things to
>>>> recommend it. However (AFAICT) the development has stalled, and they
>>>> are
>>>> definitely NOT focusing on newer hardware which means my latest CPE has
>>>> no openwrt version available for it.
>>>>
>>> I don't quite "get" where you say openwrt has stalled.
>> Sorry, I wasn't clear, I was referring to development for new hardware.
>> I can't run it on my newest AP, so it's not relevant to me. :)
>>
>>
>> Doug
>
> The equipment I mentioned is all "new hardware", shipped or developed in
> the past year.
>

I think the problem is that the OpenWRT people don't want to use the
manufacturer-supplied "binary blob" drivers for the radios, and so in
the current OpenWRT they have been dragging their feet on including those.

For example with the WRT160N  (I think that's the one that Doug has)
they dragged and dragged their feet waiting for the open source b43
driver to be released by Broadcom - then at the last minute they must
have written Broadcom directly and got permission to redistribute the
"binary blob" driver for the Linux 2.6 kernel for the chip in the
WRT 160N version 1.  (that blob driver is in the Backfire release for
the 150N, but you have to really dig to find a last-minute note about
this here:

http://sites.google.com/site/snipes4202/wrt160n-notes )

In the meanwhile the DD-WRT project seems to have always had the 
philosophy that if the manufacturer has released a "binary blob" driver
for a radio, they would just write them and get permission for
redistribution.  As a result that has allowed them to not only
support the 160N v 1/1.1 but also the 160N v3 - a platform that the
OpenWRT people haven't even started building for.

I can understand the OpenWRT's team's philosophy as that's straight
out of the RMS "never compromise your principles, even if it means
the user just isn't going to get software at all for something"
handbook, and they must be ardent disciples.  The DD-WRT approach
is definitely more pragmatic.

But the problem is that both OpenWRT and DD-WRT are the fleas on the
dog's back and when the dog wants to run the fleas just have to
hang on and recognize they aren't going to be able to force the dog
to change.

Ted




More information about the ipv6-ops mailing list