26 Jun
2015
26 Jun
'15
3:39 p.m.
On Fri, Jun 26, 2015 at 8:01 AM, Marc Juul <juul(a)labitat.dk> wrote:
I agree. I see now that running babeld is the best solution. I was trying to
Heh.
What are you doing is exchanging one set of problems for another. As much
as I personally like babel (for a variety of reasons, many outlined here:
https://tools.ietf.org/html/draft-chroboczek-babel-doesnt-care-00
And the privacy enhancing aspects of DV protocols...
)
olsr is more common and has more tools for it. olsrv2 is also looking good.
I long ago ruled out batman for the layer 2 dependencies (where I see a world
with many different radio types, like 802.11, 802.14, 802.11ad, bluetooth,
and all needing to interop with ethernet, fiber, koruza, blinking
LEDS, and smoke signals)
most IETFers are hot on link state protocols like ISIS and ospf which have thus
far proven incapable of meshy operation...
And I gotta admit, I do sometimes miss having extra information carried in the
protocol. Lat/long would help. I long ago "misplaced" a couple radios that are
somewhere on the property. I can get to them via ssh but I have no idea
where they are, physically. And so on.
On Wed, Jun 24, 2015 at 9:55 AM, Dave Taht <dave.taht(a)gmail.com> wrote:
It had seen no love from 2011... to 2014. I see it just got some.
Good. Maybe it will compile with musl.
On Wed, Jun 24, 2015 at 4:07 AM, Marc Juul <juul(a)labitat.dk> wrote:
Well that sucks but good to know. It looks like it have an active maintainer
though?
https://github.com/troglobit/pimd # The problem
Our extender-nodes can't bridge their adhoc wifi interface to their
ethernet
interface since bridging adhoc is not possible. A layer 3 pseudo-bridge
using relayd should work but both Babel and mDNS rely on multicast which
is
not handled by relayd.
# Solutions
It looks like we have two options:
1. Forward both babel and mDNS IPv4 and IPv6 multicast messages between
interfaces selectively based on the multicast addresses of these
protocols
2. Have extender-nodes forward / route multicast traffic in general
(pimd/pim6sd).
pimd is horribly ill-maintained. I have not seen it work right in many
cases.
Running babeld is a solution, but not ideal since it makes Babel deal
with
extender-nodes as real nodes, adding more signalling traffic to the
network
which should be unnecessary and complicates our network graphs.
The signalling traffic is trivial. (especially compared to bridging
multicast????)
The complications are possibly beneficial. I have gone through hell
finding weird
bridged networks in the path. make a router act like basically an extra radio for
another router and got
hung up on having it be a dumb bridge when it was looking more complicated
than just running babeld.
Interesting. Seems a bit more centralized than what we're looking for but
will have a look at the code.
Good to know!
Aw dang. Thanks for saving us from learning the hard way. I guess we'll look
at mdns-repeater and maybe modifying it to prevent packet storms. Definitely
pushing this issue to a later version then.
But we must dream of a better future! :) We'll have to revisit this next
year then.
Thank you for the insightful feedback!
--
marc/juul
--
Dave Täht
worldwide bufferbloat report:
http://www.dslreports.com/speedtest/results/bufferbloat
And:
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast
## Selective multicast routing/forwarding
mDNS has existing solutions available, such as:
* avahi with enable-reflector option (kinda bulky)
* mdns-repeater (no openwrt package exists)
The in-progress solution to unicast mdns discovery is the mdns hybrid
proxy work spearheaded by stuart chesire at the ietf.
https://tools.ietf.org/html/draft-cheshire-dnssd-hybrid-01
Code: https://github.com/sbyx/ohybridproxy I have pimd in ceropackages. Does not work well.
quagga had pim support enter it recently. That codebase looked promising.
Interesting.
If we wanted to avoid pimd, then we could disable
mDNS on IPv4, which
shouldn't present a problem since all mesh-connected devices will have
IPv6
addresses anyway, but it's probably unlikely that babeld can function on
both IPv4 and IPv6 without IPv4 multicast (unless we change a bunch of
code). Totally worth checking if it already has that ability though,
since
avoiding IPv4 multicast would be a bonus.
Babel does not use ipv4 at all. All multicast is ipv6. Babel can carry
both ipv4 and ipv6 in it´s ipv6 packets.
Babel when using source specific routing and falls back to multiple
ipv6 routing tables when ipv6_subtrees is not available. ipv6_subtrees
is enabled by default in BB and later.
You are answering all my questions!
# Conclusion
I propose that we run babeld on the extender nodes and use avahi as a
reflector for now. We can then revisit this for e.g. version 0.4.
What do you all say?
I shipped avahi as a reflector in cerowrt. It caused broadcast storms
with more than three nodes interconnected. It also went nuts when a
device was on more than one subnet and announced itself, doing things
like renumbering nodea-1 to nodea-2,3,4,5,6 (I dont think avahi is RFC
compliant here)
You are SOL. Based on this preliminary research it looks like
the long-term solution
involving the smallest amount of work is probably running pim6sd and
pimd.
This is gratifying since it would be really cool to have a mesh that
does
real actual multicast routing.
I would like pimd to work well also. However the code path in the
kernel is underutilized, horribly undertested, and I think you are
dreaming.