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

On Sat, Jun 27, 2015 at 3:08 AM, max b <maxb.personal(a)gmail.com> wrote: Even if they weren't running babeld, why not do this? They still need an IP either way. 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