[Cerowrt-devel] preliminary codel and fq_codel support for cerowrt

[Cerowrt-devel] preliminary codel and fq_codel support for cerowrt

[Dave Taht]

A test release of CeroWrt is now available that has support for Kathie
Nichols' and Van Jacobson's new AQM, Codel , and Eric Dumazet's new
fair queuing implementation on top of that, fq_codel.

fq_codel is enabled on all interfaces by default. It is vastly simpler
than what we were using before (sfqred) and draws upon and improves on
the same body of ideas (head drop, fq, timestamping) but is now tied
to Kathie and Van's blinding insights as to a good drop strategy, and
Eric's successor-to-sfqred ideas as towards head of queue behavior,
modern amounts of flows, and cache line optimizations.

There is a simple_qos.sh script that can be set to your uplink and
downlink speeds, but no uci interface for it as yet, nor gui. (help on
finishing aqm-scripts and the luci interface gladly accepted)

To see all the chocolately goodness of what fq_codel can do to wired
and wireless latency, it would be good for more to play with it.

Benchmarks have been very good thus far, and more benchmarks and
analysis are highly desired.

Caveat:

This release suffers from an unrelated bug ( #379 ) and should NOT be
installed as your main router. I would love to beat this bug because
it's the only prio 1 remaining but thus far, no luck. Under lighter
loads CeroWrt appears to work just fine, but that's for me. YMMV.

Get it here: http://huchra.bufferbloat.net/~cero1/3.3/3.3.6-2/


-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net

Re: [Cerowrt-devel] preliminary codel and fq_codel support for cerowrt

[Outback Dingo]

On Mon, May 14, 2012 at 4:59 PM, Dave Taht <dave.taht@gmail.com> wrote:
> A test release of CeroWrt is now available that has support for Kathie
> Nichols' and Van Jacobson's new AQM, Codel , and Eric Dumazet's new
> fair queuing implementation on top of that, fq_codel.
>
> fq_codel is enabled on all interfaces by default. It is vastly simpler
> than what we were using before (sfqred) and draws upon and improves on
> the same body of ideas (head drop, fq, timestamping) but is now tied
> to Kathie and Van's blinding insights as to a good drop strategy, and
> Eric's successor-to-sfqred ideas as towards head of queue behavior,
> modern amounts of flows, and cache line optimizations.
>
> There is a simple_qos.sh script that can be set to your uplink and
> downlink speeds, but no uci interface for it as yet, nor gui. (help on
> finishing aqm-scripts and the luci interface gladly accepted)
>
> To see all the chocolately goodness of what fq_codel can do to wired
> and wireless latency, it would be good for more to play with it.
>
> Benchmarks have been very good thus far, and more benchmarks and
> analysis are highly desired.
>
> Caveat:
>
> This release suffers from an unrelated bug ( #379 ) and should NOT be
> installed as your main router. I would love to beat this bug because
> it's the only prio 1 remaining but thus far, no luck. Under lighter
> loads CeroWrt appears to work just fine, but that's for me. YMMV.
>
> Get it here: http://huchra.bufferbloat.net/~cero1/3.3/3.3.6-2/
>

Odd why is there no openwrt-ar71xx-generic-wndr3700-squashfs-factory.img ??
has it been combined with another ???

>
> --
> Dave Täht
> SKYPE: davetaht
> US Tel: 1-239-829-5608
> http://www.bufferbloat.net
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] preliminary codel and fq_codel support for cerowrt

[Sebastian Moeller]

Hi Dave,

so I upgraded my router to the most recent version, and hey I am really impressed, thanks a lot for all the work. 
(I never really stress the local network, and the internet is 5/30 so I consider to be on the safe side of #379 and decided to ignore your recommendation about the suitability for main routers). 
	I tried the simple_qos.sh script and for my testing it is quite nice indeed. The whole network stays quite responsive even during abuse. The whole expeience was quite pleasant (using ssh over a ssl based VPN to remote control an X11 session while stressing in and out direction); counter to my subjective experience though netalyzr was detecting 3000 odd milliseconds of buffering upstream (downstream was fine). Once I find more time I will have a go at reproducing that. (Now I have to figure out whether I need to restart simple_qos.sh anytime I down or up an interface; any pointer?) BTW, how do you envision this to be started under the AQM tab; shall this start simple_qos or rather debloat?
Small observation, port 81 on the router seems open to the internet, easily fixed, but maybe something you might want know :)


Anyway, thanks again
	Sebastian


On May 14, 2012, at 1:59 PM, Dave Taht wrote:

> A test release of CeroWrt is now available that has support for Kathie
> Nichols' and Van Jacobson's new AQM, Codel , and Eric Dumazet's new
> fair queuing implementation on top of that, fq_codel.
> 
> fq_codel is enabled on all interfaces by default. It is vastly simpler
> than what we were using before (sfqred) and draws upon and improves on
> the same body of ideas (head drop, fq, timestamping) but is now tied
> to Kathie and Van's blinding insights as to a good drop strategy, and
> Eric's successor-to-sfqred ideas as towards head of queue behavior,
> modern amounts of flows, and cache line optimizations.
> 
> There is a simple_qos.sh script that can be set to your uplink and
> downlink speeds, but no uci interface for it as yet, nor gui. (help on
> finishing aqm-scripts and the luci interface gladly accepted)
> 
> To see all the chocolately goodness of what fq_codel can do to wired
> and wireless latency, it would be good for more to play with it.
> 
> Benchmarks have been very good thus far, and more benchmarks and
> analysis are highly desired.
> 
> Caveat:
> 
> This release suffers from an unrelated bug ( #379 ) and should NOT be
> installed as your main router. I would love to beat this bug because
> it's the only prio 1 remaining but thus far, no luck. Under lighter
> loads CeroWrt appears to work just fine, but that's for me. YMMV.
> 
> Get it here: http://huchra.bufferbloat.net/~cero1/3.3/3.3.6-2/
> 
> 
> -- 
> Dave Täht
> SKYPE: davetaht
> US Tel: 1-239-829-5608
> http://www.bufferbloat.net
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] preliminary codel and fq_codel support for cerowrt

[dave taht]

On 05/16/2012 09:34 AM, Sebastian Moeller wrote:
> Hi Dave,
>
> so I upgraded my router to the most recent version, and hey I am really impressed, thanks a lot for all the work.
> (I never really stress the local network, and the internet is 5/30 so I consider to be on the safe side of #379 and decided to ignore your recommendation about the suitability for main routers).
> 	I tried the simple_qos.sh script and for my testing it is quite nice indeed. The whole network stays quite responsive even during abuse. The whole expeience was quite pleasant (using ssh over a ssl based VPN to remote control an X11 session while stressing in and out direction); counter to my subjective experience though netalyzr was detecting 3000 odd milliseconds of buffering upstream (downstream was fine). Once I find more time I will have a go at reproducing that. (Now I have to figure out whether I need to restart simple_qos.sh anytime I down or up an interface; any pointer?) BTW, how do you envision this to be started under the AQM tab; shall this start simple_qos or rather debloat?

No, I had something more wonderful in mind.

Felix Fietkau has added fq_codel to the openwrt 3.3 kernel and to the 
existing qos-scripts as of openwrt revision 31761.

Builds for 37 architectures and ~150 platforms are popping out as I write.

See

http://buildbot.openwrt.org:8010/one_line_per_build

For details.

I will be obsoleting the CeroWrt aqm and aqm-scripts and simple_qos as 
soon as the new qos-scripts handles ipv6 properly, and maybe get a 
chance to add a trick or two to more to it.

Erics latest patch to fq_codel has not yet landed in openwrt.


> Small observation, port 81 on the router seems open to the internet, easily fixed, but maybe something you might want know :)
Patches gladly accepted. Frankly I'd hoped to have CeroWall done by now, 
but, well, the ball's on the 20 yard line, and I need to bench myself 
for a while.

Hopefully someone else can take it in for the score.
>
> Anyway, thanks again
> 	Sebastian
>
>
> On May 14, 2012, at 1:59 PM, Dave Taht wrote:
>
>> A test release of CeroWrt is now available that has support for Kathie
>> Nichols' and Van Jacobson's new AQM, Codel , and Eric Dumazet's new
>> fair queuing implementation on top of that, fq_codel.
>>
>> fq_codel is enabled on all interfaces by default. It is vastly simpler
>> than what we were using before (sfqred) and draws upon and improves on
>> the same body of ideas (head drop, fq, timestamping) but is now tied
>> to Kathie and Van's blinding insights as to a good drop strategy, and
>> Eric's successor-to-sfqred ideas as towards head of queue behavior,
>> modern amounts of flows, and cache line optimizations.
>>
>> There is a simple_qos.sh script that can be set to your uplink and
>> downlink speeds, but no uci interface for it as yet, nor gui. (help on
>> finishing aqm-scripts and the luci interface gladly accepted)
>>
>> To see all the chocolately goodness of what fq_codel can do to wired
>> and wireless latency, it would be good for more to play with it.
>>
>> Benchmarks have been very good thus far, and more benchmarks and
>> analysis are highly desired.
>>
>> Caveat:
>>
>> This release suffers from an unrelated bug ( #379 ) and should NOT be
>> installed as your main router. I would love to beat this bug because
>> it's the only prio 1 remaining but thus far, no luck. Under lighter
>> loads CeroWrt appears to work just fine, but that's for me. YMMV.
>>
>> Get it here: http://huchra.bufferbloat.net/~cero1/3.3/3.3.6-2/
>>
>>
>> -- 
>> Dave Täht
>> SKYPE: davetaht
>> US Tel: 1-239-829-5608
>> http://www.bufferbloat.net
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] preliminary codel and fq_codel support for cerowrt

[Outback Dingo]

On Wed, May 16, 2012 at 1:09 PM, dave taht <dave.taht@gmail.com> wrote:
> On 05/16/2012 09:34 AM, Sebastian Moeller wrote:
>>
>> Hi Dave,
>>
>> so I upgraded my router to the most recent version, and hey I am really
>> impressed, thanks a lot for all the work.
>> (I never really stress the local network, and the internet is 5/30 so I
>> consider to be on the safe side of #379 and decided to ignore your
>> recommendation about the suitability for main routers).
>>        I tried the simple_qos.sh script and for my testing it is quite
>> nice indeed. The whole network stays quite responsive even during abuse. The
>> whole expeience was quite pleasant (using ssh over a ssl based VPN to remote
>> control an X11 session while stressing in and out direction); counter to my
>> subjective experience though netalyzr was detecting 3000 odd milliseconds of
>> buffering upstream (downstream was fine). Once I find more time I will have
>> a go at reproducing that. (Now I have to figure out whether I need to
>> restart simple_qos.sh anytime I down or up an interface; any pointer?) BTW,
>> how do you envision this to be started under the AQM tab; shall this start
>> simple_qos or rather debloat?
>
>
> No, I had something more wonderful in mind.
>
> Felix Fietkau has added fq_codel to the openwrt 3.3 kernel and to the
> existing qos-scripts as of openwrt revision 31761.
>
> Builds for 37 architectures and ~150 platforms are popping out as I write.
>
> See
>
> http://buildbot.openwrt.org:8010/one_line_per_build
>
> For details.
>
> I will be obsoleting the CeroWrt aqm and aqm-scripts and simple_qos as soon
> as the new qos-scripts handles ipv6 properly, and maybe get a chance to add
> a trick or two to more to it.
>
> Erics latest patch to fq_codel has not yet landed in openwrt.
>
>
>
>> Small observation, port 81 on the router seems open to the internet,
>> easily fixed, but maybe something you might want know :)
>
> Patches gladly accepted. Frankly I'd hoped to have CeroWall done by now,
> but, well, the ball's on the 20 yard line, and I need to bench myself for a
> while.
>
> Hopefully someone else can take it in for the score.

