[Cerowrt-devel] notes on going for a stable release

[David Personette]

On Tue, Jan 14, 2014 at 1:07 AM, Dave Taht <dave.taht at gmail.com> 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 at davedesk:~# cd /sys/kernel/debug/mips/
> root at 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 at outpost:~# uname -a
Linux outpost 3.10.26 #1 Sun Jan 12 14:50:55 PST 2014 mips GNU/Linux
root at outpost:~# cat /sys/kernel/debug/mips/unaligned_instructions
0
root at outpost:~# uptime
 06:49:16 up 20:28,  load average: 0.00, 0.03, 0.04
root at outpost:~# dmesg | grep "checksum failed"
root at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140114/69f5a0fc/attachment-0001.html>