[Cerowrt-devel] WNDR3700v4 is out...

[Dave Taht]

As is probably not widely known, I already fairly regularly do a build
for two of ubiquity's products which use the same chipset as cerowrt.

https://www.bufferbloat.net/projects/cerowrt/wiki/Yurtlab

This is a highly specialized build to make it easy to deploy new
versions to the boxes in place there and not general purpose enough
(IMHO) for this effort (for example it relies on babel pretty heavily,
has my ssh key in it, and hard coded DNS servers, and I keep hoping to
finish up dnsmasq-ahcp so I can just wave them in the air and have
them come online).

I just got 5/5 more of the nano station M5s and Picostation 2HPs,
mostly out of fear that these too would get obsoleted on me, and
partially because this completes the expansion of the testbed boxes
I'd planned at the yurtlab in august to a full fault-tolerant mesh, in
addition to the test servers on multiple edges of that network,
already sitting there, undeployed, in boxes.

I have no idea when I'll get around to deploying the new radios,
(anybody in california want to climb some trees with me in los
gatos?). it's my hope that the last ipv6-related bits will stabilize
in openwrt very soon, and I'm willing to make that my target for the
next "stable" cerowrt - what I think I'll call "cerowrt modena"...
(votes for a name gladly accepted) - and roll it out that way, testing
cerowrt sugarland in parallel for regressions.

I like the 2HPs a LOT - they have wonderful range. And the nano
stations M5s are spectacular when aimed right. The CPUs however on
both products are kind of weak, and can barely drive the radios at
rated speed. Also the ethernet interfaces are limited to 100Mbit.

I wouldn't mind adding explicit support for ubiquity's in-home product
to cerowrt.

I would like it even more if some vendor realized the value of the
work we were doing with debloating ethernet AND wireless,
(eventually), and helped with it...

On Sun, Dec 23, 2012 at 10:22 AM, Outback Dingo <outbackdingo at gmail.com> wrote:
> Ubiquiti has quite a list of products that could be good candidates for
> debloating, as they all already run OpenWRT
> and are based on the atheros soc and put out some decent watts
>
>
> On Sun, Dec 23, 2012 at 10:16 AM, David Lang <david at lang.hm> wrote:
>>
>> On Sun, 23 Dec 2012, Dave Taht wrote:
>>
>>> On Sun, Dec 23, 2012 at 2:27 AM, David Lang <david at lang.hm> wrote:
>>>>
>>>> On Thu, 20 Dec 2012, Richard Brown wrote:
>>>>
>>>>> The wndr3700v4 is out, and appears to be a good hardware upgrade from
>>>>> the 3800 series, but it's not supported by openwrt yet.
>>>>>
>>>>> I took a look at their GPL source distribution. And yea! it's openwrt.
>>>>> And boo! it's ancient openwrt, for example dnsmasq is 2.39 (current is
>>>>> 2.64), and their kernel is 2.6.31.
>>>>>
>>>>> I think the cpu and ethernet chips tho look a lot better: Atheros
>>>>> AR9344+ AR9580(5GHz)+AR9344(2.4GHz). It's my hope these do ipv6
>>>>> better.
>>>>>
>>>>> I found a WNDR3700v4 at the local Staples for $99.99. I wasn't brave
>>>>> enough to buy it. Here's an image of the box so you can recognize it...
>>>>
>>>>
>>>>
>>>> I've purchased one, but I don't have the openwrt experiance to bootstrap
>>>> this. I have built my own openwrt images for the 3700v2 and 3800 and
>>>> have
>>>> been using Linux since the 0.99 kernel days, so I am very comfortable
>>>> mucking with kernel compile options.
>>>>
>>>> If someone is willing to coach me through the process, I'd be happy to
>>>> do
>>>> the experimentation.
>>>
>>>
>>> I've ordered one too, but I would argue that a concerted effort would
>>> need to be made on the part of some core #openwrt devs to get it
>>> anywhere. The cpu is a mips 74k. It's a dual issue core with a very,
>>> very long pipeline, so although it boasts twice the instructions per
>>> clock than the 24k, and in simple benchmarks like drystone, rocks,
>>> that deep pipeline isn't helpful for tons of code. (IMHO). It doesn't
>>> look like the cache architecture is improved much, either.
>>>
>>> It's not clear what the ethernet driver is, there appear to be legal
>>> issues on the equivalent broadcom ethernet device, and so on, and so
>>> forth.
>>>
>>> You will need, at least, a 3.3v serial port and adaptor, and jtag
>>> might be needed. If you want to learn about just how painful it is to
>>> bring up a new board, this is your chance!
>>
>>
>> I've got the serial adapter
>>
>>
>>> It makes sense to start a thread on openwrt-devel about doing the port.
>>>
>>> https://forum.openwrt.org/viewtopic.php?id=41092
>>
>>
>> There's already a thread (in english), I've added to it and sent a message
>> to the -devel list
>>
>> https://forum.openwrt.org/viewtopic.php?pid=186781
>>
>>
>>> And/or find some other still supported hardware still being shipped by
>>> some other manufacturer.
>>
>>
>> any suggestions?
>>
>>
>>> Frankly, if we truly have to jump platforms, I'd rather go arm.
>>
>>
>> part of me agrees with you, but then a nagging voice bugs me that if we
>> are programming to the point that such things matter, we're working too low
>> in the stack. It's not enough to de-bloat ARM based systems, we need to do
>> all of them, includeing ones that are even worse than MIPS :-)
>>
>> Also, I'm suspecting that the v4 hardware is pretty close to the v2 and
>> 3800 hardware from a OS point of view, close enough that it may just be a
>> matter of firmware headers being changed to get the images loaded. If I'm
>> right, then it may be that adding the 3700v4 to cerowrt isn't going to be
>> much worse than adding the 3800 was (once openwrt gets support for the v4)
>>
>>
>> David Lang
>>
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html