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 _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
