[B.A.T.M.A.N.] Battlemesh-like experiment in Washington, DC

[B.A.T.M.A.N.] Battlemesh-like experiment in Washington, DC

[Juliusz Chroboczek]

Hi,

It looks like the folks at HacDC, a hackerspace in Washington, DC, have
done their own battlemesh:

  http://drwho.virtadpt.net/archive/2011/03/15/project-byzantium-sprint-1
  http://drwho.virtadpt.net/archive/2011/04/14/project-byzantium-development-sprint-2

They've got a few minor misunderstandings (for example, they're trying
to get ordinary DHCP to work over a mesh), but they've managed to get
both Babel and BATMAN-Adv to work with no help from us -- well done.

-- Juliusz

Re: [B.A.T.M.A.N.] Battlemesh-like experiment in Washington, DC

[Marek Lindner]

Hi,

> It looks like the folks at HacDC, a hackerspace in Washington, DC, have
> done their own battlemesh:
> 
>   http://drwho.virtadpt.net/archive/2011/03/15/project-byzantium-sprint-1
>   http://drwho.virtadpt.net/archive/2011/04/14/project-byzantium-developmen
> t-sprint-2

thanks for sharing this with us!


> They've got a few minor misunderstandings (for example, they're trying
> to get ordinary DHCP to work over a mesh), 

I fail to see the misunderstanding - just because DHCP does not work with 
$your_protocol does not mean it never works. DHCP is the recommended IP 
configuration tool in a batman-adv mesh network.


Regards,
Marek

Re: [B.A.T.M.A.N.] Battlemesh-like experiment in Washington, DC

[The Doctor]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/16/2011 11:34 AM, Marek Lindner wrote:

> I fail to see the misunderstanding - just because DHCP does not work with 
> $your_protocol does not mean it never works. DHCP is the recommended IP 
> configuration tool in a batman-adv mesh network.

We found that DHCP works well to configure clients of the mesh, but a
possible problem of using it to configure other mesh nodes is too many
nodes running DHCP servers and potentially handing out conflicting
information.  For mesh /nodes/ we have two options on the table: AHCP
(every node will come with ahcpd pre-installed but not running) and
generating pseudo-random RFC 1918 addresses for the network interfaces
done by the control panel, and working fairly well at this early date).

- -- 

The Doctor [412/724/301/703]

PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F  DD89 3BD8 FF2B 807B 17C1
WWW: http://drwho.virtadpt.net/

"My mom thinks I'm cool..." --Milhouse

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4kcD0ACgkQO9j/K4B7F8HXGACfeNTfdZKPhp081ISOtR47/y6O
ZCYAoMI9iCw+lt95hVGI5zIqg4aTVFuC
=IMrn
-----END PGP SIGNATURE-----

Re: [B.A.T.M.A.N.] Battlemesh-like experiment in Washington, DC

[The Doctor]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/16/2011 09:42 AM, Juliusz Chroboczek wrote:

> They've got a few minor misunderstandings (for example, they're trying
> to get ordinary DHCP to work over a mesh), but they've managed to get
> both Babel and BATMAN-Adv to work with no help from us -- well done.

We actually did get DHCP working over our meshes as a proof of concept -
it works pretty well.  We're probably going to use DHCP to configure
clients that first associate with each mesh node (we can't install AHCP
clients on every wireless devices that happens by; besides, they support
DHCP by default).  Byzantium nodes themselves give their wireless
interfaces pseudo-randomly chosen RFC-1918 IP addresses when they're
brought online.

- -- 

The Doctor [412/724/301/703]

PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F  DD89 3BD8 FF2B 807B 17C1
WWW: http://drwho.virtadpt.net/

"Here sharky!  Here!  Here, boy!"  --Anthony Bourdain

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4nD3IACgkQO9j/K4B7F8GTNACbBzdExuJhnYOemgWMmlVAmirG
qgMAoJocq+kdlaYH4+fGRj9rzxROT99O
=pbuK
-----END PGP SIGNATURE-----

Re: [B.A.T.M.A.N.] Battlemesh-like experiment in Washington, DC

[Juliusz Chroboczek]

>> They've got a few minor misunderstandings (for example, they're trying
>> to get ordinary DHCP to work over a mesh),

> We actually did get DHCP working over our meshes as a proof of concept -
> it works pretty well.

