On Thu, Mar 12, 2015 at 1:31 PM, Alan Jenkins <alan.christopher.jenk...@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.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 -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
