[Cerowrt-devel] Just FYI: WNDR3700 (v2???) refurbs available on Amazon for USD49.99

[Cerowrt-devel] Just FYI: WNDR3700 (v2???) refurbs available on Amazon for USD49.99

[Frank Horowitz]

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

Hi All,

Amazon is listing WNDR3700 refurbs for sale on 1 March for USD49.99: < http://www.amazon.com/gp/product/B0085WVQDK/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1> Based on the stated 680 MHz processor speed, I am inferring that these are v2. refurbs. (Only v1. and v2 had those speeds.) 

I’ve ordered one and will report back what version it actually is when it arrives next week.

(Just in case you wanted a spare test router…)

Cheers,
	Frank Horowitz


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 841 bytes --]

Re: [Cerowrt-devel] Just FYI: WNDR3700 (v2???) refurbs available on Amazon for USD49.99

[Dave Taht]

Good to know. I have to admit that my own development has mostly moved
to open chaos calmer, which supports a metric ton of commonly
available platforms, include (now) all the 3700 series including the
v4, and also (finally) the 4300 series, and all of these are available
new for under 90 bucks, and there are multiple other non-netgear
brands in the same price range also supported by openwrt. The
sqm-scripts and related bufferbloat tools have more polish now in
chaos calmer than in the stable version of cerowrt.

The nightly builds of chaos calmer for these platforms and slightly
more advanced ones like the archer c7 v2 are pretty darn good, and I
recommend at present that people follow those.

http://downloads.openwrt.org/snapshots/trunk/

zillions of of possible platforms there outside of netgear and the
ath9k based stuff we currently use.

But: if anyone cares and wants to try cake or some more advanced
fq_codel models, they are welcome to try any product from my current
build: http://snapon.lab.bufferbloat.net/~cero3/ubnt/ar71xx/ - but
that is just openwrt + those new queuing models + some wifi fixes
ongoing and I have no interest or time for long term support at the
moment and ghu help you if you try to use it day-to-day.

from that last build, tested by me thus far are the ubnt nanostation
and wndr3700v2 and archer (archer has some problems)

Cake needs some love, although I certainly like being able to just do a:

tc qdisc add dev eth1 root cake bandwidth 50mbit besteffort

and then be able to do:

tc qdisc change dev eth0 root cake bandwidth 10mbit

rather than all the scripting we had to do to make htb work in sqm
scripts - but it does not do atm right, nor is anyone happy with the
diffserv functionality.

I DO love cake's output

http://pastebin.com/bX5njmkr

The above patchset also has the very nice minstrel-blues coupled rate
+ power controller and andrew mcgregor's latest minstrel patches to
optimize for minimum variance.

But really core to future progress is getting a working implementation
of per station wifi queues and that is going to take a lot more work.
And not enough funding has landed to actually do another cerowrt-scale
effort, as yet.





I am actually using the 4300 as my day-in, day-out router now, and
will probably switch to the archer c7 v2 once some issues with the
ethernet and ath10k are resolved. (we are only getting 100mbit out of
it for some reason)

On the higher end, I have a linksys product, a buffalo product, and a
d-link product sitting in a box awaiting time for me to flash....

I would certainly like to find a 30 dollar product worth working on.

We will hopefully get around to a cerowrt refresh fairly soon - as
soon as some more test code lands - and do it on several platforms.
Until then, try chaos calmer - and for all I know we will end up
building more on openwrt directly this time rather than repeating all
the stuff that openwrt won't take upstream that is presently in
cerowrt.

I am not happy with netgear the company and plan to work with several
other vendors on the next go-round.

On Thu, Feb 26, 2015 at 10:15 AM, Frank Horowitz <frank@horow.net> wrote:
> Hi All,
>
> Amazon is listing WNDR3700 refurbs for sale on 1 March for USD49.99: < http://www.amazon.com/gp/product/B0085WVQDK/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1> Based on the stated 680 MHz processor speed, I am inferring that these are v2. refurbs. (Only v1. and v2 had those speeds.)
>
> I’ve ordered one and will report back what version it actually is when it arrives next week.
>
> (Just in case you wanted a spare test router…)
>
> Cheers,
>         Frank Horowitz
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>



-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb

Re: [Cerowrt-devel] Just FYI: WNDR3700 (v2???) refurbs available on Amazon for USD49.99

[David Lang]

On Thu, 26 Feb 2015, Dave Taht wrote:

> We will hopefully get around to a cerowrt refresh fairly soon - as
> soon as some more test code lands - and do it on several platforms.
> Until then, try chaos calmer - and for all I know we will end up
> building more on openwrt directly this time rather than repeating all
> the stuff that openwrt won't take upstream that is presently in
> cerowrt.

