On Sat, Jun 27, 2015 at 3:08 AM, max b <maxb.personal@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