From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 38AB821F381 for ; Thu, 12 Mar 2015 14:21:20 -0700 (PDT) Received: by obcvb8 with SMTP id vb8so16787242obc.10 for ; Thu, 12 Mar 2015 14:21:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=S853ba1S4bZ45kwR/G/jdlkIrE4vjmzqiwPOMrOvYbw=; b=IQHOk/6xsrrTut16zX8W8/prOAwSpIdJgQkE/I2o2Jxb5KhI7ahM3Bkv5LHJBpOVC/ JdcRdy87WB+zKEkDs0otlIlSXQdtS9vHU7SHmAD4Kzc87/2U155LJmoo3lOJO8/8YZbl A1uu78bCHH3GJvsL1NnYzzfJK53+x6w6CkTgtS1fQmUCvi+9TGexb5SA3qTUEAhrpUtE s4aV+nK/WzjMKsPWYV41AQkizELSLo9Zz3Zp9WYj3Pa3mXrMTZqlx6dEGFy9Fj3XGc0o CJ4aCWtOCopjwao9ocHDWJj//LPxdMpNwpPP97N2EwhpL6depLuD/S8DRD4Bv/f5muIz 3DuA== MIME-Version: 1.0 X-Received: by 10.202.175.76 with SMTP id y73mr11490280oie.81.1426195279770; Thu, 12 Mar 2015 14:21:19 -0700 (PDT) Received: by 10.202.51.66 with HTTP; Thu, 12 Mar 2015 14:21:19 -0700 (PDT) In-Reply-To: <5501F7B7.9040105@gmail.com> References: <7DFEBF4E-513B-4F41-B559-46BC9857AB40@gmail.com> <5501F7B7.9040105@gmail.com> Date: Thu, 12 Mar 2015 14:21:19 -0700 Message-ID: From: Dave Taht To: Alan Jenkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: cerowrt-devel Subject: Re: [Cerowrt-devel] CeroWrt bits not in OpenWrt (renamed thread) X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 21:21:49 -0000 On Thu, Mar 12, 2015 at 1:31 PM, Alan Jenkins 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 availab= le > hardware. When I look at OpenWrt comparability information it seems... > never quite as reassuring as I'd prefer, lets say. Maybe I'm just anxiou= s > :). > >> 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, si= nce > 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 enable= d. > > 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 f= or > 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 obser= ve > 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 o= f > 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=3Dyes`, to support mdns across rou= ted > wireless. I think that's why I used avahi instead of the lightweight mdn= s > 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 system= s > 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 write= up. > > It's morally important, a description for people who want it would be ver= y > 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 worki= ng > 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 ena= ble > 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 mont= hs, > 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 gue= st > wireless for security. > > It'll be more work to make a fully portable script, e.g. that works for b= oth > 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 >> 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 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 --=20 Dave T=C3=A4ht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb