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 <da...@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
