On Mon, Jan 12, 2015 at 8:46 PM, Alexander Papazoglou <papazoga@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