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

[Rich Brown <richb.hanover@gmail.com>]

[-- 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 --]