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

[Dave Taht]

On Tue, Jan 14, 2014 at 7:36 AM, David Personette <dperson at gmail.com> wrote:
> 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.

The bug cropped up with native ipv6 on the wire, notably on the ge00
interface.

>
> 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

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 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 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é van Weert <r.vanweert at sowifi.com>
    Signed-off-by: Antonio Quartulli <antonio at meshcoding.com>
"

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 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:~#
>
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 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



>>
>> ** 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-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.


>>
>> * 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.

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 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...

> --
> David P.
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html