11 Jan
2015
11 Jan
'15
3:52 p.m.
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/
The IPs and subnets are statically configured in openwrt config for each
node just like they are in the old sudomesh firmware, and each node assigns
IPv4 and IPv6 addresses to clients using dhcp. All nodes have their own
subnets and run dhcp servers (as opposed to the old firmware where only
internet-connected nodes ran dhcp).
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
To begin with we can base the metric on something like the average of the
upload and download bandwidth limit on the node maybe? I'm not exactly sure
how this metric stuff works for these manual route announcements. I assume
the specified metric is the base metric and then normal babel metric
calculations happen on top of that?
In the longer term we could create a babel extension that attaches
information to route announcements about delay to the vpn server and
currently available internet/tunnel bandwidth (averaged since last router
announce). We can see how the babel diversity routing extension is
implemented and base it on that:
https://tools.ietf.org/html/draft-chroboczek-babel-diversity-routing-00
I'm not sure how we'll measure available bandwidth on a live connection
without saturating it? Maybe we can instead measure whether the bandwidth
is currently saturated by looking at how many packets are getting
queued/dropped? We can also do something even simpler and look at current
bandwidth usage vs. the user-selected bandwidth limit. If we do this then
for nodes with no bandwidth limit, we'd have to measure the available
bandwidth e.g. the first time the node finds an internet connection. We
could just skip this feature in the first firmware version and require a
user-selected bandwidth limit, but then we run the risk of the user
selecting a limit that's higher than their available connection speed.
In the future we can also replace tunneldigger with something using
foo-over-udp, but I think tunneldiggger with the "only try to connect when
a ping succeeds"-addition is good enough for now.
I must say that the more I look at it the more I'm liking babel. It seems
to me that bmx6 has several oddities:
* Can't do IPv4 and IPv6 at the same time.
* Can't have several nodes announcing the same route (e.g. to internet)
* Instead uses tunnel announcements for internet gateway selection, even
though this adds the extra overhead of having a tunnel from each
non-internet-connected node to a internet-connected node for no apparent
reason. The overhead might no be bad but the plurality of tunnel interfaces
makes debugging kinda confusing and it just seems... dirty.
* The weirdness with different nodes ending up on different IPv6 subnet.
Are there any advantages to using bmx6? The only one I can think of right
now is that it already has some internet bandwidth metric stuff
implemented, but on the other hand babel has its diversity routing metric
which is probably going to be important for us in the future if we don't
want to loose a lot of bandwidth on multi-hop routes.
Does babel have any problems I haven't considered?
Thoughts? Comments? Anything I overlooked?
--
marc/juul
11 Jan
11 Jan
11:32 p.m.
I've been having similar thoughts about this. I agree that bmx6 has seemed
awkward and cumbersome. Especially the bit about creating all of the
differently and seemingly arbitrary named interfaces. Also the IPv6 subnet
issue which I never was able to really sort out and which we never got a
good answer back from Nuemann about.
I've been tinkering with babel and I've actually branched several of our
repos into babel offshoots: makenode, sudowrt-firmware, exitnode. They
should all have some sort of maxb/babel or maxb/barrier-babel branch which
has been my starting point for work on babel. It's certainly not finished
and I don't even know that they all work together yet, but in case someone
wants to take a look through it, it's been my thinking so far.
I also built a firmware image, but for some reason it only built squashfs
and not jffs2. I can upload it to Deeko's hosting when I find my FTP keys
for his server.
On Sun, Jan 11, 2015 at 3:52 PM, Marc Juul <juul(a)labitat.dk> wrote:
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/
The IPs and subnets are statically configured in openwrt config for each
node just like they are in the old sudomesh firmware, and each node assigns
IPv4 and IPv6 addresses to clients using dhcp. All nodes have their own
subnets and run dhcp servers (as opposed to the old firmware where only
internet-connected nodes ran dhcp).
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
To begin with we can base the metric on something like the average of the
upload and download bandwidth limit on the node maybe? I'm not exactly sure
how this metric stuff works for these manual route announcements. I assume
the specified metric is the base metric and then normal babel metric
calculations happen on top of that?
In the longer term we could create a babel extension that attaches
information to route announcements about delay to the vpn server and
currently available internet/tunnel bandwidth (averaged since last router
announce). We can see how the babel diversity routing extension is
implemented and base it on that:
https://tools.ietf.org/html/draft-chroboczek-babel-diversity-routing-00
I'm not sure how we'll measure available bandwidth on a live connection
without saturating it? Maybe we can instead measure whether the bandwidth
is currently saturated by looking at how many packets are getting
queued/dropped? We can also do something even simpler and look at current
bandwidth usage vs. the user-selected bandwidth limit. If we do this then
for nodes with no bandwidth limit, we'd have to measure the available
bandwidth e.g. the first time the node finds an internet connection. We
could just skip this feature in the first firmware version and require a
user-selected bandwidth limit, but then we run the risk of the user
selecting a limit that's higher than their available connection speed.
In the future we can also replace tunneldigger with something using
foo-over-udp, but I think tunneldiggger with the "only try to connect when
a ping succeeds"-addition is good enough for now.
I must say that the more I look at it the more I'm liking babel. It seems
to me that bmx6 has several oddities:
* Can't do IPv4 and IPv6 at the same time.
* Can't have several nodes announcing the same route (e.g. to internet)
* Instead uses tunnel announcements for internet gateway selection, even
though this adds the extra overhead of having a tunnel from each
non-internet-connected node to a internet-connected node for no apparent
reason. The overhead might no be bad but the plurality of tunnel interfaces
makes debugging kinda confusing and it just seems... dirty.
* The weirdness with different nodes ending up on different IPv6 subnet.
Are there any advantages to using bmx6? The only one I can think of right
now is that it already has some internet bandwidth metric stuff
implemented, but on the other hand babel has its diversity routing metric
which is probably going to be important for us in the future if we don't
want to loose a lot of bandwidth on multi-hop routes.
Does babel have any problems I haven't considered?
Thoughts? Comments? Anything I overlooked?
--
marc/juul
_______________________________________________
mesh-dev mailing list
mesh-dev(a)lists.sudoroom.org
https://lists.sudoroom.org/listinfo/mesh-dev
12 Jan
12 Jan
8:46 p.m.
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.
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?
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.
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.
Alex
8:57 p.m.
Just one clarification: You can't actually manage/log on to the mesh node
admin UI from the mesh interface (or you shouldn't currently be able to).
We decided to only be able to do it from the private WPA protected network
because it's currently over HTTP and so this would give us a level of
encryption for the admin UI.
On Mon, Jan 12, 2015 at 8:46 PM, Alexander Papazoglou <papazoga(a)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.
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?
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.
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.
Alex
_______________________________________________
mesh-dev mailing list
mesh-dev(a)lists.sudoroom.org
https://lists.sudoroom.org/listinfo/mesh-dev
9:22 p.m.
On Mon, Jan 12, 2015 at 8:46 PM, Alexander Papazoglou <papazoga(a)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.
That would be a real pain.
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.
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
Right.
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?
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
11:03 p.m.
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(a)labitat.dk> wrote:
On Mon, Jan 12, 2015 at 8:46 PM, Alexander Papazoglou <papazoga(a)gmail.com>
wrote:
_______________________________________________
mesh-dev mailing list
mesh-dev(a)lists.sudoroom.org
https://lists.sudoroom.org/listinfo/mesh-dev
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.
That would be a real pain.
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.
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
Right.
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?
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
10:42 p.m.
New subject: In defense of the private SSID
On Mon, Jan 12, 2015 at 08:46:52PM -0800, Alexander Papazoglou wrote:
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.
Strategy Analytics suggests around 35% (worldwide, fixed-line broadband only)
don't have wireless routers at home.
http://www.strategyanalytics.com/default.aspx?mod=reportabstractviewer&…
IMO, the private SSID is a pretty key feature. A replacement AP that also
shares your bandwidth with the neighbours and might give you emergency
internet access when your DSL is down is a cool thing. An EXTRA AP that
only the neighbours use is going to wind up being left unplugged (or not
power cycled should it crash) and only get brought back up when your DSL
goes down.
2. Yet another subnet must be reserved (albeit not
globally).
3. DHCP must be done.
4. NAT must be performed for the subnet.
How much extra burden are these actually?
I have the impression that it's
negligible.
5. More radio bandwidth will be used on the same
channel as the mesh.
I don't think that's a major issue - if the typical
person's internet usage
is enough to severely degrade a node, then we probably have to abandon wifi
meshing entirely - at least in densely populated areas. The edge cases who
do use enough bandwidth to clobber a node can fall back to using multiple APs
on multiple channels, or wired links. (If I'm regularly saturating 11Mbps I
probably will be happier on 100baseT anyhow!)
3601
days inactive
3603
days old
6 comments
5 participants
participants (5)
-
Alexander Papazoglou -
Chris Jefferies -
Deekoo -
Marc Juul -
max b