IPV6_SUBTREES is helpful for source specific routing (ietf homenet)

[dtaht]

It looks as though your current kernel build does not have IPV6_SUBTREES enabled. It's a pretty harmless option that makes ipv6 source specific routing work better which is one of the things the ietf homenet working group needs.

I've managed to get the rpi and odroid folk to fix this so far, it's just an omission in many arm derived kernels (it's on on most mainline distros, and openwrt).

With it on, you get the ability to eliminated bcp38-like issues for ipv6, and be multi-homed, like this.

root@pi3:/home/d/git/bird# ip -6 route

Go out one router this way

default from 2001:552:6045:bd:3c4d:754a:3a86:650c via fe80::16cc:20ff:fee5:64c2 dev eth0 proto babel metric 1024
default from 2001:552:6045:bd:bcd0:b46b:91ab:e613 via fe80::20d:b9ff:fe41:6c2e dev eth0 proto babel metric 1024

And go out the other, this way (except that in this case the box is deep in the network so it doesn't matter which nexthop router it uses)

default from 2601:642:4102:c5::/64 via fe80::16cc:20ff:fee5:64c2 dev eth0 proto babel metric 1024
default from 2601:642:4180:64b::/64 via fe80::20d:b9ff:fe41:6c2e dev eth0 proto babel metric 1024

For more details as to homenet, see:

https://tools.ietf.org/wg/homenet/

[jason]

Neat, I would definitely like to get homenet working on CHIP ... the right place to target this is the arch/arm/configs/multi_v7_defconfig in the CHIP-linux github repo, branch nextthing/4.4/defconfig, so that it will be in a future software release ... pull-requests are always welcome

No promises, but I will see if I can find some time soon to spin some new kernel .deb's and play with homenet a bit.

Do you have any idea if homenet ipv6 will play nicely with stock windows10 / osx and mdns?

One pain point for developers that I would love to cleanly solve is a CHIP connected to wifi and via usb gadget ethernet to a linux / windows / osx dev box and that dev box connected to the same wifi network. It would be great if the dev box could consistently resolve an ipv6 mdns name and route from dev box to CHIP as wifi or usb connectivity comes and goes.

[dtaht]

I am having great fun using the chips as a "backup" router through the usb networking
interface. It would be pretty cool to see ether + acm mode work by default.

I have it running most of the homenet stack now. I don't bridge, but route (using that) and thus I can be transparently connected to both wifi and usb networking without any issues.

one of homenet's core criterions was "no host changes". So most of if "just works" with existing standards for ipv6, mdns and so on. for hosts. As for routers, taking full advantage of it, does require a few new pieces in the stack.

One piece I don't have running as yet is the mdns hybrid stuff, which should help scale service discovery to many, many more devices than it does today.

https://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid-02

The code for it is in openwrt, haven't tried to make it play over usb p2p links.

[dtaht]

That was not the current draft of that, click for a while (this forum is not letting me put the link in). The current draft is much improved over that one....

service discovery needs a unified standard for IoT and this (IMHO) is the closest to a real standard we got.

[dtaht]

Apparently this forum considers putting in a link to an IETF draft as "spam".

reposting.

...

I am having great fun using the chips as a "backup" router through the usb networkinginterface. It would be pretty cool to see ether + acm mode work by default.

I have it running most of the homenet stack now. I don't bridge, but route (using that) and thus I can be transparently connected to both wifi and usb networking without any issues.

one of homenet's core criterions was "no host changes". So most of if "just works" with existing standards for ipv6, mdns and so on. for hosts. As for routers, taking full advantage of it, does require a few new pieces in the stack.

One piece I don't have running as yet is the mdns hybrid stuff, which should help scale service discovery to many, many more devices than it does today.

If you google for "draft-ietf-dnssd-hybrid-03" you'll find it.

The code for it is in openwrt, but "drafty", haven't tried to make it play over usb p2p links.

[fordsfords]

That is very strange.

@computermouth, any idea why the BBS wouldn't like tools dot ietf dot org?

[computermouth]

Hm, that's weird. No idea. This is all run by Discourse, it's not something that we actually host or really do much to administrate on our own. There must have been some reason to block it in the past, and it was probably added to some global whitelist.

[dtaht]

standards... who needs standards?

[zerotri]

I think it has more to do with the multiple posts from the same user referencing the same domain. It seems to trigger as suspect for spam. I wouldn't worry too much about it, it's pretty clear to us that you aren't spamming and so we can make sure your post ends up passing the filter.

[dtaht]

Neat, I would definitely like to get homenet working on CHIP ... the right place to target this is the >arch/arm/configs/multi_v7_defconfig in the CHIP-linux github repo, branch nextthing/4.4/defconfig, so that it will be in a >future software release ... pull-requests are always welcome

I am sorry but I am too heads down on some wifi fixes to touch your kernel builds as yet.

No promises, but I will see if I can find some time soon to spin some new kernel .deb's and play with homenet a bit.

I plan to take a few chips to the berlin ietf (july 17th). No pressure.

Do you have any idea if homenet ipv6 will play nicely with stock windows10 / osx and mdns?

Well, homenet's mantra was "no host changes", only stuff for routers. So most of the new stuff is transparent to hosts.

Except in this odd case, where you kind of want the chip to be a usb to wifi router, or at least, sanely be present on both interfaces. And you want service discovery to work right.

On linux to chip to linux I have the homenet stack working fine. I will document that over the coming weeks. I will give OSX a shot too. Nobody, so far as I know, has ported any of core components of homenet to windows.

One pain point for developers that I would love to cleanly solve is a CHIP connected to wifi and via usb gadget ethernet to a linux / windows / osx dev box and that dev box connected to the same wifi network.

I see in the latest 4.4 release, you've tried that and it's causing some pain. I have been using the g_ether device with great success for weeks now, and I agree that the combined ether/serial device would be better, and I'm sorry for your pain and hope it sorts out.

It would be great if the dev box could consistently resolve an ipv6 mdns name and route from dev box to CHIP as wifi or usb connectivity comes and goes.

Sigh. Everybody wants mdns to do things it does not do well. Multicast across two different link layers is one of them.

I have not yet poked into the state of the unicast mdns-proxy work that was also going on as part of homenet. I'll try.

Me, what I do, is run babeld universally, and assign a local static ipv6 address to everything that can get routed any which way by the babel protocol - usb if it's up, wifi if it isn't. It's easy to remember that chipzilla is fd99::25..

I will write this stuff up, as well as the hncp address assignment methods, before mid-july. Please poke me if/when the IPV6_SUBTRESS stuff enters a build.