[Cerowrt-devel] looking for some testers this week

[Cerowrt-devel] looking for some testers this week

[Dave Taht]

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

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

[Pete Heist]

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

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

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

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

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

[Pete Heist]

> On Mar 12, 2019, at 10:24 PM, Pete Heist <pete@heistp.net> wrote:
> 
> Yes, this rfc and patch are off the deep end. :)

Meant that in a good way. The potential new IP space is enormous.

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

[Dave Taht]

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

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

[Pete Heist]

[-- Attachment #1: Type: text/plain, Size: 2044 bytes --]


> On Mar 13, 2019, at 12:20 AM, Dave Taht <dave.taht@gmail.com> wrote:
> 
> 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.

So, for ar71xx generic om2p, I’m able to set up an AP/router with IP 225.1.2.1:

root@uniextap:~# ip addr show br-lan
8: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether ac:86:74:10:26:30 brd ff:ff:ff:ff:ff:ff
    inet 225.1.2.1/24 brd 225.1.2.255 scope global br-lan
       valid_lft forever preferred_lft forever

and pick up a DHCP address in that subnet from an STA:

root@uniextsta:~# ip addr show wlan0
5: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether ac:86:74:03:0d:f2 brd ff:ff:ff:ff:ff:ff
    inet 225.1.2.120/24 brd 225.1.2.255 scope global wlan0
       valid_lft forever preferred_lft forever
    inet6 fe80::ae86:74ff:fe03:df2/64 scope link 
       valid_lft forever preferred_lft forever

and NAT traffic on that subnet to the Internet:

root@uniextsta:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=56 time=11.562 ms
64 bytes from 8.8.8.8: seq=1 ttl=56 time=12.722 ms

root@uniextap:~# tcpdump -i eth1 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
18:50:32.290616 IP uniextap.lan > google-public-dns-a.google.com: ICMP echo request, id 1252, seq 0, length 64
18:50:32.300259 IP google-public-dns-a.google.com > 10.72.0.37: ICMP echo reply, id 1252, seq 0, length 64
18:50:33.291222 IP uniextap.lan > google-public-dns-a.google.com: ICMP echo request, id 1252, seq 1, length 64
18:50:33.302339 IP google-public-dns-a.google.com > 10.72.0.37: ICMP echo reply, id 1252, seq 1, length 64

Tires kicked. Anything else?

[-- Attachment #2: Type: text/html, Size: 8178 bytes --]