So are you running a DHCP forwarder on every node?  (Or are you working
with a layer-2 mesh, which is what Marek was alluding to?)

-- Juliusz

Re: [B.A.T.M.A.N.] Battlemesh-like experiment in Washington, DC

[The Doctor]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/20/2011 02:55 PM, Juliusz Chroboczek wrote:

> So are you running a DHCP forwarder on every node?  (Or are you working
> with a layer-2 mesh, which is what Marek was alluding to?)

Not on every node.  For the purposes of our experiment, we were
configuring clients associated with a couple of nodes.  We were working
with a layer-2 mesh at the time.

By the way, should this particular thread really be going to the
babel-users list?  If we're talking layer-2 we're talking BATMAN-adv,
which is out of scope for that discussion list.

- -- 

The Doctor [412/724/301/703]

PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F  DD89 3BD8 FF2B 807B 17C1
WWW: http://drwho.virtadpt.net/

Your memories are fiction.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4oOSsACgkQO9j/K4B7F8FVGACdGnRiT3dVsZ24AtFd3BBohTFK
X5MAn0sqC/KbEqkbcqoX6wg/GAAmA9R/
=f5Jn
-----END PGP SIGNATURE-----

Re: [B.A.T.M.A.N.] Battlemesh-like experiment in Washington, DC

[Juliusz Chroboczek]

>> So are you running a DHCP forwarder on every node?  (Or are you working
>> with a layer-2 mesh, which is what Marek was alluding to?)

> Not on every node.  [...] We were working with a layer-2 mesh at the
> time.

Oh yeah, there should be no problem in a layer 2 mesh, if the mesh
implements broadcast (or hacks in some ad hoc smarts related to DHCP).
AHCP is only needed in a layer 3 mesh.

> By the way, should this particular thread really be going to the
> babel-users list?  If we're talking layer-2 we're talking BATMAN-adv,
> which is out of scope for that discussion list.

I don't think it is too outrageously off-topic.  If the respectable
recipients of this list object, we'll move to a more suitable forum.
(There's unfortunately no suitable forum for protocol-agnostic
discussions about mesh routing.)

-- Juliusz

Re: [B.A.T.M.A.N.] Battlemesh-like experiment in Washington, DC

[The Doctor]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/21/2011 12:20 PM, Juliusz Chroboczek wrote:

I am sorry this reply has been so delayed, work has been rough lately.

> Oh yeah, there should be no problem in a layer 2 mesh, if the mesh
> implements broadcast (or hacks in some ad hoc smarts related to DHCP).
> AHCP is only needed in a layer 3 mesh.

We also have a solution worked out for layer 3 meshes.  We will be using
DHCP to configure clients, and our control panel application can
pseudo-randomly choose RFC-1918 IP addresses for mesh interfaces if the
user selects it.  AHCP is still an option for configuring other mesh
nodes, we have not yet implemented that.

- -- 

The Doctor [412/724/301/703]

PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F  DD89 3BD8 FF2B 807B 17C1
WWW: http://drwho.virtadpt.net/

"Take back, take back, take back the dancefloor!"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5AM2cACgkQO9j/K4B7F8ERngCePSd8L2smWq5phMwX3ryy8ZFV
j9AAnjcCwcJuq+kcfOlyb8caXYLlUupn
=/kkF
-----END PGP SIGNATURE-----

Re: [B.A.T.M.A.N.] [Battlemesh] Battlemesh-like experiment in Washington, DC

[Mitar]

Hi!

> and our control panel application

What do you use for your control panel application?

> can pseudo-randomly choose RFC-1918 IP addresses for mesh interfaces
> if the user selects it.

You do know birthday paradox? ;-)

https://secure.wikimedia.org/wikipedia/en/wiki/Birthday_problem


Mitar

Re: [B.A.T.M.A.N.] [Battlemesh] Battlemesh-like experiment in Washington, DC

[The Doctor]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/09/2011 07:35 AM, Mitar wrote:

>> and our control panel application
> What do you use for your control panel application?

We're writing a custom control panel in Python, using CherryPy for the
web server and Mako for the templating system.

> You do know birthday paradox? ;-)
> https://secure.wikimedia.org/wikipedia/en/wiki/Birthday_problem

