[mesh-dev] Notes on babel and bmx6

[Chris Jefferies]

I know babel seems the way but I just saw this distro for Raspberry Pi that
includes BATMAN advanced...
http://subnod.es/





--
Chris Jefferies
(510) 409-0003 - mobile


On Mon, Jan 12, 2015 at 9:22 PM, Marc Juul <juul at labitat.dk> wrote:

>
>
> On Mon, Jan 12, 2015 at 8:46 PM, Alexander Papazoglou <papazoga at gmail.com>
> wrote:
>
>> Marc,
>>
>> My notes on your notes on firmware/babel. Interspersed amongst yours:
>>
>> After playing with bmx6 for a while I thought I'd look more into babel.
>>> I've been trying to figure out what we'd need in order to use babel for the
>>> firmware. Here are my thoughts:
>>>
>>> Each node has an IPv4 subnet and an IPv6 subnet.
>>>
>>> The IPv4 subnet is assigned using makenode.
>>>
>>> The IPv6 subnet is assigned using makenode, randomly using
>>>
>>>   generate-ipv6-address from
>>> http://www.pps.univ-paris-diderot.fr/~jch/software/files/
>>>
>>>
>> I believe you will need a /32 address configured for the mesh interface,
>> in addition to the subnet on which the 'public' interface will be
>> configured, and I'm fairly sure these must be disjoint. e.g. the mesh
>> address cannot be on the subnet it serves to clients. I would like to
>> be wrong about this.
>>
>
> That would be a real pain.
>
>
>>
>> Both the /32 and the subnet must be advertised by Babel. Same for IPv6
>> (with a bigger number after the slash, of course).
>>
>> If tunneldigger succeeds in establishing a tunnel, the node becomes an
>>> internet gateway and announces its route to the internet using:
>>>
>>>   babeld -C 'redistribute if eth0 metric 128' mesh0
>>>
>>
>> I think you mean 'tun0' (or whatever tunnel name we choose), right?
>>
>
> Right.
>
>
>> This will hopefully only need to be done at boot. As of Babel 0.8 the
>> daemon (it is claimed) monitors the interface for up/down events.
>>
>
> Nice!
>
>
>> A slightly off-topic question to ponder: Is it worth the overhead to
>> offer a 'private' wifi
>> interface, as in the current firmware? For those not familiar with this,
>> the firmware currently
>> advertises a 'private' WPA2-secured SSID which the owner of the node can
>> use as
>> their personal access point; it routes directly to the internet via their
>> connection without
>> going through the exit node. It also serves as a management interface.
>>
>> My thoughts are that:
>>
>>  1. There are not that many people with Internet access at home and no AP.
>>  2. Yet another subnet must be reserved (albeit not globally).
>>  3. DHCP must be done.
>>  4. NAT must be performed for the subnet.
>>  5. More radio bandwidth will be used on the same channel as the mesh.
>>  6. One can manage/log on to the mesh node from the mesh interface anyway.
>>
>>
> Other than "it's nice to have" there is only one other reason I can think
> of to keep it. It's currently used when accessing the web admin interface
> to change settings in a more secure fashion. We could keep it around
> without the NAT for only that reason. Otherwise we have to figure out
> another way. If we put the web admin on the peoplesopen.net ssid then we
> have two additional concerns:
>
>   1. Security: We'd probably need SSL and that means self-signed cert and
> that means an ugly warning.
>   2. Hostname: W are using my.node (or something like that) to point to
> the node to which you are currently connected. When getting rid of the
> private ssid, the potential worry here would be that your neighbor has a
> node with a more powerful signal, which means that my.node takes you to
> their node, and then you'd never be able to access your own node's web
> admin.
>
> Thoughts?
>
> --
> marc/juul
>
>>
>>
>
> _______________________________________________
> mesh-dev mailing list
> mesh-dev at lists.sudoroom.org
> https://lists.sudoroom.org/listinfo/mesh-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sudoroom.org/lists/private/mesh-dev/attachments/20150112/ca47dbaa/attachment.html>