<div dir="ltr">On Tue, Jan 14, 2014 at 1:07 AM, Dave Taht <span dir="ltr"><<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>></span> wrote:<br><div><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">** Instruction traps<br>
<br>
The instruction trap problem has resurfaced on boot. It is unknown<br>
what triggers it. It doesn't happen very much after boot in my limited<br>
testing.<br>
<br>
The last time it bit me was on doing tests on a busy ipv6-enabled<br>
network where it thoroughly blew up the tests. (even when not doing<br>
ipv6 itself) It also made cerowrt unreliable.<br>
<br>
oot@davedesk:~# cd /sys/kernel/debug/mips/<br>
root@davedesk:/sys/kernel/debug/mips# cat unaligned_instructions<br>
7884<br>
<br>
What values do you see, both on boot and after some uptime?<br>
<br>
For more details on how to actually fix the bug:<br>
<a href="http://www.bufferbloat.net/issues/419" target="_blank">http://www.bufferbloat.net/issues/419</a><br></blockquote><div><br>I updated to the 3.10.26-1 build, so not much uptime. Also, I don't have my IPv6 hurricane tunnel active ATM.<br>
<br>root@outpost:~# uname -a<br>Linux outpost 3.10.26 #1 Sun Jan 12 14:50:55 PST 2014 mips GNU/Linux<br>root@outpost:~# cat /sys/kernel/debug/mips/unaligned_instructions<br>0<br>root@outpost:~# uptime<br> 06:49:16 up 20:28, load average: 0.00, 0.03, 0.04<br>
root@outpost:~# dmesg | grep "checksum failed"<br>root@outpost:~# <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
** BCP38 compliance<br>
Cerowrt does not currently stop unknown rfc1918 addresses from going out ge00.<br>
** Squash incoming diffserv bits<br>
many providers pee on the diffserv bits. It would be good to detect it<br>
and reset to BE incoming packets. (note: IPv6 is far less peed on.).<br>
There was a nice idea discussed last year on using conntrack to match<br>
incoming with outgoing diffserv bits.<br></blockquote><div><br></div><div>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
** SSL support for the configuration interfaces<br>
All the plumbing exists for this in cero, it just has to be made to<br>
work. the key generation routine needs to be fixed in uci-defaults and<br>
lighttpd config updated. It's embarrassing to not have SSL running.<br></blockquote><div><br></div><div>If it's scripting and web server config, I'll work on this too.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Bufferbloat.net problems<br>
the <a href="http://bufferbloat.net" target="_blank">bufferbloat.net</a> servers are undermaintained and obsolete. I long<br>
ago swapped out my sysadmin and ruby skills for other things.<br>
<br>
** huchra replacement (one disk currently crashed, the other going)<br>
In addition to running this mailing list this used to be 1/5th of the<br>
openwrt build cluster.<br>
<br>
lists needs to move to a virtual server ASAP.<br>
<br>
openwrt could really use a good build cluster. been running most of<br>
theirs now for a couple years, out of machines pulled from the junk<br>
bin.<br>
<br>
** Web Site updates<br>
the redmine implementation on <a href="http://bufferbloat.net" target="_blank">bufferbloat.net</a> has been overrrun by<br>
spam and I stopped<br>
accepting new contributors that didn't contact me also via email<br>
long ago.<br>
<br>
given how hard it would be to update the present website, perhaps<br>
moving to <a href="http://cerowrt.org" target="_blank">cerowrt.org</a><br>
on a virtual server will be simpler.<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>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.<br>
<br></div><div>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.<br>
</div></div><br>-- <br></div><div class="gmail_extra">David P.<br><br></div></div></div>