you may have posted this and I'm just not remembering, but do you have a list of 
what's in CeroWRT that OpenWRT won't take upstream (and any info on why they 
won't take the items)?

Daivd Lang

Re: [Cerowrt-devel] Just FYI: WNDR3700 (v2???) refurbs available on Amazon for USD49.99

[Dave Taht]

On Fri, Feb 27, 2015 at 6:07 PM, David Lang <david@lang.hm> wrote:
> On Thu, 26 Feb 2015, Dave Taht wrote:
>
>> We will hopefully get around to a cerowrt refresh fairly soon - as
>> soon as some more test code lands - and do it on several platforms.
>> Until then, try chaos calmer - and for all I know we will end up
>> building more on openwrt directly this time rather than repeating all
>> the stuff that openwrt won't take upstream that is presently in
>> cerowrt.
>
>
> you may have posted this and I'm just not remembering, but do you have a
> list of what's in CeroWRT that OpenWRT won't take upstream (and any info on
> why they won't take the items)?
>
> Daivd Lang

* Unbridged interfaces - routing only
* Device Naming by function rather than type
* More open to ipv6 firewall
* Firewall using device pattern matching to avoid O(n) complexities in
firewall rules
* Babels on and preconfigured by default
* Oddball IP address range and /27 subnets
* Polipo Web proxy
* Samba by default
* Faster web server
* Weird port for the configuration web server
* Pre-enabled wifi and wifi mesh interfaces
* Huge amount of alternate qdiscs (like pie, ns2_codel, cake, cake2, etc)

And:

A build that includes all these things by default.

I note there are a couple nice "super-duper" builders of openwrt that
have WAY more features that ever made it into cerowrt. Although I
forget their names, they have their advocates on the openwrt forums.
(and both include sqm)
I have long meant to eval those and maybe hope to convince them to be
the next buildmaster for this project - the day to day grind of doing
a build, testing it, etc, was killing me - and y'all. Much better to
have it get filtered through someone else.....


-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb

Re: [Cerowrt-devel] Just FYI: WNDR3700 (v2???) refurbs available on Amazon for USD49.99

[David Lang]

On Fri, 27 Feb 2015, Dave Taht wrote:

>> you may have posted this and I'm just not remembering, but do you have a
>> list of what's in CeroWRT that OpenWRT won't take upstream (and any info on
>> why they won't take the items)?
>>
>> Daivd Lang

trying to break this down by what's a config policy vs what's code (or 
significant config logic)

> * Unbridged interfaces - routing only

simple config

> * Device Naming by function rather than type

is this code or just a set of config settings?

> * More open to ipv6 firewall

is this just default settings?

> * Firewall using device pattern matching to avoid O(n) complexities in
> firewall rules

This sounds like default settings.

> * Babels on and preconfigured by default

any code here? or is just that it's there by default?

> * Oddball IP address range and /27 subnets

simple config

> * Polipo Web proxy

is this just a different default than upstream?

> * Samba by default

simple config

> * Faster web server

just a different default?

> * Weird port for the configuration web server

simple default

> * Pre-enabled wifi and wifi mesh interfaces

different defaults

> * Huge amount of alternate qdiscs (like pie, ns2_codel, cake, cake2, etc)

any custom code here or is this just different kernel config options being 
turned on?

> And:
>
> A build that includes all these things by default.

The vast majority of these seem to be config selections rather then code. Which 
shows a huge amount of progress from the early days.

There seem to be a couple policy points that are worth trying to fight to get 
upstream

1. Device Naming by function

2. Firewall rules by device pattern matching.

3. pre-enabled wifi and mesh interfaces

4. Samba default (see the recent discussion of common authentication)

5. possibly the web proxy

Things that are probably not worth fighting for

1. a build that includes all of this by default

2. all the alternate qdiscs enabled by default

3. weird port for the config web server

4. oddball IP ranges, /27 subnets, bables, and routing between interfaces by 
default. (This is an approach that is perfect for the "super-duper" builders, 
although this may just end up being a different default config)

any major disagreements or things I missed?


It hit me as I was finishing this that a couple things may combine here.

By doing device naming by function, firewall rules by device (which ends up 
being by function), it may make it far easier to have alternate configs, one for 
bridging, one for routing, and to have options to pre-enable the wifi and mesh 
interfaces.

Thoughts from those who have been more involved with pushing things upstream?

David Lang

[Cerowrt-devel] CeroWrt bits not in OpenWrt (renamed thread)

[Rich Brown]

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

Folks,

Two thoughts:

1) I'm renaming this thread so that it is easily found in the archives (it was "Just FYI: WNDR3700 (v2???) refurbs available on Amazon for USD49.99")

2) I've been maintaining the CeroWrtScripts (https://github.com/richb-hanover/CeroWrtScripts) that has a shell script to set lots of the parameters of CeroWrt into a consistent state. To the extent that the capabilities below are simple config changes, we can use this script as a base for converting "Stock OpenWrt" into something more CeroWrt-like.

Best,

Rich

On Feb 27, 2015, at 11:44 PM, David Lang <david@lang.hm> wrote:

> On Fri, 27 Feb 2015, Dave Taht wrote:
> 
>>> you may have posted this and I'm just not remembering, but do you have a
>>> list of what's in CeroWRT that OpenWRT won't take upstream (and any info on
>>> why they won't take the items)?
>>> 
>>> Daivd Lang
> 
> trying to break this down by what's a config policy vs what's code (or significant config logic)
> 
>> * Unbridged interfaces - routing only
> 
> simple config
> 
>> * Device Naming by function rather than type
> 
> is this code or just a set of config settings?
> 
>> * More open to ipv6 firewall
> 
> is this just default settings?
> 
>> * Firewall using device pattern matching to avoid O(n) complexities in
>> firewall rules
> 
> This sounds like default settings.
> 
>> * Babels on and preconfigured by default
> 
> any code here? or is just that it's there by default?
> 
>> * Oddball IP address range and /27 subnets
> 
> simple config
> 
>> * Polipo Web proxy
> 
> is this just a different default than upstream?
> 
>> * Samba by default
> 
> simple config
> 
>> * Faster web server
> 
> just a different default?
> 
>> * Weird port for the configuration web server
> 
> simple default
> 
>> * Pre-enabled wifi and wifi mesh interfaces
> 
> different defaults
> 
>> * Huge amount of alternate qdiscs (like pie, ns2_codel, cake, cake2, etc)
> 
> any custom code here or is this just different kernel config options being turned on?
> 
>> And:
>> 
>> A build that includes all these things by default.
> 
> The vast majority of these seem to be config selections rather then code. Which shows a huge amount of progress from the early days.
> 
> There seem to be a couple policy points that are worth trying to fight to get upstream
> 
> 1. Device Naming by function
> 
> 2. Firewall rules by device pattern matching.
> 
> 3. pre-enabled wifi and mesh interfaces
> 
> 4. Samba default (see the recent discussion of common authentication)
> 
> 5. possibly the web proxy
> 
> Things that are probably not worth fighting for
> 
> 1. a build that includes all of this by default
> 
> 2. all the alternate qdiscs enabled by default
> 
> 3. weird port for the config web server
> 
> 4. oddball IP ranges, /27 subnets, bables, and routing between interfaces by default. (This is an approach that is perfect for the "super-duper" builders, although this may just end up being a different default config)
> 
> any major disagreements or things I missed?
> 
> 
> It hit me as I was finishing this that a couple things may combine here.
> 
> By doing device naming by function, firewall rules by device (which ends up being by function), it may make it far easier to have alternate configs, one for bridging, one for routing, and to have options to pre-enable the wifi and mesh interfaces.
> 
> Thoughts from those who have been more involved with pushing things upstream?
> 
> David Lang
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

Re: [Cerowrt-devel] CeroWrt bits not in OpenWrt (renamed thread)

[Dave Taht]

You all are right, there are several distinct classes of
cerowrt-specific mods. I certainly would like to leverage their
enormous build system (popping out two builds on all arches every
day), and not have to do regular builds and testing again myself, ever
again (for as long as I live!). Ideally I would just hand off our
latest (dumb or smart) bit of code, developed on an x86 and magically
have someone hand me a huge set of test results on platform of choice,
a day later.

It is really amazing the architecture coverage they have:

http://downloads.openwrt.org/snapshots/trunk/

A) The most troublesome problem is kernel hacks.

A thought would be to ask the openwrt devs to have a cerowrt repo (or,
more likely, a make-wifi-fast repo at this point),
but still several of these patches and future work planned are going
to be pretty invasive (hitting the mac80211 layer hard as well as
ath9k). Hopefully felix and co are going to handle much of that, and
our role here will be more of testing it...

Several other patches are not as invasive - all the different qdiscs
under test, for example, could easily go into their own
package. The problem I have here is I am resistant to putting buggy
code into public repos. For example, the "pfq_codel" version
does not work worth a damn, and I keep it around because one day it
might provide insight into why packet fairness doesn't
work well (or the code may merely be buggy). Similarly, "cake2" is not
fully baked yet. My own preference for new development
is to have a small, intelligent, educated number of testers before
stuff goes upstream.

I am fully aware that it took too long to get the good stuff done here
pushed upstream on a regular basis, so certainly working more upstream
than we did would be good.

B) Then there is stuff that is largely configuration, and I can see
that being a meta package that you
would have to install manually after flashing, with specialized other
packages (like an iproute2-cerowrt) with the needed
other patches - but that is likely to break on many an architecture in
terms of correctly modifying the network, wireless,
firewall and dhcp configurations

... and it presently is invasive in the boot process itself, renaming
the core network interfaces there.

as an example, the wndr4300 uses vlans by default. The archer has 3
radios. Everything is just mildly, maddeningly,
different.

The core thing is that in order to sanely test wifi, the darn
interfaces need to be unbridged, and nearly everything else we had to
do
to do that, fell out of that. And as it turned out, we never really
got around to tackling wifi in the last release, going all ga-ga over
fixing the ISP link. (which of course, I am very happy about. :))

C) I would certainly like, in particular, for someone to improve
openwrt's firewalling system in general, there is a need for a
"fw4" which would generate nf_tables rules rather than iptables.


