-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/16/2011 11:34 AM, Marek Lindner wrote: 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

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

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. 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! What do you use for your control panel application? You do know birthday paradox? ;-) https://secure.wikimedia.org/wikipedia/en/wiki/Birthday_problem Mitar

Is that available yet? -- Juliusz

Hi! 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? 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! 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 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. 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! 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. 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. 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.) But who decides which subnet a node gets to give forward? Or which IP does a node have? Mitar