CeroWall ?? OpenWRT iptables / qos scripts ???

>
>>
>> Anyway, thanks again
>>        Sebastian
>>
>>
>> On May 14, 2012, at 1:59 PM, Dave Taht wrote:
>>
>>> A test release of CeroWrt is now available that has support for Kathie
>>> Nichols' and Van Jacobson's new AQM, Codel , and Eric Dumazet's new
>>> fair queuing implementation on top of that, fq_codel.
>>>
>>> fq_codel is enabled on all interfaces by default. It is vastly simpler
>>> than what we were using before (sfqred) and draws upon and improves on
>>> the same body of ideas (head drop, fq, timestamping) but is now tied
>>> to Kathie and Van's blinding insights as to a good drop strategy, and
>>> Eric's successor-to-sfqred ideas as towards head of queue behavior,
>>> modern amounts of flows, and cache line optimizations.
>>>
>>> There is a simple_qos.sh script that can be set to your uplink and
>>> downlink speeds, but no uci interface for it as yet, nor gui. (help on
>>> finishing aqm-scripts and the luci interface gladly accepted)
>>>
>>> To see all the chocolately goodness of what fq_codel can do to wired
>>> and wireless latency, it would be good for more to play with it.
>>>
>>> Benchmarks have been very good thus far, and more benchmarks and
>>> analysis are highly desired.
>>>
>>> Caveat:
>>>
>>> This release suffers from an unrelated bug ( #379 ) and should NOT be
>>> installed as your main router. I would love to beat this bug because
>>> it's the only prio 1 remaining but thus far, no luck. Under lighter
>>> loads CeroWrt appears to work just fine, but that's for me. YMMV.
>>>
>>> Get it here: http://huchra.bufferbloat.net/~cero1/3.3/3.3.6-2/
>>>
>>>
>>> --
>>> Dave Täht
>>> SKYPE: davetaht
>>> US Tel: 1-239-829-5608
>>> http://www.bufferbloat.net
>>> _______________________________________________
>>> Cerowrt-devel mailing list
>>> Cerowrt-devel@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] preliminary codel and fq_codel support for cerowrt

