-----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

...

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

...

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

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

...

...

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

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

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

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