On Sat, Feb 28, 2015 at 7:25 AM, Rich Brown <richb.hanover@gmail.com> wrote:
> Folks,
>
> Two thoughts:
>
> 1) I'm renaming this thread so that it is easily found in the archives (it was "Just FYI: WNDR3700 (v2???) refurbs available on Amazon for USD49.99")
>
> 2) I've been maintaining the CeroWrtScripts (https://github.com/richb-hanover/CeroWrtScripts) that has a shell script to set lots of the parameters of CeroWrt into a consistent state. To the extent that the capabilities below are simple config changes, we can use this script as a base for converting "Stock OpenWrt" into something more CeroWrt-like.
>
> Best,
>
> Rich
>
> On Feb 27, 2015, at 11:44 PM, David Lang <david@lang.hm> wrote:
>
>> On Fri, 27 Feb 2015, Dave Taht wrote:
>>
>>>> you may have posted this and I'm just not remembering, but do you have a
>>>> list of what's in CeroWRT that OpenWRT won't take upstream (and any info on
>>>> why they won't take the items)?
>>>>
>>>> Daivd Lang
>>
>> trying to break this down by what's a config policy vs what's code (or significant config logic)
>>
>>> * Unbridged interfaces - routing only
>>
>> simple config
>>
>>> * Device Naming by function rather than type
>>
>> is this code or just a set of config settings?
>>
>>> * More open to ipv6 firewall
>>
>> is this just default settings?
>>
>>> * Firewall using device pattern matching to avoid O(n) complexities in
>>> firewall rules
>>
>> This sounds like default settings.
>>
>>> * Babels on and preconfigured by default
>>
>> any code here? or is just that it's there by default?
>>
>>> * Oddball IP address range and /27 subnets
>>
>> simple config
>>
>>> * Polipo Web proxy
>>
>> is this just a different default than upstream?
>>
>>> * Samba by default
>>
>> simple config
>>
>>> * Faster web server
>>
>> just a different default?
>>
>>> * Weird port for the configuration web server
>>
>> simple default
>>
>>> * Pre-enabled wifi and wifi mesh interfaces
>>
>> different defaults
>>
>>> * Huge amount of alternate qdiscs (like pie, ns2_codel, cake, cake2, etc)
>>
>> any custom code here or is this just different kernel config options being turned on?
>>
>>> And:
>>>
>>> A build that includes all these things by default.
>>
>> The vast majority of these seem to be config selections rather then code. Which shows a huge amount of progress from the early days.
>>
>> There seem to be a couple policy points that are worth trying to fight to get upstream
>>
>> 1. Device Naming by function
>>
>> 2. Firewall rules by device pattern matching.
>>
>> 3. pre-enabled wifi and mesh interfaces
>>
>> 4. Samba default (see the recent discussion of common authentication)
>>
>> 5. possibly the web proxy
>>
>> Things that are probably not worth fighting for
>>
>> 1. a build that includes all of this by default
>>
>> 2. all the alternate qdiscs enabled by default
>>
>> 3. weird port for the config web server
>>
>> 4. oddball IP ranges, /27 subnets, bables, and routing between interfaces by default. (This is an approach that is perfect for the "super-duper" builders, although this may just end up being a different default config)
>>
>> any major disagreements or things I missed?
>>
>>
>> It hit me as I was finishing this that a couple things may combine here.
>>
>> By doing device naming by function, firewall rules by device (which ends up being by function), it may make it far easier to have alternate configs, one for bridging, one for routing, and to have options to pre-enable the wifi and mesh interfaces.
>>
>> Thoughts from those who have been more involved with pushing things upstream?
>>
>> David Lang
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>



-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb

Re: [Cerowrt-devel] CeroWrt bits not in OpenWrt (renamed thread)

[David Lang]

On Sat, 28 Feb 2015, Dave Taht wrote:

> You all are right, there are several distinct classes of
> cerowrt-specific mods. I certainly would like to leverage their
> enormous build system (popping out two builds on all arches every
> day), and not have to do regular builds and testing again myself, ever
> again (for as long as I live!). Ideally I would just hand off our
> latest (dumb or smart) bit of code, developed on an x86 and magically
> have someone hand me a huge set of test results on platform of choice,
> a day later.
>
> It is really amazing the architecture coverage they have:
>
> http://downloads.openwrt.org/snapshots/trunk/
>
> A) The most troublesome problem is kernel hacks.

how much of what's left is kernel hacks?

I haven't dug down into it much, but I think I've seen from the discussions thta 
OpenWRT has the ability for you to specify a different kernel version than 
stock. The answer may be to maintain a fork of the kernel with the changes.

> A thought would be to ask the openwrt devs to have a cerowrt repo (or,
> more likely, a make-wifi-fast repo at this point),
> but still several of these patches and future work planned are going
> to be pretty invasive (hitting the mac80211 layer hard as well as
> ath9k). Hopefully felix and co are going to handle much of that, and
> our role here will be more of testing it...
>
> Several other patches are not as invasive - all the different qdiscs
> under test, for example, could easily go into their own
> package. The problem I have here is I am resistant to putting buggy
> code into public repos. For example, the "pfq_codel" version
> does not work worth a damn, and I keep it around because one day it
> might provide insight into why packet fairness doesn't
> work well (or the code may merely be buggy). Similarly, "cake2" is not
> fully baked yet. My own preference for new development
> is to have a small, intelligent, educated number of testers before
> stuff goes upstream.

Ok, there are two cases here.

1. stuff that didn't work out

2. new stuff being experimented with

I'll point out that once it's in a git repo, you can always resurrect something 
old, just keep a record of the commit that deletes the old stuff and you can 
resurrect it by reverting that commit. This does assume that you don't need to 
keep modifying the old stuff to keep it working with kernel changes.

Especially if you are maintaining a kernel fork, I don't see anything wrong with 
including the experimental stuff, and not much problem with you keeping the old 
stuff around (just make sure you add a comment to the help text or description 
that says that it didn't work well)

> I am fully aware that it took too long to get the good stuff done here
> pushed upstream on a regular basis, so certainly working more upstream
> than we did would be good.

for the kernel, you have two upstreams, kernel.org and OpenWRT. The question is 
how frequently you want to go through the work of merging with upstream. I 
personally would love to see you developing against kernel.org kernels and 
pushing your changes that work there, but that means that about every two months 
you will have a bunch of changes to merge into your work (I don't know how much 
upstream development is actually taking place in the areas that you will be 
working on), but this puts you in the best position to merge your changes 
upstream and have OpenWRT collect them by default when they upgrade their 
kernel.

> B) Then there is stuff that is largely configuration, and I can see
> that being a meta package that you
> would have to install manually after flashing, with specialized other
> packages (like an iproute2-cerowrt) with the needed
> other patches - but that is likely to break on many an architecture in
> terms of correctly modifying the network, wireless,
> firewall and dhcp configurations
>
> ... and it presently is invasive in the boot process itself, renaming
> the core network interfaces there.

Yes, this is why I think that it may be worthwhile to make a run at getting this 
change upstream into OpenWRT. It's extremely invasive, but I think the case can 
be made that it simplifies things for users. This can't be done in a stable 
branch, and I would expect that there will be a lot of debate around it, so we 
may be far enough in CC that this won't actually happen until DD, but the sooner 
the discussion starts, the better.

> as an example, the wndr4300 uses vlans by default. The archer has 3
> radios. Everything is just mildly, maddeningly,
> different.

:-)

multiple radios makes sense, why does the wndr4300 use vlans by default?

> The core thing is that in order to sanely test wifi, the darn
> interfaces need to be unbridged, and nearly everything else we had to
> do
> to do that, fell out of that. And as it turned out, we never really
> got around to tackling wifi in the last release, going all ga-ga over
> fixing the ISP link. (which of course, I am very happy about. :))

I agree with this, but I don't think that this is something that we need to make 
the default upstream. A metapackage to change the configs from bridged to 
routed, or pushing a config option upstream to have it support alternate config 
packages. This would be a huge amount of work to create initially, but ongoing 
maintinance is mostly just adding it to new devices, and it's made much easier 
with functional naming. Thinking about it, this may be the way to get functional 
naming in, make it a set of optional configs and then in DD or EE change it to 
the default.

> C) I would certainly like, in particular, for someone to improve
> openwrt's firewalling system in general, there is a need for a
> "fw4" which would generate nf_tables rules rather than iptables.

While I agree with you on this, I think you need to think of this as a separate 
major project in it's own right.

If functional naming gets upstreamed, making changes to the default firewalling 
gets MUCH easier, and a lot of the different firewall rules for the existing 
configs get simplified. The firewall rules would get simplified further with the 
pattern based rules (once you have functional names to pattern match against)

switching to nf_tables rules rather than iptables rules is a major step beyond 
that, and realistically I think it would need to wait until sysadmins start 
using nf_tables rules on servers and firewalls. Otherwise you are making it much 
harder for people to understand and tweak the rules made by the GUI. A fw4 that 
can make either iptables or nf_tables rules could go in quickly, and a tool like 
that would make it much easier for people to get comforatable with nf_tables 
(and see what benefits there are of switching)

David Lang

