[Cerowrt-devel] CeroWrt bits not in OpenWrt (renamed thread)
alan.christopher.jenkins at gmail.com
Thu Mar 12 16:31:51 EDT 2015
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.
> - 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
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
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
it is at least documented through luci
> - 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.
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
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
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
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
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.
welp, here was my experience, hopefully some of it is useful to refer to.
> On Feb 28, 2015, at 10:25 AM, Rich Brown <richb.hanover at gmail.com>
>> 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.
>> On Feb 27, 2015, at 11:44 PM, David Lang <david at 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?
>>>> 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
>>> 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
>>> 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 at lists.bufferbloat.net
More information about the Cerowrt-devel