[mesh-dev] Multicast forwarding for layer 3 pseudo-bridges

[Marc Juul]

On Sat, Jun 27, 2015 at 3:08 AM, max b <maxb.personal at gmail.com> wrote:

> Ok so the one thing is that if we're actually running babeld on the
> extender nodes, we might want to reconsider our topology/configuration just
> a touch now that we have slightly more options.
>
> For example, if the extender nodes are running babeld, why not just assign
> them an arbitrary /32 in the same manner as the home nodes.
>

Even if they weren't running babeld, why not do this? They still need an IP
either way.


> All the extender nodes could count down from the top of the IP space or
> something. Then we would need a lot less of the notdhcp fanciness - just
> plug any extender node into any mesh home node and it won't matter at all
> whether they're on the same subnet or not because we're doing routing! Of
> course that doesn't really address the UI stuff we had talked about, but
> some fairly simple port forwarding would allow users to get to the web UI
> and ssh port of the extender nodes without too much trouble I think....
>

The extender nodes will still need to exchange security information with
the home nodes on connect (otherwise how do they only allow their home node
to manage them via web UI?) so they will still need notdhcp. If we assign
them /32 at birth then we are adding the need to configure (with makenode)
all extender nodes, and the gain is that we will then not use a notdhcp
feature which is already implemented and functioning, but we don't get to
drop notdhcp completely.

I personally am not sold on removing bridging just yet.
>

We're still bridging the open (peoplesopen.net) network (and the private
network if we decide to extend it). Adrian says that there is a way to
enable 4-address mode for adhoc but he did not know how to do so. I'm
dubious that it can be made to work without kernel patching (currently the
kernel disallows adding adhoc-mode interfaces to a bridge). We could use
WDS instead of adhoc-4-address, but then we loose flexibility because now
one device must be the ap and the other devices must be clients. Deciding
which are which will have to be configured manually and clients that can
both see an ap (and maybe not the same ap) but can also see each other
would not be able to communicate. Even if we could get adhoc-4-address mode
working or we decided to go with WDS then we'd still be dropping support
for any non-atheros chipsets (and I am not sure if that includes the older
atheros chipsets in previous generation ubiquiti gear).

If we run babeld on the extender nodes then the only disadvantage is an
increase in routing table size and babeld traffic. This might come back to
haunt us later, but the network size we'd need for this to be a problem
means we've been successful and I'm comfortable letting our future
successful selves deal with that issue.

Dropping support for non-atheros chipsets is makes me a bit uncomfortable.
I had some vague idea that our mesh might integrate well with byzantium and
that anyone running linux would be able to run a little script and become a
mesh node, which would add some fun/cool factor for local hackers with an
interest in the mesh but also make it easy to improvise mesh nodes out of
e.g. raspberry pi's or whatever people have lying around. Being
vendor-locked also might have repercussions in the future since we can't
expect to rely on a single chipset for all eternity, especially since
Qualcomm now owns Atheros.


> Maybe the compromise is that we just do bridging for any devices that
> don't support openwrt/babeld (Ubiquiti AC gear, airfibers, etc).
>

Yes, probably we'd have to use WDS bridging mode for non-openwrt routers. I
can't actually think of any other way babeld could work over a non-openwrt
router link, except for tunneling which would be horrible.

The non-openwrt extender nodes will be limited to extending a single
network at a time: mesh, open or private. I expect we'll mostly use them
for high speed point to point links, but really any old non-openwrt home
router could be an extender node if configured correctly, though maybe we
shouldn't encourage that as I'm not sure if we really want some old belkin
piece of shit router broadcasting the peoplesopen.net ssid. Some of those
things need rebooting like once a week. Give us a bad rep it will.

-- 
marc/juul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sudoroom.org/lists/private/mesh-dev/attachments/20150629/12d32087/attachment.html>