>
> On Sat, Feb 28, 2015 at 7:25 AM, Rich Brown <richb.hanover@gmail.com> wrote:
>> Folks,
>>
>> Two thoughts:
>>
>> 1) I'm renaming this thread so that it is easily found in the archives (it was "Just FYI: WNDR3700 (v2???) refurbs available on Amazon for USD49.99")
>>
>> 2) I've been maintaining the CeroWrtScripts (https://github.com/richb-hanover/CeroWrtScripts) that has a shell script to set lots of the parameters of CeroWrt into a consistent state. To the extent that the capabilities below are simple config changes, we can use this script as a base for converting "Stock OpenWrt" into something more CeroWrt-like.
>>
>> Best,
>>
>> Rich
>>
>> On Feb 27, 2015, at 11:44 PM, David Lang <david@lang.hm> wrote:
>>
>>> On Fri, 27 Feb 2015, Dave Taht wrote:
>>>
>>>>> you may have posted this and I'm just not remembering, but do you have a
>>>>> list of what's in CeroWRT that OpenWRT won't take upstream (and any info on
>>>>> why they won't take the items)?
>>>>>
>>>>> Daivd Lang
>>>
>>> trying to break this down by what's a config policy vs what's code (or significant config logic)
>>>
>>>> * Unbridged interfaces - routing only
>>>
>>> simple config
>>>
>>>> * Device Naming by function rather than type
>>>
>>> is this code or just a set of config settings?
>>>
>>>> * More open to ipv6 firewall
>>>
>>> is this just default settings?
>>>
>>>> * Firewall using device pattern matching to avoid O(n) complexities in
>>>> firewall rules
>>>
>>> This sounds like default settings.
>>>
>>>> * Babels on and preconfigured by default
>>>
>>> any code here? or is just that it's there by default?
>>>
>>>> * Oddball IP address range and /27 subnets
>>>
>>> simple config
>>>
>>>> * Polipo Web proxy
>>>
>>> is this just a different default than upstream?
>>>
>>>> * Samba by default
>>>
>>> simple config
>>>
>>>> * Faster web server
>>>
>>> just a different default?
>>>
>>>> * Weird port for the configuration web server
>>>
>>> simple default
>>>
>>>> * Pre-enabled wifi and wifi mesh interfaces
>>>
>>> different defaults
>>>
>>>> * Huge amount of alternate qdiscs (like pie, ns2_codel, cake, cake2, etc)
>>>
>>> any custom code here or is this just different kernel config options being turned on?
>>>
>>>> And:
>>>>
>>>> A build that includes all these things by default.
>>>
>>> The vast majority of these seem to be config selections rather then code. Which shows a huge amount of progress from the early days.
>>>
>>> There seem to be a couple policy points that are worth trying to fight to get upstream
>>>
>>> 1. Device Naming by function
>>>
>>> 2. Firewall rules by device pattern matching.
>>>
>>> 3. pre-enabled wifi and mesh interfaces
>>>
>>> 4. Samba default (see the recent discussion of common authentication)
>>>
>>> 5. possibly the web proxy
>>>
>>> Things that are probably not worth fighting for
>>>
>>> 1. a build that includes all of this by default
>>>
>>> 2. all the alternate qdiscs enabled by default
>>>
>>> 3. weird port for the config web server
>>>
>>> 4. oddball IP ranges, /27 subnets, bables, and routing between interfaces by default. (This is an approach that is perfect for the "super-duper" builders, although this may just end up being a different default config)
>>>
>>> any major disagreements or things I missed?
>>>
>>>
>>> It hit me as I was finishing this that a couple things may combine here.
>>>
>>> By doing device naming by function, firewall rules by device (which ends up being by function), it may make it far easier to have alternate configs, one for bridging, one for routing, and to have options to pre-enable the wifi and mesh interfaces.
>>>
>>> Thoughts from those who have been more involved with pushing things upstream?
>>>
>>> David Lang
>>> _______________________________________________
>>> Cerowrt-devel mailing list
>>> Cerowrt-devel@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>
>
>
>

Re: [Cerowrt-devel] CeroWrt bits not in OpenWrt (renamed thread)

[David Lang]

On Sat, 28 Feb 2015, David Lang wrote:

>> as an example, the wndr4300 uses vlans by default. The archer has 3
>> radios. Everything is just mildly, maddeningly,
>> different.
>
> :-)
>
> multiple radios makes sense, why does the wndr4300 use vlans by default?

I may have answered my own question. I just ran across a different system that 
uses an 8-port switch, one port labeled WAN and the other four ports labeled 
LAN1-4 and it uses VLANs internally to make the different interfaces for these.

can interface relabeling change eth0.2 to a functional name? or is it limited to 
the base interface?

David Lang

Re: [Cerowrt-devel] CeroWrt bits not in OpenWrt (renamed thread)

[Rich Brown]

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

We're espousing the proposition that OpenWrt BB and later is a worthy successor to our beloved - and wicked reliable - CeroWrt 3.10.50-1. (See, for example, "CeroWrt Triumphs over Bufferbloat" at http://www.bufferbloat.net/news/ ) 

I just tried this out myself, and the initial experience isn't good/well-documented/easy enough for ordinary people who want it to "just work".

