[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 at 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 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?
>>>
>>>> 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 at lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>
>
>