I am aware that this is a possibility, yes.  However, it is my hope that
by providing a large enough address space (17,891,328) we can minimize
the number of IP address collisions in a given mesh.  If need be, we can
always try a different approach.

- -- 

The Doctor [412/724/301/703]

PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F  DD89 3BD8 FF2B 807B 17C1
WWW: http://drwho.virtadpt.net/

WWPMD? (What Would Paul Muad'dib Do?)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5BZYQACgkQO9j/K4B7F8HhUgCcD/nmVvHv0+YAZiJDu4EaLNOH
zq8AoL57bSA+0PJQ0zf3ps1qcONji4cj
=xIAF
-----END PGP SIGNATURE-----

Re: [B.A.T.M.A.N.] [Battlemesh] Battlemesh-like experiment in Washington, DC

[Juliusz Chroboczek]

>>> and our control panel application

>> What do you use for your control panel application?

> We're writing a custom control panel in Python, using CherryPy for the
> web server and Mako for the templating system.

Is that available yet?

-- Juliusz

Re: [B.A.T.M.A.N.] [Battlemesh] Battlemesh-like experiment in Washington, DC

[Mitar]

Hi!

> We're writing a custom control panel in Python, using CherryPy for the
> web server and Mako for the templating system.

What exactly is this control panel? What do you understand under this
term? It is something running on the node? Or on the server?

Is there some webpage with more about that?

> However, it is my hope that by providing a large enough address space
> (17,891,328) we can minimize the number of IP address collisions in a
> given mesh.  If need be, we can always try a different approach.

You are talking about IPv6 or IPv4 here?In IPv4 some MAC address + IPv6
prefix could be enough.

In IPv4 is problem, that if you will take big address space you will
have problems peering with other mesh networks. If this will be one day
interesting to you. (At least in Europe we are slowly trying to connect
all networks together.)


Mitar

Re: [B.A.T.M.A.N.] [Battlemesh] Battlemesh-like experiment in Washington, DC

[The Doctor]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/09/2011 04:13 PM, Juliusz Chroboczek wrote:

>> We're writing a custom control panel in Python, using CherryPy for the
>> web server and Mako for the templating system.
> 
> Is that available yet?

Not yet, but here is a link to the Git repository:

https://github.com/Sitwon/Byzantium/tree/master/control_panel

- -- 

The Doctor [412/724/301/703]

PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F  DD89 3BD8 FF2B 807B 17C1
WWW: http://drwho.virtadpt.net/

"And the flowers are still standing!" --Peter Venkman, _Ghostbusters_

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5CsmQACgkQO9j/K4B7F8Hq5ACgvHNNTiK5kfJL17Dn0wCLCgCN
xYAAn0g8BQS5gO1KlZKr15+7X9EqzZVc
=jBHn
-----END PGP SIGNATURE-----

Re: [B.A.T.M.A.N.] [Battlemesh] Battlemesh-like experiment in Washington, DC

[The Doctor]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/09/2011 05:04 PM, Mitar wrote:

> What exactly is this control panel? What do you understand under this
> term? It is something running on the node? Or on the server?

The Byzantium control panel is an application which allows the user to
(de)configure network interfaces, add or remove them from a mesh, and
enable or disable services and web applications running on a node.  It
runs on a node (listening only on the loopback interface) and is
accessed with any web browser.  Technically, it is a web application,
but seeing as how Byzantium will package a couple of web applications
for public use on a mesh anyway (Etherpad-lite, crypto.cat, status.net,
and a few others) it made more sense to call it a control panel.

> Is there some webpage with more about that?

http://wiki.hacdc.org/index.php/Byzantium
http://wiki.hacdc.org/index.php/Byzantium_Live_Distro (developer info)

> You are talking about IPv6 or IPv4 here?In IPv4 some MAC address + IPv6
> prefix could be enough.

IPv4.  We considered IPv6, and in fact we get it for free with the Linux
kernel, but not all applications are aware of or play nicely with it.

> In IPv4 is problem, that if you will take big address space you will
> have problems peering with other mesh networks. If this will be one day
> interesting to you. (At least in Europe we are slowly trying to connect
> all networks together.)

This is an interesting problem to us, and one of the things we have in
mind once Byzantium is stable is correcting problems with
interoperability.  In the States right now, mesh networking is not
really a popular technology; hopefully Byzantium will drum up more
interest over here (and open a meaningful dialogue with the "Mesh
networking sucks, why don't you just give up?" critics).

- -- 

The Doctor [412/724/301/703]

PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F  DD89 3BD8 FF2B 807B 17C1
WWW: http://drwho.virtadpt.net/

"And the flowers are still standing!" --Peter Venkman, _Ghostbusters_

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5CtBEACgkQO9j/K4B7F8FmpgCfdZZDeTtPuSxFgIgNYJuDwNZS
/2cAoOH7dDvsRrscwiuGvL+FTZ2C7ius
=pE6H
-----END PGP SIGNATURE-----

Re: [B.A.T.M.A.N.] [Battlemesh] Battlemesh-like experiment in Washington, DC

[Mitar]

Hi!

> The Byzantium control panel is an application which allows the user to
> (de)configure network interfaces, add or remove them from a mesh, and
> enable or disable services and web applications running on a node.  It
> runs on a node (listening only on the loopback interface) and is
> accessed with any web browser.  Technically, it is a web application,
> but seeing as how Byzantium will package a couple of web applications
> for public use on a mesh anyway (Etherpad-lite, crypto.cat, status.net,
> and a few others) it made more sense to call it a control panel.

Interesting. Just as an information, in our network (wlan slovenia) we
have taken directly the opposite approach and made a centralized system
for deploying nodes (centralized in the sense it is one of the services
of the network, but the network itself still runs operates if this
service is removed from operation, this server/system/service only
streamlines node deployment (and prevents IP collisions so that it
maintains ). The point we have seen is that web interface on the node
takes simply too much time to maintain once you have many nodes which
you want to configure the same (and update configuration and so on). It
takes time to click all those things. And that it is still too technical
for common people to use.

So we have taken completely other approach: nodes without any web
interface, where you have a service in the network which issues
pregenerated firmware images with all configuration already in there. So
you just select what hardware you have, where the node will be and
everything else is done by the system (for power users you can also
select additional OpenWrt packets and mangle with configuration, but it
is not necessary). You flash the image, power it up and this is it.

Now, the next step is to make this service distributed (like every node
can be it) and we have best of both worlds. ;-)

But currently we are making it modular, so that different networks can
adapt it to their needs:

http://dev.wlan-si.net/wiki/Nodewatcher

> IPv4.  We considered IPv6, and in fact we get it for free with the Linux
> kernel, but not all applications are aware of or play nicely with it.

Yes, but if everybody just waits for applications to be ready ... ;-)

I think it is crucial especially for decentralized networks to start
using it.

Maybe instead of random IP allocation you could try some distributed IP
allocation system where you would take some temporary IP and request
what is free (using distributed hash storage or something). But yes,
there were already so many other ideas for this problem discussed and
yes, there is a problem of mixing layers.

> This is an interesting problem to us, and one of the things we have in
> mind once Byzantium is stable is correcting problems with
> interoperability.

I would invite you to take part here:

http://interop.wlan-si.net/

It is an initiative by many networks to find some common ground. As I
see it is a bit more centralized that your approach (we are mostly using
centralized node databases), but probably we could also find some common
ground with you. For example, currently we are defining a common
database schema to be able to describe our nodes in a common way so that
we can then have common applications working over that.

You could probably use the same schema internally in your control panel
in a distributed way so that maybe some centralized system in your
network could still fetch this data and use it (for example to draw a
map or something).


Mitar

Re: [B.A.T.M.A.N.] [Battlemesh] Battlemesh-like experiment in Washington, DC

[The Doctor]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/09/2011 01:40 PM, Glen Duncan wrote:

>  Doesn't RFC-1918 and supporting protocols check to see if the address
> chosen is already in use and back off/retry if it fails?

That is an excellent question, but to answer it I will have to do some
research and get back to you.

- -- 

The Doctor [412/724/301/703]

PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F  DD89 3BD8 FF2B 807B 17C1
WWW: http://drwho.virtadpt.net/

"And the flowers are still standing!" --Peter Venkman, _Ghostbusters_

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5Ct4MACgkQO9j/K4B7F8F0sQCghfe67YYb3ESxCrL3myyRB0Ke
jKEAoLzkWeyMu1mN4qg975um5XN9Ldoe
=qRJY
-----END PGP SIGNATURE-----

Re: [B.A.T.M.A.N.] [Babel-users] [Battlemesh] Battlemesh-like experiment in Washington, DC

[haxwithaxe]

hi,
i'm one of the other byzantium developers. at some point we do intend to 
get switched over to ipv6 but for now we are using ipv4 just to simplify 
our lives during development as none of us are terribly experienced with 
ipv6.
our use case dictates that the meshes will at some point need to operate 
without being connected to the internet at all so relying on any kind of 
centralized service to configure the nodes isn't always going to work. 
also we are using x86 machines (laptops/desktops) for our nodes so we 
need to allow for tweaking given the diversity of the hardware byzantium 
will be on. we will likely have some form of graduated configuration 
which will start at the most basic level so that people don't have to 
fiddle with more settings than are required.
in addition the lack of centralized configuration mechanism prevents an 
a hostile party from spoofing control instructions and shutting down the 
network by scrambling the configs in the event byzantium is deployed in 
an environment where it may not be welcome by authorities, or if it's 
deployed in the proximity of skiddies who think it'd be funny to kill a 
community's link to each other and the internet.
also we are using ahcpd so withing the mesh it's not entirely random 
what ip one gets.


On 08/10/2011 12:53 PM, Mitar wrote:
> Hi!
>
>> The Byzantium control panel is an application which allows the user to
>> (de)configure network interfaces, add or remove them from a mesh, and
>> enable or disable services and web applications running on a node.  It
>> runs on a node (listening only on the loopback interface) and is
>> accessed with any web browser.  Technically, it is a web application,
>> but seeing as how Byzantium will package a couple of web applications
>> for public use on a mesh anyway (Etherpad-lite, crypto.cat, status.net,
>> and a few others) it made more sense to call it a control panel.
>
> Interesting. Just as an information, in our network (wlan slovenia) we
> have taken directly the opposite approach and made a centralized system
> for deploying nodes (centralized in the sense it is one of the services
> of the network, but the network itself still runs operates if this
> service is removed from operation, this server/system/service only
> streamlines node deployment (and prevents IP collisions so that it
> maintains ). The point we have seen is that web interface on the node
> takes simply too much time to maintain once you have many nodes which
> you want to configure the same (and update configuration and so on). It
> takes time to click all those things. And that it is still too technical
> for common people to use.
>
> So we have taken completely other approach: nodes without any web
> interface, where you have a service in the network which issues
> pregenerated firmware images with all configuration already in there. So
> you just select what hardware you have, where the node will be and
> everything else is done by the system (for power users you can also
> select additional OpenWrt packets and mangle with configuration, but it
> is not necessary). You flash the image, power it up and this is it.
>
> Now, the next step is to make this service distributed (like every node
> can be it) and we have best of both worlds. ;-)
>
> But currently we are making it modular, so that different networks can
> adapt it to their needs:
>
> http://dev.wlan-si.net/wiki/Nodewatcher
>
>> IPv4.  We considered IPv6, and in fact we get it for free with the Linux
>> kernel, but not all applications are aware of or play nicely with it.
>
> Yes, but if everybody just waits for applications to be ready ... ;-)
>
> I think it is crucial especially for decentralized networks to start
> using it.
>
> Maybe instead of random IP allocation you could try some distributed IP
> allocation system where you would take some temporary IP and request
> what is free (using distributed hash storage or something). But yes,
> there were already so many other ideas for this problem discussed and
> yes, there is a problem of mixing layers.
>
>> This is an interesting problem to us, and one of the things we have in
>> mind once Byzantium is stable is correcting problems with
>> interoperability.
>
> I would invite you to take part here:
>
> http://interop.wlan-si.net/
>
> It is an initiative by many networks to find some common ground. As I
> see it is a bit more centralized that your approach (we are mostly using
> centralized node databases), but probably we could also find some common
> ground with you. For example, currently we are defining a common
> database schema to be able to describe our nodes in a common way so that
> we can then have common applications working over that.
>
> You could probably use the same schema internally in your control panel
> in a distributed way so that maybe some centralized system in your
> network could still fetch this data and use it (for example to draw a
> map or something).
>
>
> Mitar
>
> _______________________________________________
> Babel-users mailing list
> Babel-users@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [B.A.T.M.A.N.] [Babel-users] [Battlemesh] Battlemesh-like experiment in Washington, DC