I snagged a TP-Link Archer C7 for $89 on Amazon (so I'd be working with a router that has a little more availability), and installed BB 14.07. I configured it as a secondary router (DHCP on the WAN port). So far, so good - it seems to pass packets, etc.

But a lot of the "special sauce" of CeroWrt seems to be missing. Specifically:

- BB seems to have bloat, and I don't understand how to install and configure the QoS/SQM scripts. (And is there a Luci GUI?)

- It's slick to have Guest and Secure networks

- I miss mDNS naming

- I haven't tried it, but would want to have smooth instructions for native IPv6 and/or IPV6 tunneling

I'm (personally) less concerned about these facilities, but would love to document how to make them work out of the box:

- Routing the interfaces instead of bridging them
- Babel mesh routing
- DNSSEC

 I'm willing to write up and publish the details. I'll also create a script similar to the ones in /usr/lib/CeroWrtScripts so it's easy to make the changes systematically. But I'd like hints for what is required to make these configuration changes. Many thanks.

Rich


On Feb 28, 2015, at 10:25 AM, Rich Brown <richb.hanover@gmail.com> wrote:

> Folks,
> 
> Two thoughts:
> 
> 1) I'm renaming this thread so that it is easily found in the archives (it was "Just FYI: WNDR3700 (v2???) refurbs available on Amazon for USD49.99")
> 
> 2) I've been maintaining the CeroWrtScripts (https://github.com/richb-hanover/CeroWrtScripts) that has a shell script to set lots of the parameters of CeroWrt into a consistent state. To the extent that the capabilities below are simple config changes, we can use this script as a base for converting "Stock OpenWrt" into something more CeroWrt-like.
> 
> Best,
> 
> Rich
> 
> On Feb 27, 2015, at 11:44 PM, David Lang <david@lang.hm> wrote:
> 
>> On Fri, 27 Feb 2015, Dave Taht wrote:
>> 
>>>> you may have posted this and I'm just not remembering, but do you have a
>>>> list of what's in CeroWRT that OpenWRT won't take upstream (and any info on
>>>> why they won't take the items)?
>>>> 
>>>> Daivd Lang
>> 
>> trying to break this down by what's a config policy vs what's code (or significant config logic)
>> 
>>> * Unbridged interfaces - routing only
>> 
>> simple config
>> 
>>> * Device Naming by function rather than type
>> 
>> is this code or just a set of config settings?
>> 
>>> * More open to ipv6 firewall
>> 
>> is this just default settings?
>> 
>>> * Firewall using device pattern matching to avoid O(n) complexities in
>>> firewall rules
>> 
>> This sounds like default settings.
>> 
>>> * Babels on and preconfigured by default
>> 
>> any code here? or is just that it's there by default?
>> 
>>> * Oddball IP address range and /27 subnets
>> 
>> simple config
>> 
>>> * Polipo Web proxy
>> 
>> is this just a different default than upstream?
>> 
>>> * Samba by default
>> 
>> simple config
>> 
>>> * Faster web server
>> 
>> just a different default?
>> 
>>> * Weird port for the configuration web server
>> 
>> simple default
>> 
>>> * Pre-enabled wifi and wifi mesh interfaces
>> 
>> different defaults
>> 
>>> * Huge amount of alternate qdiscs (like pie, ns2_codel, cake, cake2, etc)
>> 
>> any custom code here or is this just different kernel config options being turned on?
>> 
>>> And:
>>> 
>>> A build that includes all these things by default.
>> 
>> The vast majority of these seem to be config selections rather then code. Which shows a huge amount of progress from the early days.
>> 
>> There seem to be a couple policy points that are worth trying to fight to get upstream
>> 
>> 1. Device Naming by function
>> 
>> 2. Firewall rules by device pattern matching.
>> 
>> 3. pre-enabled wifi and mesh interfaces
>> 
>> 4. Samba default (see the recent discussion of common authentication)
>> 
>> 5. possibly the web proxy
>> 
>> Things that are probably not worth fighting for
>> 
>> 1. a build that includes all of this by default
>> 
>> 2. all the alternate qdiscs enabled by default
>> 
>> 3. weird port for the config web server
>> 
>> 4. oddball IP ranges, /27 subnets, bables, and routing between interfaces by default. (This is an approach that is perfect for the "super-duper" builders, although this may just end up being a different default config)
>> 
>> any major disagreements or things I missed?
>> 
>> 
>> It hit me as I was finishing this that a couple things may combine here.
>> 
>> By doing device naming by function, firewall rules by device (which ends up being by function), it may make it far easier to have alternate configs, one for bridging, one for routing, and to have options to pre-enable the wifi and mesh interfaces.
>> 
>> Thoughts from those who have been more involved with pushing things upstream?
>> 
>> David Lang
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> 


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

Re: [Cerowrt-devel] CeroWrt bits not in OpenWrt (renamed thread)

[Alan Jenkins]

On 12/03/15 16:43, Rich Brown wrote:
> We're espousing the proposition that OpenWrt BB and later is a worthy
> successor to our beloved - and wicked reliable - CeroWrt 3.10.50-1.
> (See, for example, "CeroWrt Triumphs over Bufferbloat" at
> http://www.bufferbloat.net/news/ )
>
> I just tried this out myself, and the initial experience isn't
> good/well-documented/easy enough for ordinary people who want it to
> "just work".

i can believe that

> I snagged a TP-Link Archer C7 for $89 on Amazon (so I'd be working
> with a router that has a little more availability), and installed BB
> 14.07. I configured it as a secondary router (DHCP on the WAN port).
> So far, so good - it seems to pass packets, etc.

yay.  seems rather useful being able to suggest working & current 
available hardware.  When I look at OpenWrt comparability information it 
seems... never quite as reassuring as I'd prefer, lets say.  Maybe I'm 
just anxious :).

> But a lot of the "special sauce" of CeroWrt seems to be missing.
> Specifically:
>
> - BB seems to have bloat, and I don't understand how to install and
> configure the QoS/SQM scripts.

Install qos-scripts package.  package install requires first updating, 
since package cache does not persist over reboots.  Pleasantly that 
detail isn't too obscure in luci System -> Software.  "Update lists" 
button is at the top & there's a neighboring label saying "No package 
lists available".

The install doesn't automatically enable the `qos` init script.  Maybe 
it's a general policy like how Fedora treats daemons.  You must

`/etc/init.d/qos enable`, or use luci System -> Startup

> (And is there a Luci GUI?)

luci-app-qos.  Installing that package will pull in qos-scripts for you. 
  It's an easy way to enable qos.  qos is disabled by default... which 
made three steps so far just to enable it.  Though I suppose you need to 
enter the upload / download speed here anyway, before it can sensibly be 
enabled.

sqm-scripts / luci-app-sqm is only available from CC (trunk).  The CC 
version can be installed manually, but it will complain & leave you with 
warnings about it on every subsequent package install.

qos-scripts is "good enough" for many cases, including my own.  Dave 
said in the dlink forum it doesn't do ipv6, and it doesn't do exact 
adjustments for widespread legacy ATM over ADSL.

luci-app-qos does make it easy to classify and prioritize traffic, I 
unscientifically tried that once for BitTorrent however I failed to 
observe a difference, fq_codel seemed to be handling it ok anyway.


> - It's slick to have Guest and Secure networks

please yes

it is at least documented through luci

http://wiki.openwrt.org/doc/recipes/guest-wlan-webinterface


> - I miss mDNS naming

do you just mean e.g. 'router.local'?  I agree - I didn't like the idea 
of losing access & having to reflash because I couldn't find the IP somehow!

I use Avahi but unfortunately it requires a work-around.

https://dev.openwrt.org/ticket/12971

I also changed it to `enable-reflector=yes`, to support mdns across 
routed wireless.  I think that's why I used avahi instead of the 
lightweight mdns daemon.


> - I haven't tried it, but would want to have smooth instructions for
> native IPv6 and/or IPV6 tunneling

maybe a no-go what with ipv6 silently bypassing qos-scripts


> I'm (personally) less concerned about these facilities, but would
> love to document how to make them work out of the box:
>
> - Routing the interfaces instead of bridging them

There's problems if you force people to do this, they may complain they 
can't get to work their windows network and chromecast and... such 
systems that currently work on a single lan.  I think the homenet 
project has the same problem, if they were alive they might be 
interested in such a writeup.

It's morally important, a description for people who want it would be 
very nice to have.  Sorry I don't remember much from setting it up, just 
that I used luci for it.

> - Babel mesh
> routing

similarly... I know this is said to fall out from trying to fix wifi, 
but for the writeups you talk about this might be boiling the ocean.

> - DNSSEC

grr.  tried it on a couple of different systems, never quite get it 
working reliably.

dunno if I found it at the time, but (unless this new box has an RTC 
battery?) it looks like BB leaves you to solve the NTP / DNSSEC circular 
dependency yourself, that must have been my problem

https://dev.openwrt.org/ticket/17724

Worst thing with dnssec, it fails to bootstrap, you get "internet is 
broken", dns is not the first thing people think of!  The above problem 
happens on boot, so I didn't notice it until the following day.


BB doesn't enable dnssec or seem to have a checkbox in luci.  You can 
enable it in the config

http://wiki.openwrt.org/doc/uci/dhcp


I've just had to turn off my debian unbound server, running for many 
months, dig showing "ANSWER: 0" for discordcomics.com.  Years ago I 
tried unbound on Ubuntu desktop and had some occasional 
bootstrap/startup problem.  Seemed it sometimes failed to get/update the 
root keys - maybe when the internet connection wasn't up in time.  The 
debian server was working better, but I'm sure I had startup problems 
occasionally, just I don't turn it off and I don't make anyone _else_ 
rely on it working.

> I'm willing to write up and publish the details. I'll also create a
> script similar to the ones in /usr/lib/CeroWrtScripts so it's easy to
> make the changes systematically.

Cool.  Personally I like the idea it would encourage people to set up 
guest wireless for security.

It'll be more work to make a fully portable script, e.g. that works for 
both 1 and 2 radio boxes (2.4 / 5Ghz).  Might want to say "buy the 
listed hardware, we tested it already".

I guess the nice thing about openwrt is you can run the uci command to 
do the config file editing.

> But I'd like hints for what is
> required to make these configuration changes. Many thanks.
>
> Rich

welp, here was my experience, hopefully some of it is useful to refer to.

Regards
Alan

>
> On Feb 28, 2015, at 10:25 AM, Rich Brown <richb.hanover@gmail.com>
> wrote:
>
>> Folks,
>>
>> Two thoughts:
>>
>> 1) I'm renaming this thread so that it is easily found in the
>> archives (it was "Just FYI: WNDR3700 (v2???) refurbs available on
>> Amazon for USD49.99")
>>
>> 2) I've been maintaining the CeroWrtScripts
>> (https://github.com/richb-hanover/CeroWrtScripts) that has a shell
>> script to set lots of the parameters of CeroWrt into a consistent
>> state. To the extent that the capabilities below are simple config
>> changes, we can use this script as a base for converting "Stock
>> OpenWrt" into something more CeroWrt-like.
>>
>> Best,
>>
>> Rich
>>
>> On Feb 27, 2015, at 11:44 PM, David Lang <david@lang.hm> wrote:
>>
>>> On Fri, 27 Feb 2015, Dave Taht wrote:
>>>
>>>>> you may have posted this and I'm just not remembering, but do
>>>>> you have a list of what's in CeroWRT that OpenWRT won't take
>>>>> upstream (and any info on why they won't take the items)?
>>>>>
>>>>> Daivd Lang
>>>
>>> trying to break this down by what's a config policy vs what's
>>> code (or significant config logic)
>>>
>>>> * Unbridged interfaces - routing only
>>>
>>> simple config
>>>
>>>> * Device Naming by function rather than type
>>>
>>> is this code or just a set of config settings?
>>>
>>>> * More open to ipv6 firewall
>>>
>>> is this just default settings?
>>>
>>>> * Firewall using device pattern matching to avoid O(n)
>>>> complexities in firewall rules
>>>
>>> This sounds like default settings.
>>>
>>>> * Babels on and preconfigured by default
>>>
>>> any code here? or is just that it's there by default?
>>>
>>>> * Oddball IP address range and /27 subnets
>>>
>>> simple config
>>>
>>>> * Polipo Web proxy
>>>
>>> is this just a different default than upstream?
>>>
>>>> * Samba by default
>>>
>>> simple config
>>>
>>>> * Faster web server
>>>
>>> just a different default?
>>>
>>>> * Weird port for the configuration web server
>>>
>>> simple default
>>>
>>>> * Pre-enabled wifi and wifi mesh interfaces
>>>
>>> different defaults
>>>
>>>> * Huge amount of alternate qdiscs (like pie, ns2_codel, cake,
>>>> cake2, etc)
>>>
>>> any custom code here or is this just different kernel config
>>> options being turned on?
>>>
>>>> And:
>>>>
>>>> A build that includes all these things by default.
>>>
>>> The vast majority of these seem to be config selections rather
>>> then code. Which shows a huge amount of progress from the early
>>> days.
>>>
>>> There seem to be a couple policy points that are worth trying to
>>> fight to get upstream
>>>
>>> 1. Device Naming by function
>>>
>>> 2. Firewall rules by device pattern matching.
>>>
>>> 3. pre-enabled wifi and mesh interfaces
>>>
>>> 4. Samba default (see the recent discussion of common
>>> authentication)
>>>
>>> 5. possibly the web proxy
>>>
>>> Things that are probably not worth fighting for
>>>
>>> 1. a build that includes all of this by default
>>>
>>> 2. all the alternate qdiscs enabled by default
>>>
>>> 3. weird port for the config web server
>>>
>>> 4. oddball IP ranges, /27 subnets, bables, and routing between
>>> interfaces by default. (This is an approach that is perfect for
>>> the "super-duper" builders, although this may just end up being a
>>> different default config)
>>>
>>> any major disagreements or things I missed?
>>>
>>>
>>> It hit me as I was finishing this that a couple things may
>>> combine here.
>>>
>>> By doing device naming by function, firewall rules by device
>>> (which ends up being by function), it may make it far easier to
>>> have alternate configs, one for bridging, one for routing, and to
>>> have options to pre-enable the wifi and mesh interfaces.
>>>
>>> Thoughts from those who have been more involved with pushing
>>> things upstream?
>>>
>>> David Lang _______________________________________________
>>> Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>
>
>

Re: [Cerowrt-devel] CeroWrt bits not in OpenWrt (renamed thread)

[Alan Jenkins]

On 12/03/15 20:31, Alan Jenkins wrote:
> On 12/03/15 16:43, Rich Brown wrote:
>> - BB seems to have bloat, and I don't understand how to install and
>> configure the QoS/SQM scripts.
>
> Install qos-scripts package.  package install requires first updating, 
> since package cache does not persist over reboots. Pleasantly that 
> detail isn't too obscure in luci System -> Software.  "Update lists" 
> button is at the top & there's a neighboring label saying "No package 
> lists available".
>
> The install doesn't automatically enable the `qos` init script. Maybe 
> it's a general policy like how Fedora treats daemons.  You must
>
> `/etc/init.d/qos enable`, or use luci System -> Startup
>
>> (And is there a Luci GUI?)
>
> luci-app-qos.  Installing that package will pull in qos-scripts for 
> you.  It's an easy way to enable qos.  qos is disabled by default... 
> which made three steps so far just to enable it. Though I suppose you 
> need to enter the upload / download speed here anyway, before it can 
> sensibly be enabled.

Gah, that was stupidly unclear.  I mean

1. luci-app-qos gives you a nice page under Network -> QOS.

2. There's a config to enable qos, separate from enabling the init 
script, after you've installed qos-scripts.  It's a pity it's not just 
enabled once you start the init script.  luci could just give you a 
button on the QOS page to enable/disable the init script (and start/stop 
at the same time!).  Job done.

Re: [Cerowrt-devel] CeroWrt bits not in OpenWrt (renamed thread)

[Dave Taht]

On Thu, Mar 12, 2015 at 1:31 PM, Alan Jenkins
<alan.christopher.jenkins@gmail.com> wrote:
> On 12/03/15 16:43, Rich Brown wrote:
>>
>> We're espousing the proposition that OpenWrt BB and later is a worthy
>> successor to our beloved - and wicked reliable - CeroWrt 3.10.50-1.
>> (See, for example, "CeroWrt Triumphs over Bufferbloat" at
>> http://www.bufferbloat.net/news/ )
>>
>> I just tried this out myself, and the initial experience isn't
>> good/well-documented/easy enough for ordinary people who want it to
>> "just work".

I am painfully more aware that chaos calmer does not do some of what
we want, notably they really need to fix the dnsmasq-full package to
include something like what we did for DNSSEC, or use tlsdate.

I am equally painfully aware that doing what I want - actually getting
down and dirty in the wifi stack, is HARD, and every minute I spend
doing something else is a minute I lose doing that.

It has long been my hope to find someone - or find someone willing to
pay someone - to handle a higher density of integration of the good
stuff into a user-installable distro. There are several high end
distros of openwrt chaos calmer being maintained in the openwrt
forums, perhaps we could leverage one of those.

Of late, I have been spending more time trying to raise funding, than
actually working.

> i can believe that
>
>> I snagged a TP-Link Archer C7 for $89 on Amazon (so I'd be working
>> with a router that has a little more availability), and installed BB
>> 14.07. I configured it as a secondary router (DHCP on the WAN port).
>> So far, so good - it seems to pass packets, etc.
>
>
> yay.  seems rather useful being able to suggest working & current available
> hardware.  When I look at OpenWrt comparability information it seems...
> never quite as reassuring as I'd prefer, lets say.  Maybe I'm just anxious
> :).
>
>> But a lot of the "special sauce" of CeroWrt seems to be missing.
>> Specifically:
>>
>> - BB seems to have bloat, and I don't understand how to install and
>> configure the QoS/SQM scripts.
>
>
> Install qos-scripts package.  package install requires first updating, since
> package cache does not persist over reboots.  Pleasantly that detail isn't
> too obscure in luci System -> Software.  "Update lists" button is at the top
> & there's a neighboring label saying "No package lists available".
>
> The install doesn't automatically enable the `qos` init script.  Maybe it's
> a general policy like how Fedora treats daemons.  You must
>
> `/etc/init.d/qos enable`, or use luci System -> Startup
>
>> (And is there a Luci GUI?)
>
>
> luci-app-qos.  Installing that package will pull in qos-scripts for you.
> It's an easy way to enable qos.  qos is disabled by default... which made
> three steps so far just to enable it.  Though I suppose you need to enter
> the upload / download speed here anyway, before it can sensibly be enabled.
>
> sqm-scripts / luci-app-sqm is only available from CC (trunk).  The CC
> version can be installed manually, but it will complain & leave you with
> warnings about it on every subsequent package install.
>
> qos-scripts is "good enough" for many cases, including my own.  Dave said in
> the dlink forum it doesn't do ipv6, and it doesn't do exact adjustments for
> widespread legacy ATM over ADSL.
>
> luci-app-qos does make it easy to classify and prioritize traffic, I
> unscientifically tried that once for BitTorrent however I failed to observe
> a difference, fq_codel seemed to be handling it ok anyway.
>
>
>> - It's slick to have Guest and Secure networks
>
>
> please yes
>
> it is at least documented through luci
>
> http://wiki.openwrt.org/doc/recipes/guest-wlan-webinterface
>
>
>> - I miss mDNS naming
>
>
> do you just mean e.g. 'router.local'?  I agree - I didn't like the idea of
> losing access & having to reflash because I couldn't find the IP somehow!
>
> I use Avahi but unfortunately it requires a work-around.
>
> https://dev.openwrt.org/ticket/12971
>
> I also changed it to `enable-reflector=yes`, to support mdns across routed
> wireless.  I think that's why I used avahi instead of the lightweight mdns
> daemon.
>
>
>> - I haven't tried it, but would want to have smooth instructions for
>> native IPv6 and/or IPV6 tunneling
>
>
> maybe a no-go what with ipv6 silently bypassing qos-scripts
>
>
>> I'm (personally) less concerned about these facilities, but would
>> love to document how to make them work out of the box:
>>
>> - Routing the interfaces instead of bridging them
>
>
> There's problems if you force people to do this, they may complain they
> can't get to work their windows network and chromecast and... such systems
> that currently work on a single lan.  I think the homenet project has the
> same problem, if they were alive they might be interested in such a writeup.
>
> It's morally important, a description for people who want it would be very
> nice to have.  Sorry I don't remember much from setting it up, just that I
> used luci for it.
>
>> - Babel mesh
>> routing
>
>
> similarly... I know this is said to fall out from trying to fix wifi, but
> for the writeups you talk about this might be boiling the ocean.
>
>> - DNSSEC
>
>
> grr.  tried it on a couple of different systems, never quite get it working
> reliably.
>
> dunno if I found it at the time, but (unless this new box has an RTC
> battery?) it looks like BB leaves you to solve the NTP / DNSSEC circular
> dependency yourself, that must have been my problem
>
> https://dev.openwrt.org/ticket/17724
>
> Worst thing with dnssec, it fails to bootstrap, you get "internet is
> broken", dns is not the first thing people think of!  The above problem
> happens on boot, so I didn't notice it until the following day.
>
>
> BB doesn't enable dnssec or seem to have a checkbox in luci.  You can enable
> it in the config
>
> http://wiki.openwrt.org/doc/uci/dhcp
>
>
> I've just had to turn off my debian unbound server, running for many months,
> dig showing "ANSWER: 0" for discordcomics.com.  Years ago I tried unbound on
> Ubuntu desktop and had some occasional bootstrap/startup problem.  Seemed it
> sometimes failed to get/update the root keys - maybe when the internet
> connection wasn't up in time.  The debian server was working better, but I'm
> sure I had startup problems occasionally, just I don't turn it off and I
> don't make anyone _else_ rely on it working.
>
>> I'm willing to write up and publish the details. I'll also create a
>> script similar to the ones in /usr/lib/CeroWrtScripts so it's easy to
>> make the changes systematically.
>
>
> Cool.  Personally I like the idea it would encourage people to set up guest
> wireless for security.
>
> It'll be more work to make a fully portable script, e.g. that works for both
> 1 and 2 radio boxes (2.4 / 5Ghz).  Might want to say "buy the listed
> hardware, we tested it already".
>
> I guess the nice thing about openwrt is you can run the uci command to do
> the config file editing.
>
>> But I'd like hints for what is
>> required to make these configuration changes. Many thanks.
>>
>> Rich
>
>
> welp, here was my experience, hopefully some of it is useful to refer to.
>
> Regards
> Alan
>
>
>>
>> On Feb 28, 2015, at 10:25 AM, Rich Brown <richb.hanover@gmail.com>
>> wrote:
>>
>>> Folks,
>>>
>>> Two thoughts:
>>>
>>> 1) I'm renaming this thread so that it is easily found in the
>>> archives (it was "Just FYI: WNDR3700 (v2???) refurbs available on
>>> Amazon for USD49.99")
>>>
>>> 2) I've been maintaining the CeroWrtScripts
>>> (https://github.com/richb-hanover/CeroWrtScripts) that has a shell
>>> script to set lots of the parameters of CeroWrt into a consistent
>>> state. To the extent that the capabilities below are simple config
>>> changes, we can use this script as a base for converting "Stock
>>> OpenWrt" into something more CeroWrt-like.
>>>
>>> Best,
>>>
>>> Rich
>>>
>>> On Feb 27, 2015, at 11:44 PM, David Lang <david@lang.hm> wrote:
>>>
>>>> On Fri, 27 Feb 2015, Dave Taht wrote:
>>>>
>>>>>> you may have posted this and I'm just not remembering, but do
>>>>>> you have a list of what's in CeroWRT that OpenWRT won't take
>>>>>> upstream (and any info on why they won't take the items)?
>>>>>>
>>>>>> Daivd Lang
>>>>
>>>>
>>>> trying to break this down by what's a config policy vs what's
>>>> code (or significant config logic)
>>>>
>>>>> * Unbridged interfaces - routing only
>>>>
>>>>
>>>> simple config
>>>>
>>>>> * Device Naming by function rather than type
>>>>
>>>>
>>>> is this code or just a set of config settings?
>>>>
>>>>> * More open to ipv6 firewall
>>>>
>>>>
>>>> is this just default settings?
>>>>
>>>>> * Firewall using device pattern matching to avoid O(n)
>>>>> complexities in firewall rules
>>>>
>>>>
>>>> This sounds like default settings.
>>>>
>>>>> * Babels on and preconfigured by default
>>>>
>>>>
>>>> any code here? or is just that it's there by default?
>>>>
>>>>> * Oddball IP address range and /27 subnets
>>>>
>>>>
>>>> simple config
>>>>
>>>>> * Polipo Web proxy
>>>>
>>>>
>>>> is this just a different default than upstream?
>>>>
>>>>> * Samba by default
>>>>
>>>>
>>>> simple config
>>>>
>>>>> * Faster web server
>>>>
>>>>
>>>> just a different default?
>>>>
>>>>> * Weird port for the configuration web server
>>>>
>>>>
>>>> simple default
>>>>
>>>>> * Pre-enabled wifi and wifi mesh interfaces
>>>>
>>>>
>>>> different defaults
>>>>
>>>>> * Huge amount of alternate qdiscs (like pie, ns2_codel, cake,
>>>>> cake2, etc)
>>>>
>>>>
>>>> any custom code here or is this just different kernel config
>>>> options being turned on?
>>>>
>>>>> And:
>>>>>
>>>>> A build that includes all these things by default.
>>>>
>>>>
>>>> The vast majority of these seem to be config selections rather
>>>> then code. Which shows a huge amount of progress from the early
>>>> days.
>>>>
>>>> There seem to be a couple policy points that are worth trying to
>>>> fight to get upstream
>>>>
>>>> 1. Device Naming by function
>>>>
>>>> 2. Firewall rules by device pattern matching.
>>>>
>>>> 3. pre-enabled wifi and mesh interfaces
>>>>
>>>> 4. Samba default (see the recent discussion of common
>>>> authentication)
>>>>
>>>> 5. possibly the web proxy
>>>>
>>>> Things that are probably not worth fighting for
>>>>
>>>> 1. a build that includes all of this by default
>>>>
>>>> 2. all the alternate qdiscs enabled by default
>>>>
>>>> 3. weird port for the config web server
>>>>
>>>> 4. oddball IP ranges, /27 subnets, bables, and routing between
>>>> interfaces by default. (This is an approach that is perfect for
>>>> the "super-duper" builders, although this may just end up being a
>>>> different default config)
>>>>
>>>> any major disagreements or things I missed?
>>>>
>>>>
>>>> It hit me as I was finishing this that a couple things may
>>>> combine here.
>>>>
>>>> By doing device naming by function, firewall rules by device
>>>> (which ends up being by function), it may make it far easier to
>>>> have alternate configs, one for bridging, one for routing, and to
>>>> have options to pre-enable the wifi and mesh interfaces.
>>>>
>>>> Thoughts from those who have been more involved with pushing
>>>> things upstream?
>>>>
>>>> David Lang _______________________________________________
>>>> 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



-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb

Re: [Cerowrt-devel] CeroWrt bits not in OpenWrt (renamed thread)

[Alan Jenkins]

On 12/03/15 21:21, Dave Taht wrote:
> On Thu, Mar 12, 2015 at 1:31 PM, Alan Jenkins
> <alan.christopher.jenkins@gmail.com> wrote:
>> On 12/03/15 16:43, Rich Brown wrote:
>>> We're espousing the proposition that OpenWrt BB and later is a worthy
>>> successor to our beloved - and wicked reliable - CeroWrt 3.10.50-1.
>>> (See, for example, "CeroWrt Triumphs over Bufferbloat" at
>>> http://www.bufferbloat.net/news/ )
>>>
>>> I just tried this out myself, and the initial experience isn't
>>> good/well-documented/easy enough for ordinary people who want it to
>>> "just work".
> I am painfully more aware that chaos calmer does not do some of what
> we want, notably they really need to fix the dnsmasq-full package to
> include something like what we did for DNSSEC, or use tlsdate.
>
> I am equally painfully aware that doing what I want - actually getting
> down and dirty in the wifi stack, is HARD, and every minute I spend
> doing something else is a minute I lose doing that.
>
> It has long been my hope to find someone - or find someone willing to
> pay someone - to handle a higher density of integration of the good
> stuff into a user-installable distro. There are several high end
> distros of openwrt chaos calmer being maintained in the openwrt
> forums, perhaps we could leverage one of those.
>
> Of late, I have been spending more time trying to raise funding, than
> actually working.

Personally I'm happy if capable people spend coding time on wifi. Or 
non-coding time, trying to make it happen :-).  You don't need to 
apologize or justify it to us.  The world has qos-scripts in Barrier 
Breaker to prove fq_codel works against bufferbloat.  sqm-scripts in 
Chaos Calmer to work with "the production version of IP".  And tools to 
test it, and drivers that suck less...  Thank you & everyone else.

People love free stuff.  Please look after yourself :-).

I know there's much more left in Cero than DNS security, but - it's a 
whole 'nother research project!  You've shown the world what can be 
done, the results and source code are there.  Recently you mentioned 
looking at nftables, ISTM that project can look after itself.

I gave Rich what I knew, for practical write-ups.  Just because they 
might help spread the word.  Documentation is really helpful, even when 
the code can still be improved.

Alan "and don't let me bother you, I'm terrible with people"

Re: [Cerowrt-devel] CeroWrt bits not in OpenWrt (renamed thread)

[Rich Brown]

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

Hi folks,

On Mar 12, 2015, at 8:53 PM, Alan Jenkins <alan.christopher.jenkins@gmail.com> wrote:

> I gave Rich what I knew, for practical write-ups.  Just because they might help spread the word.  Documentation is really helpful, even when the code can still be improved.

Thanks to Alan and everyone else who responded on this thread. I'm going to go off and begin incorporating the info into a tutorial and script that'll turn these features on.

As I get traction, I'll maintain them in the CeroWrtScripts repo at https://github.com/richb-hanover/CeroWrtScripts

Best,

Rich

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

Re: [Cerowrt-devel] CeroWrt bits not in OpenWrt (renamed thread)

[Toke Høiland-Jørgensen]

>sqm-scripts / luci-app-sqm is only available from CC (trunk).  The CC 
>version can be installed manually, but it will complain & leave you
>with 
>warnings about it on every subsequent package install.

Note that we've been discussing backporting it to BB, but had one outstanding bug that we fixed recently. Been waiting until that fix has been out in CC for sufficiently long to weed out any adverse effects, then we'll get it into BB as well if possible :)

-Toke

Re: [Cerowrt-devel] CeroWrt bits not in OpenWrt (renamed thread)

[Dave Taht]

On Thu, Mar 12, 2015 at 2:47 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
>>sqm-scripts / luci-app-sqm is only available from CC (trunk).  The CC
>>version can be installed manually, but it will complain & leave you
>>with
>>warnings about it on every subsequent package install.
>
> Note that we've been discussing backporting it to BB, but had one outstanding bug that we fixed recently. Been waiting until that fix has been out in CC for sufficiently long to weed out any adverse effects, then we'll get it into BB as well if possible :)

