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