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

[David Lang <david@lang.hm>]

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