I wouldn't mind restarting work on cake, either, as it simplifies the
sqm-scripts tremendously, and (in it's present form) is mildly faster.

Also exploring the existing policing options would be good at the
higher rates. For an example of use see the last set of comments on
wondershaper must die. And then there's "bobbie", which would be worth
a paper for anyone that wants to talk to me then write it....



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



-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb

Re: [Cerowrt-devel] CeroWrt bits not in OpenWrt (renamed thread)

[Sebastian Moeller]

On Mar 12, 2015, at 22:59 , Dave Taht <dave.taht@gmail.com> wrote:

> On Thu, Mar 12, 2015 at 2:47 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>> 
>>> sqm-scripts / luci-app-sqm is only available from CC (trunk).  The CC
>>> version can be installed manually, but it will complain & leave you
>>> with
>>> warnings about it on every subsequent package install.
>> 
>> Note that we've been discussing backporting it to BB, but had one outstanding bug that we fixed recently. Been waiting until that fix has been out in CC for sufficiently long to weed out any adverse effects, then we'll get it into BB as well if possible :)
> 
> I wouldn't mind restarting work on cake, either, as it simplifies the
> sqm-scripts tremendously, and (in it's present form) is mildly faster.
> 
> Also exploring the existing policing options would be good at the
> higher rates. For an example of use see the last set of comments on
> wondershaper must die. And then there's "bobbie", which would be worth
> a paper for anyone that wants to talk to me then write it….

	I guess, it should be relatively simple to introduce a sign to sqm’s bandwidth fields, with positive denoting HTB shaping, negative simple policing (and zero stays at no shaping or policing); it is not that we have not already “overloaded” the bandwidth field already ;). That way we can keep everything in simple.qos making it more likely people will actually be able to test it… (Currently I have a temporary 100/40 Mbps link so I want to try the policer anyway ;) )
	Now if thee was a cerowrt re-spin that added cake, that would be great