[Mitar]

Hi!

> our use case dictates that the meshes will at some point need to operate
> without being connected to the internet at all so relying on any kind of
> centralized service to configure the nodes isn't always going to work.

This centralized service does not need to be on the Internet? It can
just be one (or more) more powerful nodes in the network itself. Also, I
still believe that the concept is easier to develop centralized
(especially when it is a new concept and you have to try few iterations
to find the right ingredients) and then make it decentralized.

For example, the approach which we will probably take to decentralize
our system will be to have a distributed IP allocation storage over
whole network and a cloning approach to generate firmware images (so you
will just need an existing node of the same hardware and it will
generate a new image firmware just for you from its own firmware
currently running). So the concept of not having a web interface and
making maintenance and operation of the network very easily can still be
made decentralized.

But for 95 % of times when this central service will be available (and
can be deployed very fast again somewhere else if somebody takes one
offline), it will make network operation much much easier for everybody
(and thus also network faster spreading as it will be able to be
operated by non-technical people too, and for technical people, they
will not spend their time going through wizards again and again,
entering some numbers, potentially making mistakes). Again, network is
still decentralized, only for easier deployment we have additional
service in the network. You could still configure nodes yourself without
the system. But you would then face changes of IP collisions and
misconfigurations.

I just want to share our experiences. We have been there. We had web
interface on the routers. And we learned that this is maybe good for DIY
networks and geeks, but not if you want that common people deploy your
network. And at the end of the day, it counts how many nodes you have
deployed. Because this makes the network more resilient.

