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. 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 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:~# > ** 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 development skills I have are in scripting. > ** 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. > * 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 list, but we can discuss it off the mailing list. 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. Hmm, just saw that Digital Ocean still doesn't have IPv6 yet. Will that 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. -- David P.