[mesh-dev] Notes on babel and bmx6

Marc Juul juul at labitat.dk
Mon Jan 12 21:22:56 PST 2015


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

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sudoroom.org/lists/private/mesh-dev/attachments/20150112/4c2988fa/attachment.html>


More information about the mesh-dev mailing list