[Dave Taht]

The problem with most home router firewalls today is that they have a strict
"us" vs "them" concept in them, and are closely tied to what can be
NATed, or not, which limits our internet to tcp and udp.

Recently the concept of 'guest' has been added to many devices,
which doesn't work particularly well.

A problem with "us vs them" and extending this sort of thinking
to ipv6, is that interesting new protocols such as
sctp, hip, rdp, dccp, rsvp esp, gre, ah, skip, ospf, vrrp, isis, manet, shim6,
wesp, and rohc...

are all blocked by default in ipv6, too.

It doesn't need to be this way.

I have hated living in a world of purely tcp on port 80 and 443.

Seeing udp begin to fail in multiple respects - such as dns,dhcp, voice, etc
really bothers me.

So cerowall attempted (I've never finished it) to use pattern matching
in iptables, and device renaming, to make it possible to have a nearly
default free zone (DFZ) for guests, and use a bare minimum of rules,
to pass through...

and the core idea was also be able to pass ALL protocols everywhere,
under ipv6.

The current openwrt firewall solution scales O(n) where n = the number
of interfaces
the cerowall idea scales O(n) where n = the number of different zones.

Firewalling is responsible for a minimum of 11% of the current runtime,
with the current firewall rules, with 6 interfaces in play.

CeroWall did a lot better, while opening up new vistas to play in.

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net

Re: [Cerowrt-devel] preliminary codel and fq_codel support for cerowrt

[Sebastian Moeller]

Hi Dave,

all of this sounds interesting, and a bit scary...

While I have a hunch that I am trying to flog a quite deceased horse here,I think that closed by default is the safest way to set up a secure router. If it is easy to open it up for incoming services easily than everything is golden. As long as I control the router control and restriction actually become great concepts :) (even DPI is decidedly non-scary if I perform it my own network packages versus someone else doing it on my packages :) )