Best Regards
	Sebastian


> 
> 
> 
>> 
>> -Toke
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> 
> 
> 
> -- 
> Dave Täht
> Let's make wifi fast, less jittery and reliable again!
> 
> https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] CeroWrt bits not in OpenWrt (renamed thread)

[Alan Jenkins]

On 12/03/15 21:47, Toke Høiland-Jørgensen wrote:
>> sqm-scripts / luci-app-sqm is only available from CC (trunk).  The CC
>> version can be installed manually, but it will complain & leave you
>> with
>> warnings about it on every subsequent package install.
> Note that we've been discussing backporting it to BB, but had one outstanding bug that we fixed recently. Been waiting until that fix has been out in CC for sufficiently long to weed out any adverse effects, then we'll get it into BB as well if possible :)
>
> -Toke

oh!  I didn't even realize that might be possible, very cool.
Alan

Re: [Cerowrt-devel] CeroWrt bits not in OpenWrt (renamed thread)

[Sebastian Moeller]

On Mar 13, 2015, at 01:50 , Alan Jenkins <alan.christopher.jenkins@gmail.com> wrote:

> On 12/03/15 21:47, Toke Høiland-Jørgensen wrote:
>>> sqm-scripts / luci-app-sqm is only available from CC (trunk).  The CC
>>> version can be installed manually, but it will complain & leave you
>>> with
>>> warnings about it on every subsequent package install.
>> Note that we've been discussing backporting it to BB, but had one outstanding bug that we fixed recently. Been waiting until that fix has been out in CC for sufficiently long to weed out any adverse effects, then we'll get it into BB as well if possible :)
>> 
>> -Toke
> 
> oh!  I didn't even realize that might be possible, very cool.
> Alan

	BTW, I think the bug is the one from your report (sqm not starting after boot and getting confused by disappearing interfaces); but since neither you nor I can recreate the bug’s symptoms anymore with the new code, the likelihood of sqm-scripts appearing in BB increased a lot ;)

Best Regards
	Sebastian

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

Re: [Cerowrt-devel] CeroWrt bits not in OpenWrt (renamed thread)

[David Lang]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 639 bytes --]

On Thu, 12 Mar 2015, Toke Høiland-Jørgensen wrote:

>> sqm-scripts / luci-app-sqm is only available from CC (trunk).  The CC
>> version can be installed manually, but it will complain & leave you
>> with
>> warnings about it on every subsequent package install.
>
> Note that we've been discussing backporting it to BB, but had one outstanding 
> bug that we fixed recently. Been waiting until that fix has been out in CC for 
> sufficiently long to weed out any adverse effects, then we'll get it into BB 
> as well if possible :)

Is the idea of functional interface naming something that is reasonable to talk 
about for CC?

David Lang