Oh no. Not another firmware project. Please work with qmp or libremesh or villagetelco.

2) bmx6 won the last battlemesh competition.

3) Yes I'm well aware of the firmware projects and that they spin openwrt a certain way. Unfortunately most of them don't push changes back upstream or use openwrt features to make integration easier (like feeds).

4) qmp is used by guifi.net. They are the largest mesh network in the world with 15k+ nodes.

6) Actually nodeshot is pretty much the standard for mapping, used by pretty much all the mesh projects as a map/dashboard system.

On Wed, Jul 10, 2013 at 4:21 PM, Charles N Wyble <charles(a)thefnf.org> wrote: I find this statement odd. In my opinion it doesn't make sense for different mesh projects to share a firmware project. These "firmwares" are all just OpenWRT with extra packages pre-installed and a bit of mesh-specific default configuration... sometimes some custom web gui stuff. Most of this will vary based on what the mesh project is trying to achieve. New work in the form of additional features for OpenWRT should be put into OpenWRT or released in the form of OpenWRT packages. Useful configuration files and web guis can be shared, but will likely need to be adapted by the different groups Let's have a look at these projects anyway: qmp does not support all of the devices we are using. It uses bmx6 which as far as I can tell is based on the now-abandoned batmand, and so runs in userland (ah!) and is layer 3. On top of that bmx6 it seems to have a worryingly small amount of documentation. qmp has a few tools that may be interesting, like a node map, but then again all mesh groups seem to have their own node map and little helper tools. libre-mesh.org is giving me a 502 bad gateway and archive.org does not have a copy of the site. Looking at the git repo it seems to consist of a few make files, a bit of addition to the openwrt web gui and a bit of configuration. It oddly installs both bmx6 _and_ batman-adv on all routers (we have lots of 4mb flash routers. space is an issue). villagetelco seems to be a for profit company (?). They support only their own hardware and two models of tp-link. It bundles SIP stuff and its goals seem to be very different from ours. I'm sure someone who just wants an easy to deploy mesh solution and doesn't care too much about the specifics of the firmware could be happy with these solutions, but given our goals, basing our firmware on either of these projects would likely set us back more than it would help. In my opinion, the correct solution for building a mesh firmware is to begin by identifying what the needs of the mesh project are, identify what functionality the firmware must have in order to best fulfill those needs, then find the best tools from OpenWRT or other mesh projects for the required functionality and finally combine them into a custom firmware. _______________________________________________ mesh mailing list mesh(a)lists.sudoroom.org http://lists.sudoroom.org/listinfo/mesh