On May 16, 2012, at 10:52 AM, Dave Taht wrote:

> The problem with most home router firewalls today is that they have a strict
> "us" vs "them" concept in them, and are closely tied to what can be
> NATed, or not, which limits our internet to tcp and udp.
> 
> Recently the concept of 'guest' has been added to many devices,
> which doesn't work particularly well.
> 
> A problem with "us vs them" and extending this sort of thinking
> to ipv6, is that interesting new protocols such as
> sctp, hip, rdp, dccp, rsvp esp, gre, ah, skip, ospf, vrrp, isis, manet, shim6,
> wesp, and rohc…

	Just to show my ignorance, but all are on top of IP packages, so why can these not be integrated into NAT default closed firewalls?

> 
> are all blocked by default in ipv6, too.

	Which I think is the right thing to do, as long as opening a service is a few mouse clicks away. 

	There is too much internet enabled gear around (say like my ipod) which is not really be trustworthy nor can be audited easily to go to open by default. Having the router be restrictive does not eradicate consequences from insecure devices but mitigates it some. It should be easier to keep a single router secure than a small armada of end user devices behind this thing (and so much easier to give TLC to one firewall instead of several all using slightly different configuration methods). Hey, I just realize I am a pessimist and a spassbremse...


> 
> It doesn't need to be this way.
> 
> I have hated living in a world of purely tcp on port 80 and 443.
> 
> Seeing udp begin to fail in multiple respects - such as dns,dhcp, voice, etc
> really bothers me.

	How is that related to restrictive handling of incoming data? I ask because I really do not know. I always assumed that blocking all incoming unless either related to an already initiated connection or explicitly allowed made sense and should allow most things to just work. (I am totally prepared to open the firewall for services I am interested in).