So we created an approach where you have plug & mesh. And everything
else is automatic. So people just have to share an idea, buy a router,
register it, plug it in and this is almost it.

Of course this approach is not best for all cases. But I would just like
to present it, so that maybe you can think about it and see if it fits
into your picture.

> also we are using x86 machines (laptops/desktops) for our nodes so we
> need to allow for tweaking given the diversity of the hardware byzantium
> will be on.

We also allow tweaking. You made all your changes in the OpenWrt
packages (currently we support only OpenWrt build chain, but we will
soon lift this limitation) and then it is always added to your firmware
image when generated.

Even more. Once this is in a package, somebody else can also use this
package for their own router. So instead that everybody tries same
things again and again, only one person has to do it, package it, and
everybody can use it.

> in addition the lack of centralized configuration mechanism prevents an
> a hostile party from spoofing control instructions and shutting down the
> network by scrambling the configs in the event byzantium is deployed in
> an environment where it may not be welcome by authorities, or if it's
> deployed in the proximity of skiddies who think it'd be funny to kill a
> community's link to each other and the internet.

Again, centralized system for monitoring and deployment does not mean
that taking over this system can make network less stable/useless. It
just means that you have to deploy the service somewhere else again (and
this again just one person has to know how to do and again everybody can
enjoy) or that you switch to secondary means of deployment (like cloning
routers).

BTW, it is much easier for anybody currently to throw any of our mesh
networks offline: you just need to put garbage and stupid routes in our
routing daemons. Zero route everything or something. This is much more
realistic scenario for me. Having a service which draws nice graphs and
maps put down is also possible. But to put the network down you will
just have to poison routing daemons.

Or just scramble the 2.4 GHz spectrum. If I would be government, I would
just broadcast sawtooth signal over whole 2.4 GHz spectrum at 100 kW.
Simple and effective.

So then we get back to the basic: more nodes, better the resilience,
harder to poison, harder to quiet. How to get more nodes? By very easy
deployment at the time of peace and possible deployment at the time of
war. And with many nodes it is hard to get all of them offline.

I believe the approach is in masses. It must be so easy to deploy that
even in the time of peace people will want and do deploy those nodes.
And not just heavily motivated geeks, but also normal population. Just
because of the fun of it, because it is something for a greater good.
And already have many of them in the time of peace. Because it is a bit
too late to start deploying them when there are problems already on the
horizon. Simply the problem of time. (Especially if you have to click
each time again on the web interface things.)

> also we are using ahcpd so withing the mesh it's not entirely random
> what ip one gets.

But who decides which subnet a node gets to give forward? Or which IP
does a node have?


Mitar