From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (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 37D3021F118 for ; Wed, 15 Jan 2014 06:47:18 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id q59so1838713wes.25 for ; Wed, 15 Jan 2014 06:47:16 -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=hWfGhXQh8QU2kqqRkZNQkl6hSus+iKmRVBW5id0bs7I=; b=o9dumScXl+jj/8VTFHrbJaRSVJcsHJ5heFcC4epkt5FHZ66W8O4MOSnU90CjicLIqF UP9V8uv4887Yn2IkQcvfYIswIHjIIyRTUqKaBYm0gxCuwObCjz33lx0bWIv3klbodanK vF076XuobwpokstYgJRH/VQ7p+WGMonMkzGVK0AA09S1goSj8cnwSlg6kWV94S16yrTw EYst30DtgHy6LHokaYa9PygvICRn7y3XdesVImPxpT+1l8z7IwSo3S5oLAuzvcMWjs2Y yTnwGKTkP4TKdqXQoQx3JKBEnoAGKt12bESAqxW5JT3JvTBSs4RDc6AOFxu+rC5am1of tfLw== MIME-Version: 1.0 X-Received: by 10.180.211.39 with SMTP id mz7mr2722440wic.53.1389797235818; Wed, 15 Jan 2014 06:47:15 -0800 (PST) Received: by 10.217.123.69 with HTTP; Wed, 15 Jan 2014 06:47:15 -0800 (PST) In-Reply-To: References: Date: Wed, 15 Jan 2014 09:47:15 -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 14:47:29 -0000 On Wed, Jan 15, 2014 at 7:27 AM, David Personette wrote= : > On Tue, Jan 14, 2014 at 11:11 PM, Dave Taht wrote: >> >> On Tue, Jan 14, 2014 at 7:36 AM, David Personette >> wrote: >> > On Tue, Jan 14, 2014 at 1:07 AM, Dave Taht wrote= : >> there is btw, a fix for setting mcast_rates in 3.10.26-1. I have long >> thought >> 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 we= ak >> 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 th= at >> works better/faster or worse > > > I've added your recommended "option mcast_rate 9000" to the 2.4 ghz and > "option mcast_rate 12000" to the 5 ghz. I'll reboot the router in a bit > (random other services aren't happy after a network restart; where random= =3D=3D > I don't remember what breaks). > >> >> >> >> >> ** 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 i= t >> >> 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 went and looked over the firewall stuff in cero and this stanza was missi= ng. So it isn't getting called. # include a file with users custom iptables rules config include option path /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 >> > development >> > 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 >> floods >> # 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 > > > Sorry, didn't trim quite enough to designate what I was replying to, I ha= d > meant that I added the rfc1918 egress blocking to my /etc/firewall.user. = But > I do have a few lines (that I thought came from this mailing list) for > cleaning up diffserv bits. Although looking at the output of 'iptables -S= ' > now, I'm not sure that it's even doing what the original author intended. > Instead of three dscp classes (which iptables accepts without throwing an > error), it seems to only keep one of them in the ACCEPT line... it will > probably have to be broken out into multiple lines. If it's even doing wh= at > you were interested in, in the first place. Please note it's also been a really long time since I touched iptables... so everything I write below could be wrong. While the rest of you lovable crazies are putting this stuff on your main gw I'm usually in a lab with all the firewalls off internally, doing benchmarks.... > ### Configure both IPv4 and IPv6 > ipt() { > iptables $* > ip6tables $* > } > # iptables doesn't support an inverted match > # ipt -t mangle -A PREROUTING -m dscp ! --dscp-class AF11,AF21,BE -j DSCP= \ > # --set-dscp-class BE > ipt -t mangle -N FIX_TOS > ipt -t mangle -A FIX_TOS -m dscp --dscp-class AF11,AF21,BE -j ACCEPT I sure wish/hope that works. Otherwise writing 23 firewall rules is kind of= hard on iptables. Definately incomplete otherwise... > ipt -t mangle -A FIX_TOS -j DSCP --set-dscp-class BE What I see is a ton of CS1 traffic that I don't think originated that way. I don't mind re-marking CS1 traffic to be BE on entry, and then applying local rules (trying to match torrent for example) I think this needs to happen only on exiting the ge00 interface on entry. We want to not mangle our own diffserv domain. > for i in sw00 sw10 gw00 gw10 gw01 gw11; do > ipt -t mangle -A POSTROUTING -o $i -j FIX_TOS > done So a change to: ipt -t mangle -A PREROUTING -i ge00 -j FIX_TOS ? moving onto bcp38... http://tools.ietf.org/html/bcp38 > # Create a rfc1918 IP filter > iptables -N grey > iptables -A grey -s 172.30.42.0/24 -j ACCEPT > iptables -A grey -s 10.0.0.0/8 -j DROP > iptables -A grey -s 127.0.0.0/8 -j DROP > iptables -A grey -s 172.16.0.0/12 -j DROP > iptables -A grey -s 192.168.0.0/16 -j DROP > iptables -A grey -s 169.254.0.0/16 -j DROP > iptables -I delegate_forward 4 -o ge00 -j grey 1) We have a problem is that bcp38 should not be on by default in a double nat situation. Or at least be more clever and grok if it's external interface is a rfc1918 address that it should be allowed to send to it. Or punt and not enable bcp38 in a double nat situation. 2) Is there BCP38 for ipv6? I know the default rules for hurricane "do the right thing", but native? 3) At least in my networks I use 172.x subnets heavily 4) And ipset is available. I don't know if the gui supports it or what the difference in speed would be by traversing this many rules. Moving onto a different thought on a slightly different topic I think something like this should be a defined rule in the /etc/config/firewall so that missing hosts get information back... (untested) iptables -N noegress iptables -A noegress -d 10.0.0.0/8 -j REJECT # with destination unreachable somehow iptables -A noegress -d 127.0.0.0/8 -j REJECT iptables -A noegress -d 172.16.0.0/12 -j REJECT iptables -A noegress -d 192.168.0.0/16 -j REJECT iptables -A noegress -d 169.254.0.0/16 -j REJECT iptables -I delegate_forward 4 -o ge00 -j noegress #here? why this rule? > >> >> >> >> >> ** 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 an= d >> >> 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-= defaults/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. > > > I'll start working on it. Thanks. > >> >> >> >> >> * 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 >> > that >> > should be able to run a mailing list with no problems. Getting Postfix >> > setup >> > should be a snap, I'm not sure what else is needed for the mailing lis= t, >> > 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 fro= m >> > 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 tha= t >> > be 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... > > > I have nothing against Linode's service. The nice things about DigitalOce= an > are: all SSD storage, and their rates are about half Linode. Linode offer= s > more CPUs at each node size however, and has functional IPv6 (which I > thought that they would have straightened out by now *SIGH*). > > I'm eastern time too. I'm get off work at 17:30, but can probably work in= an > extra meeting during the day if it works out better for you. I'm off next > couple of Mondays so have a 3 day weekends to work on things in. You can > reach me via email, gtalk, "hangouts", and I'll be glad to give you my PO= TS > numbers on a medium that can't easily be harvested by bots. > > -- > David P. > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html