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

[Dave Taht]

On Thu, Mar 12, 2015 at 1:31 PM, Alan Jenkins
<alan.christopher.jenkins at gmail.com> wrote:
> 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 am painfully more aware that chaos calmer does not do some of what
we want, notably they really need to fix the dnsmasq-full package to
include something like what we did for DNSSEC, or use tlsdate.

I am equally painfully aware that doing what I want - actually getting
down and dirty in the wifi stack, is HARD, and every minute I spend
doing something else is a minute I lose doing that.

It has long been my hope to find someone - or find someone willing to
pay someone - to handle a higher density of integration of the good
stuff into a user-installable distro. There are several high end
distros of openwrt chaos calmer being maintained in the openwrt
forums, perhaps we could leverage one of those.

Of late, I have been spending more time trying to raise funding, than
actually working.

> 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
>>>
>>>
>>
>>
>>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb