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

[max b]

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. 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....

I personally am not sold on removing bridging just yet. Maybe the
compromise is that we just do bridging for any devices that don't support
openwrt/babeld (Ubiquiti AC gear, airfibers, etc).



On Fri, Jun 26, 2015 at 8:10 AM, Marc Juul <juul at labitat.dk> wrote:

>
>
> On Wed, Jun 24, 2015 at 9:34 PM, max b <maxb.personal at gmail.com> wrote:
>
>> Just a thought - what exactly does using adhoc buy us here? I imagine
>> that our extender nodes will likely be either pt->pt or pt->multipoint,
>> each of which would be supported by an AP->Station mode. I guess that it
>> might be slightly more convenient to just throw extender nodes into adhoc
>> and not worry about them, but generally we'll have to select channels
>> anyhow, so is it much harder just to choose station or AP mode?
>>
>> If we were to abandon adhoc mode, can we use WDS in order to bridge
>> extender nodes?
>>
>
> Abandoning adhoc sounds like a pain, but according to Adrian we can
> actually use four-address mode even on adhoc with the mac80211 driver.
>
> The trade-off is that only devices with atheros chipsets would be able to
> connect to the mesh. This, to me, is not a good trade-off. I went ahead and
> implemented a solution with babeld running on the extender nodes.
>
> If we get to a point where our routing tables or babeld traffic is getting
> to be too much then that is a good day and we'll have a large mesh with
> enough resources to throw at this problem.
>
> --
> marc/juul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sudoroom.org/lists/private/mesh-dev/attachments/20150627/f480ac77/attachment.html>