Re: [Cerowrt-devel] [Cake] looking for some testers this week

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

On Tue, Mar 12, 2019 at 2:24 PM Pete Heist <pete@heistp.net> wrote:
>
>
> > On Mar 12, 2019, at 4:19 AM, Dave Taht <dave.taht@gmail.com> wrote:
> >
> > 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)
>
> Yes, this rfc and patch are off the deep end. :) Then again, I haven’t used the Mbone since ’95 on IRIX, so I for one am ok with killing that dead.

It had 16 remaining nodes 12 years ago, which is the last we heard from it.

> Working on building my first OpenWRT image, ever. Does 32-bit mips do you much good?

mips big endian test is good. Endianess always bites me on the wrong
side of the egg.

> I guess I’ll just see what I can do with two boxes somewhere on 224.0.0.0/4...

only 225/8-231/8 are opened up from the relevant reserved for
multicast space by this patch series. They have always been unassigned
addresses. I did not change the userspace IN_MULTICAST macro, but
nearly nothing in userspace checks that.

224/8 is used by a half dozen common applications and reserved by a
few hundred old ones. Theoretically we could use 224.6/16 and up but
it was simpler to do 224.

232 and up is unclear.

> > 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.
>
> Looking forward to that patch (esp. Cake).
>
> > There's one other thing I'd like to test, if at all possible - that's
> > the new babel-hmac code.
>
> Likely too much for me to digest before the conference.



-- 

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