> 
> So cerowall attempted (I've never finished it) to use pattern matching
> in iptables, and device renaming, to make it possible to have a nearly
> default free zone (DFZ) for guests, and use a bare minimum of rules,
> to pass through…

	That sounds great (if the secure zone stays restrictive by default, having an easy way to go into the deep end sounds great). 

> 
> and the core idea was also be able to pass ALL protocols everywhere,
> under ipv6.

	That I can not understand, as IPv6 becomes more pervasive so will exploits and security issues. I see the whole issue a bit as the dichotomy between control and laissez faire; in theory cooperation easily beats strict control, but in reality cooperation only works well in special cases. And from that perspective I see allow all incoming IPv6 as a gamble that will fail once the population of users grows beyond the early-adopter tech crowd…

> 
> The current openwrt firewall solution scales O(n) where n = the number
> of interfaces
> the cerowall idea scales O(n) where n = the number of different zones.
> 
> Firewalling is responsible for a minimum of 11% of the current runtime,
> with the current firewall rules, with 6 interfaces in play.

	But is that not a good part of what a network edge router should do to "earn" its living :) 

> 
> CeroWall did a lot better, while opening up new vistas to play in.

	It seems I am a chicken incapable of appreciating these vistas without worrying about what else could happen :)

Anyway, I am truly interested in learning the gains of default open routing and what risk mitigation approaches exist for the t scenario.


Best
	Sebastian

> 
> -- 
> Dave Täht
> SKYPE: davetaht
> US Tel: 1-239-829-5608
> http://www.bufferbloat.net

Re: [Cerowrt-devel] preliminary codel and fq_codel support for cerowrt

[dpreed]

[-- Attachment #1: Type: text/plain, Size: 5159 bytes --]


So here's an interesting question .. can cerowrt's approach relate to FON?   FON is not so successful in US, but in Europe, it is doing well.   FON should also adopt codel and fq_codel.
 
It may not make sense quickly, but the 802.11p stuff that is going on in the world might be a big opportunity to enage with cerowrt capabilities....
 
-----Original Message-----
From: "Sebastian Moeller" <moeller0@gmx.de>
Sent: Wednesday, May 16, 2012 3:51pm
To: "Dave Taht" <dave.taht@gmail.com>
Cc: "<cerowrt-devel@lists.bufferbloat.net>" <cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] preliminary codel and fq_codel support for cerowrt



Hi Dave,

all of this sounds interesting, and a bit scary...

While I have a hunch that I am trying to flog a quite deceased horse here,I think that closed by default is the safest way to set up a secure router. If it is easy to open it up for incoming services easily than everything is golden. As long as I control the router control and restriction actually become great concepts :) (even DPI is decidedly non-scary if I perform it my own network packages versus someone else doing it on my packages :) )


On May 16, 2012, at 10:52 AM, Dave Taht wrote:

