From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (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 5AB5221F180 for ; Tue, 14 Jan 2014 20:11:04 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id u57so1277232wes.1 for ; Tue, 14 Jan 2014 20:11:02 -0800 (PST) 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=wgbbPt76/Sp4aPGuA+NpcQpv7jSLltMGbMapek9/4CA=; b=XLViwxqlaHxc/UX235m7Ahgp4aLVhgvY6KI40mZ2UifFO8ydJ16/6xARe4ZdZeG36r GzWLepqW6fcIUn9FdIFIDKEYIikIvFfSqXapWMzvWgXzTDR5c1WNUB3CBDem8n4kUGcu OPRf0NQEw9Sm/436gq7TSH6Jw/aIU/+ukqJfubFjtOYRf77PJ74MB5i9qmdwlxrg+jlE kKJwXQaTyMebPv0l32MuNoYg+TgvtyiexKg4owr1bnmxwlufHH55nrQT2VDybbjkDk9i feQKUwxgi3r0zBwI0lRvjXTyVDoN4LcEEjRl/4/c9O5EDKQizMhcuwL0+bXpGQP4dit9 9oyg== MIME-Version: 1.0 X-Received: by 10.180.211.39 with SMTP id mz7mr29938wic.53.1389759062101; Tue, 14 Jan 2014 20:11:02 -0800 (PST) Received: by 10.217.123.69 with HTTP; Tue, 14 Jan 2014 20:11:02 -0800 (PST) In-Reply-To: References: Date: Tue, 14 Jan 2014 23:11:02 -0500 Message-ID: From: Dave Taht To: David Personette Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] notes on going for a stable release 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: Wed, 15 Jan 2014 04:11:27 -0000 X-List-Received-Date: Wed, 15 Jan 2014 04:11:27 -0000 On Tue, Jan 14, 2014 at 7:36 AM, David Personette wrote= : > On Tue, Jan 14, 2014 at 1:07 AM, Dave Taht wrote: >> >> ** Instruction traps >> >> The instruction trap problem has resurfaced on boot. It is unknown >> what triggers it. It doesn't happen very much after boot in my limited >> testing. >> >> The last time it bit me was on doing tests on a busy ipv6-enabled >> network where it thoroughly blew up the tests. (even when not doing >> ipv6 itself) It also made cerowrt unreliable. >> >> oot@davedesk:~# cd /sys/kernel/debug/mips/ >> root@davedesk:/sys/kernel/debug/mips# cat unaligned_instructions >> 7884 >> >> What values do you see, both on boot and after some uptime? >> >> For more details on how to actually fix the bug: >> http://www.bufferbloat.net/issues/419 > > > I updated to the 3.10.26-1 build, so not much uptime. Also, I don't have = my > IPv6 hurricane tunnel active ATM. The bug cropped up with native ipv6 on the wire, notably on the ge00 interface. > > root@outpost:~# uname -a > Linux outpost 3.10.26 #1 Sun Jan 12 14:50:55 PST 2014 mips GNU/Linux > root@outpost:~# cat /sys/kernel/debug/mips/unaligned_instructions > 0 Since I get 7k+ errors on boot with 3.10.24-8, I think .26 is looking like an improvement in this respect. there is btw, a fix for setting mcast_rates in 3.10.26-1. I have long thoug= ht that we should *default* to a higher rate (9mbits for 2.4ghz and 12 for 5 ghz) as freifunk does for each ssid, for multicast. This will knock weak signal'd devices off the network entirely, but minimize the impact of multicast on everyone else. " hostapd: fix mcast_rate setting Introduced by ("netifd: add wireless configuration support and port mac80211 to the new framework") Reported-by: Ren=E9 van Weert Signed-off-by: Antonio Quartulli " to test that, add a option mcast_rate 9000 under each wifi-iface stanza in /etc/config/wireless. You can do things like fiddle with mdns-scan on your client to see if that works better/faster or worse. > root@outpost:~# uptime > 06:49:16 up 20:28, load average: 0.00, 0.03, 0.04 > root@outpost:~# dmesg | grep "checksum failed" > root@outpost:~# > I am encouraged. >> >> ** BCP38 compliance >> Cerowrt does not currently stop unknown rfc1918 addresses from going out >> ge00. >> ** Squash incoming diffserv bits >> many providers pee on the diffserv bits. It would be good to detect it >> and reset to BE incoming packets. (note: IPv6 is far less peed on.). >> There was a nice idea discussed last year on using conntrack to match >> incoming with outgoing diffserv bits. > > > I'd added this into my /etc/firewall.user. I'd be happy to work on adding= it > into the official script if you would like. I'm a sysadmin, what developm= ent > skills I have are in scripting. Which part? is it possible to squash just the diffserv and not the ecn bits= ? iptables and ipv6tables lines appreciated. Also additional suggestions for firewall rules appreciated. One thing I added to simple.qos in the last go round was deprioritizing icmp a bit post-wondershaper-rant. # ICMP traffic - Don't impress your friends. Deoptimize to manage ping floo= ds # better instead $TC filter add dev $IFACE parent 1:0 protocol ip prio 8 \ u32 match ip protocol 1 0xff flowid 1:13 $TC filter add dev $IFACE parent 1:0 protocol ipv6 prio 9 \ u32 match ip protocol 1 0xff flowid 1:13 >> >> ** SSL support for the configuration interfaces >> All the plumbing exists for this in cero, it just has to be made to >> work. the key generation routine needs to be fixed in uci-defaults and >> lighttpd config updated. It's embarrassing to not have SSL running. > > > If it's scripting and web server config, I'll work on this too. GOFERIT! The cert generation is just plain wrong for lighttpd... controlled by this file... (which vanishes after boot) https://github.com/dtaht/cerofiles-next/blob/cerowrt-next/files/etc/uci-def= aults/make-certs.sh and could use to get re-run out of cron or something after sufficient randomness has been generated to ensure a decent cert. and lightttpd doesn't seem to like the generated cert or trying to listen with ssl enabled on https://cerowrt.local:81 (yes, I'd like to keep using a weird port number for the admin interface) I don't mind shipping openssl rather than pxg if that's what's needed to generate a valid cert. >> >> * Bufferbloat.net problems >> the bufferbloat.net servers are undermaintained and obsolete. I long >> ago swapped out my sysadmin and ruby skills for other things. >> >> ** huchra replacement (one disk currently crashed, the other going) >> In addition to running this mailing list this used to be 1/5th of the >> openwrt build cluster. >> >> lists needs to move to a virtual server ASAP. >> >> openwrt could really use a good build cluster. been running most of >> theirs now for a couple years, out of machines pulled from the junk >> bin. >> >> ** Web Site updates >> the redmine implementation on bufferbloat.net has been overrrun by >> spam and I stopped >> accepting new contributors that didn't contact me also via email >> long ago. >> >> given how hard it would be to update the present website, perhaps >> moving to cerowrt.org >> on a virtual server will be simpler. > > > This I can work on now, if you like, I can spin up a Digital Ocean VM tha= t > should be able to run a mailing list with no problems. Getting Postfix se= tup > should be a snap, I'm not sure what else is needed for the mailing list, = but > we can discuss it off the mailing list. I can free up some time to work on this fairly soon. Let me know when you can set aside a few hours (I am presently on EST) > Did you want a new name or keep > huchra for the VM? Once it's up, getting a list of needed software from > huchra, certs, and the data can be synced over, do some testing, then the > DNS A and MX records can be updated. Oh, that would be nice. We haven't had anybody caring for the servers since Richard Pitt left us... The other big problem is updating from an ancient version of redmine + postgres to chilliproject + postgres. > Hmm, just saw that Digital Ocean still doesn't have IPv6 yet. Will that b= e a > problem? Any other suggestions for hosting it? I've used them for several > little projects, they have a good interface and rates, IMHO. Thanks. Yep, need ipv6. I have a pair of linode instances spun up but have never done anything with them aside from use them as targets for rrul tests. One is in NJ, the other in england. Linode seems competent.= .. > -- > David P. > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html