[Cake] looking for some testers this week

[Dave Taht <dave.taht@gmail.com>]

I don't build openwrt regularly anymore, and I'm not setup at the
moment to build anything but x86 which doesn't help. I'm bringing my
usual wndr3700v2, 3800, ubnt gear to the conference though... and will
hopefully get a build going for myself... and I'd love to get more
folk testing this new stuff than just me.

I got two separate patch sets I'd like us to be able to test. it's
easier to just fold them into one build.

We already made the 240/4 address range work in openwrt in december.
This patch adds in other formerly reserved address ranges:

1) https://github.com/dtaht/unicast-extensions/blob/master/patches/linux/0001-Allow-0.0.0.0-8-and-reduce-localnet-and-enable-225-2.patch

And it would be good to know if these addresses worked at all, on
wifi, and through nat. We hit a limit in the netifd daemon last time.

(this is in relation to my moonshot talk at netdevconf. Which is
totally a moonshot)

2) I hope we have the first SCE (
https://tools.ietf.org/html/draft-morton-taht-tsvwg-sce-00 )  patchset
up fairly soon for fq_codel_fast (my out of tree mildly improved
fq_codel), and sch_cake. Maybe Freebsd also, if anyone here runs that.

 I'm going to put up a few more flent servers to see what happens
(with the SCE patches, not the former, too dangerous). First objective
is to see if "they do no harm", only, and we need some tcpdumps of the
ecn bit patterns. Basically to enable it in openwrt or elsewhere, we
just set the shortly to be revised ce_threshold to 1ms, which is
easily done in an option in the sqm scripts.

There's one other thing I'd like to test, if at all possible - that's
the new babel-hmac code. And I have not the foggiest idea on how to
compile a package with a git line like this:

... from a message from juliusz ...

    git clone -b hmac --recurse-submodules https://github.com/jech/babeld

While this code is almost completely untested, it is meant to eventually
implement the protocol described in

    https://tools.ietf.org/html/draft-ietf-babel-hmac

Known issues:

  - no interop testing has been done yet;
  - we create a neighbour entry too early, which makes us vulnerable to DoS;
  - we compute HMAC for each TLV, rather than just once for the whole
    packet, which, again, makes us vulnerable to DoS;
  - we don't timeout neighbours properly, which makes us vulnerable to
    delayed packets;
  - we only support sending one HMAC (receiving multiple HMACs should
    work, but for obvious reasons it's untested);
  - we don't support key rotation.

You can test this code by saying something like:

    babeld -C 'key id test type sha256 value
ebf49e6fbc6414aa567e30891846e96963cdda73289b9cd245d67ff9d281abc0' -C
'interface eth0 hmac test'

The "key" stanza defines a key of type sha256, with the value given as
a 32 byte-long hex key. The "interface" stanza enables the key on the
interface eth0.

In addition to "type sha256", we support "type blake2s", which requires
a 16 byte-long key.

-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740