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.