> The problem with most home router firewalls today is that they have a strict
> "us" vs "them" concept in them, and are closely tied to what can be
> NATed, or not, which limits our internet to tcp and udp.
> 
> Recently the concept of 'guest' has been added to many devices,
> which doesn't work particularly well.
> 
> A problem with "us vs them" and extending this sort of thinking
> to ipv6, is that interesting new protocols such as
> sctp, hip, rdp, dccp, rsvp esp, gre, ah, skip, ospf, vrrp, isis, manet, shim6,
> wesp, and rohc…

 Just to show my ignorance, but all are on top of IP packages, so why can these not be integrated into NAT default closed firewalls?

> 
> are all blocked by default in ipv6, too.

 Which I think is the right thing to do, as long as opening a service is a few mouse clicks away. 

 There is too much internet enabled gear around (say like my ipod) which is not really be trustworthy nor can be audited easily to go to open by default. Having the router be restrictive does not eradicate consequences from insecure devices but mitigates it some. It should be easier to keep a single router secure than a small armada of end user devices behind this thing (and so much easier to give TLC to one firewall instead of several all using slightly different configuration methods). Hey, I just realize I am a pessimist and a spassbremse...


> 
> It doesn't need to be this way.
> 
> I have hated living in a world of purely tcp on port 80 and 443.
> 
> Seeing udp begin to fail in multiple respects - such as dns,dhcp, voice, etc
> really bothers me.

 How is that related to restrictive handling of incoming data? I ask because I really do not know. I always assumed that blocking all incoming unless either related to an already initiated connection or explicitly allowed made sense and should allow most things to just work. (I am totally prepared to open the firewall for services I am interested in).

> 
> So cerowall attempted (I've never finished it) to use pattern matching
> in iptables, and device renaming, to make it possible to have a nearly
> default free zone (DFZ) for guests, and use a bare minimum of rules,
> to pass through…

 That sounds great (if the secure zone stays restrictive by default, having an easy way to go into the deep end sounds great). 

> 
> and the core idea was also be able to pass ALL protocols everywhere,
> under ipv6.

 That I can not understand, as IPv6 becomes more pervasive so will exploits and security issues. I see the whole issue a bit as the dichotomy between control and laissez faire; in theory cooperation easily beats strict control, but in reality cooperation only works well in special cases. And from that perspective I see allow all incoming IPv6 as a gamble that will fail once the population of users grows beyond the early-adopter tech crowd…

> 
> The current openwrt firewall solution scales O(n) where n = the number
> of interfaces
> the cerowall idea scales O(n) where n = the number of different zones.
> 
> Firewalling is responsible for a minimum of 11% of the current runtime,
> with the current firewall rules, with 6 interfaces in play.

 But is that not a good part of what a network edge router should do to "earn" its living :) 

> 
> CeroWall did a lot better, while opening up new vistas to play in.

 It seems I am a chicken incapable of appreciating these vistas without worrying about what else could happen :)

Anyway, I am truly interested in learning the gains of default open routing and what risk mitigation approaches exist for the t scenario.


Best
 Sebastian

> 
> -- 
> Dave Täht
> SKYPE: davetaht
> US Tel: 1-239-829-5608
> http://www.bufferbloat.net

_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[-- Attachment #2: Type: text/html, Size: 5996 bytes --]

Re: [Cerowrt-devel] preliminary codel and fq_codel support for cerowrt

[Richard Brown]

[-- Attachment #1: Type: text/plain, Size: 728 bytes --]


On May 15, 2012, at 3:00 PM, Outback Dingo wrote:

Caveat:

This release suffers from an unrelated bug ( #379 ) and should NOT be
installed as your main router. I would love to beat this bug because
it's the only prio 1 remaining but thus far, no luck. Under lighter
loads CeroWrt appears to work just fine, but that's for me. YMMV.

Get it here: http://huchra.bufferbloat.net/~cero1/3.3/3.3.6-2/


Odd why is there no openwrt-ar71xx-generic-wndr3700-squashfs-factory.img ??
has it been combined with another ???

CeroWrt has no builds for the either the WNDR3700 v1 or v3. The WNDR3700v2 and WNDR3800 both work fine (and the WNDR3800 has more flash memory, so it's a bit more futureproof...)

Best,

Rich

[-- Attachment #2: Type: text/html, Size: 2197 bytes --]