Hi! I would just raise concerns about captive portal/splash screen. We had that for some time and it was much more an issue than worth. It was our primary reason why people said that the network does not work. People wondered why things don't work. For example Skype and e-mail. And the concept that they have first to open some webpage. And then Skype will start working. This was made easier now since OSes detect captive portal and display information about that. But still. Smart phones still have this issue. It does not work with HTTPS. And we should encourage users to use HTTPS. So if they are using Google over HTTPS and we have captive portal and they want to open Google (what is what they do in practice first) over HTTPS, you have two options: - you block 443 (and all other ports) until they confirm - you intercept and have some untrusted SSL shown (which is really bad to get people used to that) - you leave through all traffic before the captive portal, you intercept only 80, but then it is very strange why everything works, except 80 In general captive portal is a very bad moment to display any information. People want at that moment to connect to the Internet, they will just click anything and continue. What you would want is to display something after they finish working with anything. So like captive portal people maybe read first time, but later on it is useless to use it for some messages and notices. And the most important thing: If you have captive portal on nodes, then every time you want to upgrade captive portal, you have to upgrade nodes. (You could maybe make some system which syncs this automatically, but then nodes are getting more and more complicated and you might want that things are stable and don't change once they are deployed.) Captive portal also makes things harder when uplink to Internet fails. So then in such situations people have to confirm the captive portal just to be able to connect to the network, not even Internet. This is hard to explain to people. This difference. Captive portal makes it really hard for Batman roaming between nodes. So we removed captive portals from all nodes. Currently we don't have anything. What we are planning is to intercept first request on port 80 on the Internet gateway and redirect to our social info portal called PiplMesh: http://dev.wlan-si.net/wiki/PiplMesh So the idea is that people can still use the network and Internet normally. You just hijack first request. But it is not a captive portal (so no button to confirm to get access). Just to display information about the network. But even more important: to display a portal which is useful to people using the network. If you have such a portal, then people will be using and reading things there and you will get people engaged into the network and then you can communicate two-ways with your users. So the idea is that on that portal all connected people to the mesh can communicate in real-time, share information (like "hey, this event is happening there and there, come", or even "hay, I am sitting in this coffee shop, anybody for a chat?" or "I am a CouchSurfer and got stranded in the city, can anybody offer me a couch for a night?" And you can share this based on the distance in hops from the node you are connected to (for example the message about chat is relevant only to the node you are on, the message about the event is maybe useful to more people, and CouchSurfer might want to address the whole city). So the portal again introduces the physical nature of "voice" into virtual sharing. How load you are, so far you are heard. And distance is hops between nodes. And next to that you can also display local relevant information for people. So the idea is that captive portal influence is minimized (only 80 port, firs time) and that the content of the portal is made useful to the people. So that they might even use it outside the captive portal use. But yes, this is again possible because we have a centralized gateway and we don't have issues with central services if the network can still operate without them. They then just add a value to the network and make adoption and usefulness of the network higher. (The development of PiplMesh sadly stopped and we will probably rewrite it from the scratch. But the idea I believe is still valid.) Mitar > Hi all! > > Thought I might start sharing what's been getting added to our wiki each > week, as well as general mesh-related links I come across. Feel free to add > to this thread! > > *Wiki:* > > - Tunabananas added Mesh/Oakland > <https://sudoroom.org/wiki/Mesh/Oakland>for Oakland-specific data. > Currently this links to a spreadsheet of local > organizations [schools, churches, etc] as well as a 157-page document from > 2009 on the feasibility of providing municipal wifi in Oakland. > - Tunabananas updated > Mesh/Other_mesh_projects<https://sudoroom.org/wiki/Mesh/Other_mesh_proje… > more info on the abrupt rise and seeming fall of SF Lan. > - Juul created Mesh/Firmware > <https://sudoroom.org/wiki/Mesh/Firmware>with lots of ideas and plans > for the firmware we'll be developing for the > mesh! > - MaxB added some system configuration details on the > Mesh/BATMAN-adv<https://sudoroom.org/wiki/Mesh/BATMAN-adv>paget;page. > - Tunabananas updated Meeting > Minutes<https://sudoroom.org/wiki/Mesh/04_July_2013>with last week's > minutes. > - Tunabananas created Mesh/Naming > <https://sudoroom.org/wiki/Mesh/Naming>to document potential names for > our group. > - Juul created Mesh/Bylaws <https://sudoroom.org/wiki/Mesh/Bylaws> - we > could **really** use some feedback and input on these potential bylaws > so we can become a 501(c)3! > - Mitar added information about wlan-slovenia to > Mesh/Other_mesh_projects<https://sudoroom.org/wiki/Mesh/Other_mesh_proje… > > *Some recent news on mesh:* > <http://www.networkcomputing.com/next-generation-data-center/servers/mesh-networking-revival-sparked-by-nsa-p/240157635> > > - Mesh Networking Revival Sparked By NSA PRISM > Program<http://www.networkcomputing.com/next-generation-data-center/serv… > <http://www.technologyreview.com/news/516571/build-your-own-internet-with-mobile-mesh-networking/#comments> > - Build Your Own Internet with Mobile Mesh > Networking<http://www.technologyreview.com/news/516571/build-your-own-in… > - The Serval mobile mesh project is currently > crowdfunding<http://www.indiegogo.com/projects/speak-freely> > - Stop overbroad patents that would put limitations on the progress of > mesh technology!<https://www.eff.org/deeplinks/2013/06/mesh-networking-good-o… > > --------- > Jenny > http://jennyryan.net > http://thepyre.org > http://thevirtualcampfire.org > http://technomadic.tumblr.com > > `~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~` > "Technology is the campfire around which we tell our stories." > -Laurie Anderson > > "Storytelling reveals meaning without committing the error of defining it." > -Hannah Arendt > > "To define is to kill. To suggest is to create." > -Stéphane Mallarmé > ~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~` > > > > _______________________________________________ > mesh mailing list > mesh(a)lists.sudoroom.org > http://lists.sudoroom.org/listinfo/mesh >

Hi! I would just raise concerns about captive portal/splash screen. We had that for some time and it was much more an issue than worth. It was our primary reason why people said that the network does not work. People wondered why things don't work. For example Skype and e-mail. And the concept that they have first to open some webpage. And then Skype will start working. This was made easier now since OSes detect captive portal and display information about that. But still. Smart phones still have this issue.

It does not work with HTTPS. And we should encourage users to use HTTPS. So if they are using Google over HTTPS and we have captive portal and they want to open Google (what is what they do in practice first) over HTTPS, you have two options: - you block 443 (and all other ports) until they confirm - you intercept and have some untrusted SSL shown (which is really bad to get people used to that) - you leave through all traffic before the captive portal, you intercept only 80, but then it is very strange why everything works, except 80

In general captive portal is a very bad moment to display any information. People want at that moment to connect to the Internet, they will just click anything and continue. What you would want is to display something after they finish working with anything. So like captive portal people maybe read first time, but later on it is useless to use it for some messages and notices.

And the most important thing: If you have captive portal on nodes, then every time you want to upgrade captive portal, you have to upgrade nodes. (You could maybe make some system which syncs this automatically, but then nodes are getting more and more complicated and you might want that things are stable and don't change once they are deployed.)

Captive portal also makes things harder when uplink to Internet fails. So then in such situations people have to confirm the captive portal just to be able to connect to the network, not even Internet. This is hard to explain to people. This difference.

Captive portal makes it really hard for Batman roaming between nodes.

So we removed captive portals from all nodes. Currently we don't have anything. What we are planning is to intercept first request on port 80 on the Internet gateway and redirect to our social info portal called PiplMesh: http://dev.wlan-si.net/wiki/PiplMesh So the idea is that people can still use the network and Internet normally. You just hijack first request. But it is not a captive portal (so no button to confirm to get access). Just to display information about the network. But even more important: to display a portal which is useful to people using the network. If you have such a portal, then people will be using and reading things there and you will get people engaged into the network and then you can communicate two-ways with your users.

So the idea is that on that portal all connected people to the mesh can communicate in real-time, share information (like "hey, this event is happening there and there, come", or even "hay, I am sitting in this coffee shop, anybody for a chat?" or "I am a CouchSurfer and got stranded in the city, can anybody offer me a couch for a night?" And you can share this based on the distance in hops from the node you are connected to (for example the message about chat is relevant only to the node you are on, the message about the event is maybe useful to more people, and CouchSurfer might want to address the whole city). So the portal again introduces the physical nature of "voice" into virtual sharing. How load you are, so far you are heard. And distance is hops between nodes.

And next to that you can also display local relevant information for people. So the idea is that captive portal influence is minimized (only 80 port, firs time) and that the content of the portal is made useful to the people. So that they might even use it outside the captive portal use.

But yes, this is again possible because we have a centralized gateway and we don't have issues with central services if the network can still operate without them. They then just add a value to the network and make adoption and usefulness of the network higher.

(The development of PiplMesh sadly stopped and we will probably rewrite it from the scratch. But the idea I believe is still valid.)

What I am missing, I would go into a decentralized architecture with this, is something which integrates nicely with Zeroconf. So that even when there is no gateway and users are not technically skilled, they can still connect to some common chat with Skype, iChat, Adium or some other chat client with supports Zeroconf/Bonjour. Sadly, not many closed source do (and also this support is limited, probably still requires Internet access, haven't tried it yet). I tend to first implement something centrally, to even try if the idea is good. And then distribute. But I know that we disagree on that. For me, it is just a practical approach. Do I want to spend one year implementing a framework to develop my distributed app running on nodes. Or do I want to spend one year working on a app itself. It just boils down to how many developers there is. I rather spend time on something which can be used immediately and by everybody (so it has to work as they people are used to). But please, teach/show me how can be this done easier. Maybe I am just an old school guy who has not yet grasped some new framework which allows to do this. Is there a framework like http://www.meteor.com/, just distributed and would run on nodes themselves?

so once we have the core features implemented in big we will surely finish implementing the distributed features.

a few people and i spend our time working on such a framework: https://github.com/bigcompany/big/ and https://www.bountysource.com/fundraisers/383-big. the original creator of the project was behind the late hook.io (https://npmjs.org/package/hook.io) which had a lot of features for running distributed nodes of a single app, so once we have the core features implemented in big we will surely finish implementing the distributed features. we're not yet ready for production so give us at least half a year, maybe a year, maybe more. hopefully sooner i'll be able to release some alpha apps like