From 95aa819fdd71623c2f43f35f0aa63b7b86b785ac Mon Sep 17 00:00:00 2001
From: Andrew Reynolds It contains only the scripts and default files needed to download OpenWRT and add Commotion's packages to the OpenWRT build system. Those Commotion packages are defined in the packages directory of the Commotion Feed repo (https://github.com/opentechinstitute/commotion-feed.git). Package source code can be found in the repositories (PKG_SOURCE_URL) and branches (PKG_VERSION) specified in their respective Commotion Feed Makefiles. See the Commotion Router Readme on GitHub. Commotion runs on multiple software and hardware platforms: Embedded routers, smart phones, desktops and laptops, and open source GSM basestations. Development on each of these platforms occurs in parallel. Where possible, a common set of tools are used to develop Commotion, no matter the platform. However, there are certain platforms where unique tools are required. Commotion runs on multiple software and hardware platforms: Embedded routers,
+smart phones, desktops and laptops, and open source GSM basestations.
+Development on each of these platforms occurs in parallel. Where possible, a
+common set of tools are used to develop Commotion, no matter the platform.
+However, there are certain platforms where unique tools are required. All Commotion platforms share a common core: a shared network medium (usually ad-hoc Wifi, known as IBSS) and an IP routing protocol (OLSRd). Read more about the Commotion architecture and how it varies across platforms on the Developer Wiki. All Commotion platforms share a common core: a shared network medium (usually
+ad-hoc Wifi, known as IBSS) and
+an IP routing protocol (OLSRd). Read more
+about the
+Commotion architecture and how it varies across platforms on the Developer
+Wiki. Commotion is written in a combination of C, Lua, Javascript, Python, Java, shell, Objective-C, PHP. All of our source code is hosted on Github. To see the relationship between code repositories and the Commotion architecture, read the architecture documents above. Commotion is written in a combination of C, Lua, Javascript, Python, Java,
+shell, Objective-C, PHP. All of our source code is hosted on Github. To see the relationship
+between code repositories and the Commotion architecture, read the architecture
+documents above. Commotion developers rely on a combination of tools and intuition to debug. We use gdb, ddms and unit testing. Read more about our testing procedures and methodologies and procedures for lab testing on the Developer Wiki. Commotion developers rely on a combination of tools, experience, and intuition to debug.
+We use gdb, ddms and unit testing. Read more about our testing procedures and methodologies
+and procedures for
+lab testing on the Developer Wiki. Read more about common debugging procedures we use on the Developer Wiki. To report bugs and submit fixes, use our issue tracker. Read more about common
+debugging procedures we use on the Developer Wiki. To report bugs and submit
+fixes, use our issue
+tracker. It contains only the scripts and default files needed to download OpenWRT and add Commotion's packages to the OpenWRT build system. Those Commotion packages are defined in the packages directory of the Commotion Feed repo (https://github.com/opentechinstitute/commotion-feed.git). Package source code can be found in the repositories (PKG_SOURCE_URL) and branches (PKG_VERSION) specified in their respective Commotion Feed Makefiles. Commotion-Router is a highly customized version of the OpenWRT embedded Linux distribution. The main project repository (commotion-router) contains only the scripts and default files needed to download OpenWRT and add Commotion's packages to the OpenWRT build system. Those Commotion packages are defined in the packages directory of the Commotion Feed repo. Source code for individual Commotion-Router packages can be found in the repositories (PKG_SOURCE_URL) and branches (PKG_VERSION) specified in their respective Commotion Feed Makefiles. By default, Commotion-Router is configured to build images for Ubiquiti devices using the master branch of each project repo. New development takes place in feature branches, which are merged to master after function testing. Commotion-Router can theoretically be built for any OpenWRT-compatible device with sufficient flash storage to install the 5.4MB Commotion image. However, at present, devices using the ar7xxx/ar9xxx have the best wireless driver compatibility. See the Commotion Router Readme on GitHub. See the Commotion Router Readme on GitHub. Commotion-Router is a highly customized version of the OpenWRT embedded Linux distribution. The main project repository (commotion-router) contains only the scripts and default files needed to download OpenWRT and add Commotion's packages to the OpenWRT build system. Those Commotion packages are defined in the packages directory of the Commotion Feed repo. Source code for individual Commotion-Router packages can be found in the repositories (PKG_SOURCE_URL) and branches (PKG_VERSION) specified in their respective Commotion Feed Makefiles. By default, Commotion-Router is configured to build images for Ubiquiti devices using the master branch of each project repo. New development takes place in feature branches, which are merged to master after function testing. By default, Commotion-Router is configured to build images for Ubiquiti devices using the master branch of each project repo. New development takes place in feature branches, which are merged to master after function testing. See the GitHub Workflow document on the Commotion Wiki for information on branching and submitting patches. Commotion-Router can theoretically be built for any OpenWRT-compatible device with sufficient flash storage to install the 5.4MB Commotion image. However, at present, devices using the ar7xxx/ar9xxx have the best wireless driver compatibility. See the OpenWRT Easy Build guide for OpenWRT's minimum build prerequisites. You may encounter additional dependencies when building or developing specific Commotion packages. See the Android Issue #82), the original Commotion-Android, currently in master branch is deprecated. All new development should be based on Commotion-Android's CM branch. https://github.com/opentechinstitute/commotion-android/tree/cm See the Commotion-Android Readme for build instructions and prerequisites.Overview
+Structure
+Build/Install
+Platforms
-
-
Architectures
-Code
-Debugging Tools
-Overview
-Structure
-Build/Install
-Overview
Prerequisites
+Build/Install
Source Code
+Build & Install
+
Commotion runs on multiple software and hardware platforms: Embedded routers, -smart phones, desktops and laptops, and open source GSM basestations. -Development on each of these platforms occurs in parallel. Where possible, a -common set of tools are used to develop Commotion, no matter the platform. -However, there are certain platforms where unique tools are required.
+Commotion runs on multiple software and hardware platforms: Embedded routers, smart phones, desktops and laptops, and open source GSM basestations. Development on each of these platforms occurs in parallel. Where possible, a common set of tools are used to develop Commotion, no matter the platform. However, there are certain platforms where unique tools are required.
All Commotion platforms share a common core: a shared network medium (usually -ad-hoc Wifi, known as IBSS) and -an IP routing protocol (OLSRd). Read more -about the -Commotion architecture and how it varies across platforms on the Developer -Wiki.
+All Commotion platforms share a common core: a shared network medium (usually ad-hoc Wifi, known as IBSS) and an IP routing protocol (OLSRd). Read more about the Commotion architecture and how it varies across platforms on the Developer Wiki.
Commotion is written in a combination of C, Lua, Javascript, Python, Java, -shell, Objective-C, PHP. All of our source code is hosted on Github. To see the relationship -between code repositories and the Commotion architecture, read the architecture -documents above.
+Commotion is written in a combination of C, Lua, Javascript, Python, Java, shell, Objective-C, PHP. All of our source code is hosted on Github. To see the relationship between code repositories and the Commotion architecture, read the architecture documents above.
+ +See the GitHub Workflow page on the Commotion Wiki for information on the Commotion team's GitHub workflow.
Commotion developers rely on a combination of tools, experience, and intuition to debug. -We use gdb, ddms and unit testing. Read more about our testing procedures and methodologies -and procedures for -lab testing on the Developer Wiki.
+Commotion developers rely on a combination of tools, experience, and intuition to debug. We use gdb, ddms and unit testing. Read more about our testing procedures and methodologies and procedures for lab testing on the Developer Wiki.
-Read more about common -debugging procedures we use on the Developer Wiki. To report bugs and submit -fixes, use our issue -tracker.
+Read more about common debugging procedures we use on the Developer Wiki. To report bugs and submit fixes, use our issue tracker.
From 3b8b27009cc3dbbf6472db2810517b4a1a2acc20 Mon Sep 17 00:00:00 2001 From: Andrew ReynoldsOur nightly builds are back! Nightly built images of Commotion OpenWRT are generated from our build server and posted to downloads.commotionwireless.net/nightly. Nightly images contain the most up to date feature and bug fix commites, but should be considered working, yet unstable builds.
+ +### Build From Source +Commotion-Router's source code is available on GitHub: https://github.com/opentechinstitute/commotion-router. See the Commotion-Router README for information on building and installing from source.
From ae795ad4e3c3c56443f3b58810a917dee9d61300 Mon Sep 17 00:00:00 2001 From: Chris RitzoCommotion is not currently a secure circumvention tool. At some point that statement will not be true, but until then this fact must be known by anyone who interacts with Commotion. With the increasing popularity of digital circumvention tools, news outlets have pointed to Commotion as a possible tool for creating safe local communication networks when the usual channels are compromised. When an unfinished project like Commotion enters the spotlight, it is important to warn potential users about the limitations of the tools in development. In the circumvention and cryptography communities, this is usually done with a warning. This post will walk through our process for developing a warning label. We hope it will help new projects who face this same dilemma. We decided to frame our search for a warning by asking two questions. What information is important for a potential user of Commotion to have to make an informed decision? How do we ensure the "ability of the individual reading [the warning] to understand the information sufficiently to take the desired action"[1] for their specific situation? We brainstormed country-specific warnings that identified local threats from internet rights watchdogs[2] to create customized warnings for various levels of threat. But with location anonymizing tools[3] and individual variability in threats, we decided to create a unified warning that focuses on what Commotion can't do. Broadly, Commotion is a tool-kit that allows wireless routers, laptop and desktop computers, rooted android phones, and software-defined cell phone basestations to find and communicate with and through each other. What Commotion is unable to do is a trickier question. Commotion is unable to do many things. It cannot ride a bike or do my taxes. But, most users will not expect these things. In order to tell potential users what Commotion cannot do, we needed to find out the potential set of functionality users expect of Commotion. To discover possible expectations, we poured over our own outreach and the press we have received to see what it conveyed to those who read it. Here is a collection of salient snippets, and what functionality we gleaned from them. Secure independent wireless for conflicts and disasters:
+"\[The\] Internet in a Suitcase is basically a software program aimed at giving people in conflict or disaster zones the ability to establish a secure, independent wireless network over their computers and cell phones." \[4\]+
Device and centralized infrastructure-independent tool which eliminates surveillance and monitoring while ensuring the identity of those you communicate with:
+"This is a completely ad hoc network, there's no dependency of any device on any other device and that eliminates a central point for command and control surveillance and monitoring," said Meinrath. "We also have authentication between each hop on the network and encryption across each hop." \[4\]+
Free phone calls:
+"The killer app that I talk with a lot of folks about is, if you have a system like this, there's no reason you would ever need to pay for local phone calls again" once you've downloaded the software allowing your device to join the wifi network, "because you're just pinging machine to machine over a local network," said Meinrath. \[4\]+
Cheap tech for routers and Android phones for dissidents to evade censorship:
+"He and a team of software engineers are developing open-source software to turn cheap wireless access points and Android smartphones into nodes on the network, which could then be used by dissidents to evade censorship and to spread low-cost connections everywhere around the world." \[6\]+
Easy to install and set up:
+”The firmware provides auto-configuration capabilities,” said Brian Duggan, one of the engineers on the Internet in a Suitcase project, “so you don’t need to be an engineer” to install it. “You flash as many nodes as you want, or pick up previous ones.” \[6\]+
Delay tolerant access to the Internet:
+“You could have a delay-tolerant Twitter, where people on the local network could see your tweets and then when a connection is restored it could get pushed to the internet,” Meinrath said. “We are in the very infancy of this kind of intranet.” \[6\]+
We're rock stars (totally true):
+"One operation out of a spy novel in a fifth-floor shop on L Street in Washington, where a group of young entrepreneurs who look as if they could be in a garage band are fitting deceptively innocent-looking hardware into a prototype “Internet in a suitcase.” \[5\]+
Separate from existing infrastructure, impossible to shut down, control, and surveil:
+“We’re going to build a separate infrastructure where the technology is nearly impossible to shut down, to control, to surveil.” \[5\]+
Decentralized network using phones, computers:
+"Commotion is an open-source communication tool that uses mobile phones, computers, and other wireless devices to create decentralized mesh networks." \[7\]+
Share the internet:
+"Commotion software also allows users on a mesh network to share access to the Internet. The software does not provide Internet access, but it does allow multiple devices to share their connections." \[7\]+
Robust network that ensures anonymity and circumvents censorship even when other communication systems have failed:
+"Commotion is a flexible set of tools that can work well in many different scenarios. They can grow, shrink, and move as necessary and according to available resources. Commotion is organized and maintained by community members to fit their needs. It can act as a backbone for last-mile infrastructure, a local community network, a circumvention and anonymity ensuring communication channel, or a local emergency communications infrastructure when existing systems are severed." \[7\]+
This set of quotes gave us an idea of what we have presented as the current and future states of Commotion, and therefore, what users may expect from Commotion when they go to download it. We took these quotes and compiled a list of what the current release of Commotion is NOT yet able to do. Commotion does not:
+With this list in hand we narrowed down to the points that increase the ability of a potential user to make an informed decision about their security. Commotion does not:
+In Part 2, we'll go over how we used this list of unimplemented security features to develop a warning label.
+Commotion is not currently a secure circumvention tool. At some point that statement will not be true, but until then this fact must be known by anyone who interacts with Commotion. With the increasing popularity of digital circumvention tools, news outlets have pointed to Commotion as a possible tool for creating safe local communication networks when the usual channels are compromised. When an unfinished project like Commotion enters the spotlight, it is important to warn potential users about the limitations of the tools in development. In the circumvention and cryptography communities, this is usually done with a warning. This post will walk through our process for developing a warning label. We hope it will help new projects who face this same dilemma. We decided to frame our search for a warning by asking two questions. What information is important for a potential user of Commotion to have to make an informed decision? How do we ensure the "ability of the individual reading [the warning] to understand the information sufficiently to take the desired action"[1] for their specific situation? We brainstormed country-specific warnings that identified local threats from internet rights watchdogs[2] to create customized warnings for various levels of threat. But with location anonymizing tools[3] and individual variability in threats, we decided to create a unified warning that focuses on what Commotion can't do. Broadly, Commotion is a tool-kit that allows wireless routers, laptop and desktop computers, rooted android phones, and software-defined cell phone basestations to find and communicate with and through each other. What Commotion is unable to do is a trickier question. Commotion is unable to do many things. It cannot ride a bike or do my taxes. But, most users will not expect these things. In order to tell potential users what Commotion cannot do, we needed to find out the potential set of functionality users expect of Commotion. To discover possible expectations, we poured over our own outreach and the press we have received to see what it conveyed to those who read it. Here is a collection of salient snippets, and what functionality we gleaned from them. Secure independent wireless for conflicts and disasters:
-"\[The\] Internet in a Suitcase is basically a software program aimed at giving people in conflict or disaster zones the ability to establish a secure, independent wireless network over their computers and cell phones." \[4\]-
Device and centralized infrastructure-independent tool which eliminates surveillance and monitoring while ensuring the identity of those you communicate with:
-"This is a completely ad hoc network, there's no dependency of any device on any other device and that eliminates a central point for command and control surveillance and monitoring," said Meinrath. "We also have authentication between each hop on the network and encryption across each hop." \[4\]-
Free phone calls:
-"The killer app that I talk with a lot of folks about is, if you have a system like this, there's no reason you would ever need to pay for local phone calls again" once you've downloaded the software allowing your device to join the wifi network, "because you're just pinging machine to machine over a local network," said Meinrath. \[4\]-
Cheap tech for routers and Android phones for dissidents to evade censorship:
-"He and a team of software engineers are developing open-source software to turn cheap wireless access points and Android smartphones into nodes on the network, which could then be used by dissidents to evade censorship and to spread low-cost connections everywhere around the world." \[6\]-
Easy to install and set up:
-”The firmware provides auto-configuration capabilities,” said Brian Duggan, one of the engineers on the Internet in a Suitcase project, “so you don’t need to be an engineer” to install it. “You flash as many nodes as you want, or pick up previous ones.” \[6\]-
Delay tolerant access to the Internet:
-“You could have a delay-tolerant Twitter, where people on the local network could see your tweets and then when a connection is restored it could get pushed to the internet,” Meinrath said. “We are in the very infancy of this kind of intranet.” \[6\]-
We're rock stars (totally true):
-"One operation out of a spy novel in a fifth-floor shop on L Street in Washington, where a group of young entrepreneurs who look as if they could be in a garage band are fitting deceptively innocent-looking hardware into a prototype “Internet in a suitcase.” \[5\]-
Separate from existing infrastructure, impossible to shut down, control, and surveil:
-“We’re going to build a separate infrastructure where the technology is nearly impossible to shut down, to control, to surveil.” \[5\]-
Decentralized network using phones, computers:
-"Commotion is an open-source communication tool that uses mobile phones, computers, and other wireless devices to create decentralized mesh networks." \[7\]-
Share the internet:
-"Commotion software also allows users on a mesh network to share access to the Internet. The software does not provide Internet access, but it does allow multiple devices to share their connections." \[7\]-
Robust network that ensures anonymity and circumvents censorship even when other communication systems have failed:
-"Commotion is a flexible set of tools that can work well in many different scenarios. They can grow, shrink, and move as necessary and according to available resources. Commotion is organized and maintained by community members to fit their needs. It can act as a backbone for last-mile infrastructure, a local community network, a circumvention and anonymity ensuring communication channel, or a local emergency communications infrastructure when existing systems are severed." \[7\]-
This set of quotes gave us an idea of what we have presented as the current and future states of Commotion, and therefore, what users may expect from Commotion when they go to download it. We took these quotes and compiled a list of what the current release of Commotion is NOT yet able to do. Commotion does not:
-With this list in hand we narrowed down to the points that increase the ability of a potential user to make an informed decision about their security. Commotion does not:
-In Part 2, we'll go over how we used this list of unimplemented security features to develop a warning label.
-In Part 1, we came up with a list of security features Commotion lacked. We took this list of unimplemented security features and used OSHA's hazard communication guide to clarify our language[9]:
+Our first change was to move the negative “does not” that is stated in the header into each statement. This ensures that each statement can be read out of context of the whole with full meaning intact and gave us greater freedom in our wording on each line. We then switched the focus from attacks that Commotion does not protect against to consequences that come from lack of feature sets. For example, we removed "malware" in favor of highlighting the result of data and identity insecurity. We then went through each statement to remove jargon/acronyms and make the language more active. WARNING!Commotion:
+In accordance to ANZI "Product Safety Signs and Labels" [10], the term "warning indicates a potentially hazardous situation which, if not avoided, could result in death or serious injury." We felt that this was appropriate for the current non-secure release of Commotion. The next highest level, "danger" is "to be limited to the most extreme situations." We will reserve this warning for our future release of a "secure" Commotion distribution to emphasize the ways in which it does not provide full security. We hope this escalation will signal to users of Commotion for secure communication that they put themselves in danger by assuming security where it does not exist. In the future, as we have translation done on our documentation, we will also work with translators to ensure that region-specific translations are not direct translations, but instead clearly convey the warnings to the users in the most understandable way. With our language solidified, we started on our second question: How do we ensure the "ability of the individual reading [the warning] to understand the information sufficiently to take the desired action"[1] for their specific situation? The first thing that we did was look for existing literature on warning labels in software, which was sorely lacking. So, we turned to warning labels on tobacco, drugs, and dangerous machinery. "A review of the science base to support the development of health warnings for tobacco packages" is an interesting read for its own merit, and was a great resource in helping us ensure that the warning was in the best possible site placement to reach our users.
++
- ...shoppers typically start at the dominant visual element (often the brand name), and are then drawn to the next strongest element (usually the next most dominant visual element).
- A related and important point is that viewing patterns are driven by packaging layout rather than a function of “what people want to look at” or what they think is important. In other words, the fact that a message is frequently missed or overlooked does not mean that shoppers think it is unimportant. It simply means that the message was not adequately highlighted on the package...
- In the few seconds that shoppers typically spend looking at a package, they can actively consider only three or four primary design elements... Research repeatedly found that adding extra messages does not usually increase packaging viewing time, but instead results in more elements fighting for attention in a ‘zero-sum’ game. Package viewing patterns suggest that the “less is more” axiom is nearly always true...
- Package viewing patterns are largely consistent across cultures and product categories because they are driven mainly by human physiology rather than by cultural patterns of preferences.
- Is it important for a packaging design to establish a dominant viewing flow that leads consumers from their “start point” to the other critical packaging elements... What doesn’t work well is a balanced lay out in which the main visual starts consumers in the middle and the other design elements surrounding it are all secondary. The ineffective balanced layout forces consumers to ‘randomly’ choose among directions, and this often causes them to miss important / key elements of the labeling.
Our warning needs to be the main visual element on the page and highlighted above everything else on the screen. Pages that display the warning must have minimal eye-catching elements to ensure that the user is not distracted from the warning. Eye tracking research [8] shows that "users start by reading across the top line and then look down the page a little and read across again and then continue down the left side."[8] Based upon this we decided to place our warning as the topmost content item on the page. This would be the first and most bold item that varies from the generic website themeing. Beyond this placement, we also decided to add a secondary javascript element of this warning when a user loads the downloads page. We added this extra layer on the downloads page because it is the portal for aquireing the software. We felt an additional layer of warning was warranted. This requires the user to click a button stating that "I Understand" to highlight the importance of the warning. We also provided a second button "I DON'T Understand" which sends the user to a more in-depth explanation of the current "in-security" of the current releases. The commotion site has a vibrant design. It has pastel tones and "speech bubble" section dividers. We assume that a user will quickly start to ignore site content that is themed similarly as navigational content. A warning label must stand out from all common site elements in order to ensure that a user sees it as important content. When we looked at research on font use in warnings we found we had used the most effective warning fonts as our generic site fonts. The Commotion site uses AsapRegular, Ariel, or sans-serif depending upon the availability in a users browser. We were left with size and color to visually differentiate our image. We chose a warning header size that was 1.5 larger than our largest header fonts and using all Caps. Lastly we decided that none of the text on the warning could be text converted to an image format. It is important for translation and text-based browsing that this information is available as html & text. While the warning must stand out from the site,we came across a warning that it must not look like advertising as "Users seldom look at banner ads or anything that remotely looks like an advertisement."[8] In order to accomplish this we decided to use a traditional warning color scheme. This was a simple process, as there are common color combinations to go with different warning levels. "Use a red background with white lettering for danger, orange background with black lettering for warning, and yellow background with black lettering for caution to indicate decreasing levels of hazard."[11] This left us with a orange background. The debate over what icon to use for our warning was quickly extinguished by a study cited in the OSHA's hazard communication guide which stated that "The presence of the signal icon had no significant effect on hazard perception." We decided that adding content that did not effect hazard perception, and had the possibility of distracting a user from the important aspects of the message was not worth the possible risk. Now that we have a warning that will clearly convey the required information, we need to ensure that a user take the desired action. The desired action is for users to NOT use Commotion for communication requiring security unless they are layering other secure communication tools on top or along-side it. We hope to ensure this with the “I Don’t Understand” document. By placing links next to each warning bullet point to projects that address the security needs that Commotion we hope to lower the “cost of compliance”[12] to a level where the user does not “give up” and will either pair these technologies with Commotion, if there needs require mesh support, or use a security tool that is appropriate for their needs. The final Commotion warning can be seen on our downloads page. This process was an enlightening one. The most important lesson we learned was that a truly good warning is a clear and simple one. Warning labels have been internationally standardized. Our warning would not seem out of place on the side of dangerous machinery in any country. By following standards developed over years of research we can best ensure that our users take the warning with the gravity that it deserves. Creating tools for privacy comes with a deep responsibility to ones users. In an age where already spun news stories can be chopped into misleading 140 character tweets, and when these ideas make there way in to overheard conversations at parties and conferences, the responsibility falls on us to ensure that the public face that we do control is clear about the perils of our technology. A warning is merely one of the steps that we must take to educate our users.
+In Part 1, we came up with a list of security features Commotion lacked. We took this list of unimplemented security features and used OSHA's hazard communication guide to clarify our language[9]:
-Our first change was to move the negative “does not” that is stated in the header into each statement. This ensures that each statement can be read out of context of the whole with full meaning intact and gave us greater freedom in our wording on each line. We then switched the focus from attacks that Commotion does not protect against to consequences that come from lack of feature sets. For example, we removed "malware" in favor of highlighting the result of data and identity insecurity. We then went through each statement to remove jargon/acronyms and make the language more active. WARNING!Commotion:
-In accordance to ANZI "Product Safety Signs and Labels" [10], the term "warning indicates a potentially hazardous situation which, if not avoided, could result in death or serious injury." We felt that this was appropriate for the current non-secure release of Commotion. The next highest level, "danger" is "to be limited to the most extreme situations." We will reserve this warning for our future release of a "secure" Commotion distribution to emphasize the ways in which it does not provide full security. We hope this escalation will signal to users of Commotion for secure communication that they put themselves in danger by assuming security where it does not exist. In the future, as we have translation done on our documentation, we will also work with translators to ensure that region-specific translations are not direct translations, but instead clearly convey the warnings to the users in the most understandable way. With our language solidified, we started on our second question: How do we ensure the "ability of the individual reading [the warning] to understand the information sufficiently to take the desired action"[1] for their specific situation? The first thing that we did was look for existing literature on warning labels in software, which was sorely lacking. So, we turned to warning labels on tobacco, drugs, and dangerous machinery. "A review of the science base to support the development of health warnings for tobacco packages" is an interesting read for its own merit, and was a great resource in helping us ensure that the warning was in the best possible site placement to reach our users.
--
- ...shoppers typically start at the dominant visual element (often the brand name), and are then drawn to the next strongest element (usually the next most dominant visual element).
- A related and important point is that viewing patterns are driven by packaging layout rather than a function of “what people want to look at” or what they think is important. In other words, the fact that a message is frequently missed or overlooked does not mean that shoppers think it is unimportant. It simply means that the message was not adequately highlighted on the package...
- In the few seconds that shoppers typically spend looking at a package, they can actively consider only three or four primary design elements... Research repeatedly found that adding extra messages does not usually increase packaging viewing time, but instead results in more elements fighting for attention in a ‘zero-sum’ game. Package viewing patterns suggest that the “less is more” axiom is nearly always true...
- Package viewing patterns are largely consistent across cultures and product categories because they are driven mainly by human physiology rather than by cultural patterns of preferences.
- Is it important for a packaging design to establish a dominant viewing flow that leads consumers from their “start point” to the other critical packaging elements... What doesn’t work well is a balanced lay out in which the main visual starts consumers in the middle and the other design elements surrounding it are all secondary. The ineffective balanced layout forces consumers to ‘randomly’ choose among directions, and this often causes them to miss important / key elements of the labeling.
Our warning needs to be the main visual element on the page and highlighted above everything else on the screen. Pages that display the warning must have minimal eye-catching elements to ensure that the user is not distracted from the warning. Eye tracking research [8] shows that "users start by reading across the top line and then look down the page a little and read across again and then continue down the left side."[8] Based upon this we decided to place our warning as the topmost content item on the page. This would be the first and most bold item that varies from the generic website themeing. Beyond this placement, we also decided to add a secondary javascript element of this warning when a user loads the downloads page. We added this extra layer on the downloads page because it is the portal for aquireing the software. We felt an additional layer of warning was warranted. This requires the user to click a button stating that "I Understand" to highlight the importance of the warning. We also provided a second button "I DON'T Understand" which sends the user to a more in-depth explanation of the current "in-security" of the current releases. The commotion site has a vibrant design. It has pastel tones and "speech bubble" section dividers. We assume that a user will quickly start to ignore site content that is themed similarly as navigational content. A warning label must stand out from all common site elements in order to ensure that a user sees it as important content. When we looked at research on font use in warnings we found we had used the most effective warning fonts as our generic site fonts. The Commotion site uses AsapRegular, Ariel, or sans-serif depending upon the availability in a users browser. We were left with size and color to visually differentiate our image. We chose a warning header size that was 1.5 larger than our largest header fonts and using all Caps. Lastly we decided that none of the text on the warning could be text converted to an image format. It is important for translation and text-based browsing that this information is available as html & text. While the warning must stand out from the site,we came across a warning that it must not look like advertising as "Users seldom look at banner ads or anything that remotely looks like an advertisement."[8] In order to accomplish this we decided to use a traditional warning color scheme. This was a simple process, as there are common color combinations to go with different warning levels. "Use a red background with white lettering for danger, orange background with black lettering for warning, and yellow background with black lettering for caution to indicate decreasing levels of hazard."[11] This left us with a orange background. The debate over what icon to use for our warning was quickly extinguished by a study cited in the OSHA's hazard communication guide which stated that "The presence of the signal icon had no significant effect on hazard perception." We decided that adding content that did not effect hazard perception, and had the possibility of distracting a user from the important aspects of the message was not worth the possible risk. Now that we have a warning that will clearly convey the required information, we need to ensure that a user take the desired action. The desired action is for users to NOT use Commotion for communication requiring security unless they are layering other secure communication tools on top or along-side it. We hope to ensure this with the “I Don’t Understand” document. By placing links next to each warning bullet point to projects that address the security needs that Commotion we hope to lower the “cost of compliance”[12] to a level where the user does not “give up” and will either pair these technologies with Commotion, if there needs require mesh support, or use a security tool that is appropriate for their needs. The final Commotion warning can be seen on our downloads page. This process was an enlightening one. The most important lesson we learned was that a truly good warning is a clear and simple one. Warning labels have been internationally standardized. Our warning would not seem out of place on the side of dangerous machinery in any country. By following standards developed over years of research we can best ensure that our users take the warning with the gravity that it deserves. Creating tools for privacy comes with a deep responsibility to ones users. In an age where already spun news stories can be chopped into misleading 140 character tweets, and when these ideas make there way in to overheard conversations at parties and conferences, the responsibility falls on us to ensure that the public face that we do control is clear about the perils of our technology. A warning is merely one of the steps that we must take to educate our users.
-Commotion’s first developer release (DR1) is now available for testing. This version replaces our September 2012 pre-release (PR3) and adds several new features. Though Commotion developers tested each component feature, we will begin extensive pre-release testing of the entire DR1 suite in the coming weeks. We hope you will join us in testing the new components. Pre-built Commotion packages for Ubiquiti routers and Android devices can be found at https://commotionwireless.net/download, with DR1 listed under Nightly Builds and PR3 listed as Stable. The download page also provides links to the Commotion source code for those who wish to build their own packages. We have pre-built images for testing on Ubiquiti wireless hardware. The source code includes instructions for building Commotion’s test release on other hardware for those that wish to test on their own devices. The DR1 release brings a complete overhaul to the Commotion system while still ensuring compatibility with PR3 release Commotion nodes. Forward-facing features include a new theme, easy “quickstart” node configuration, application announcement and discovery, and a one-click troubleshooting tool. Behind the scenes, DR1 contains a core Commotion daemon and new cryptographic system. The quickstart tool provides an easy interface for node configuration. The Commotion daemon provides a common mesh network management interface through an embedded library, and forms the core of future Commotion platform development. Commotion’s new application suite uses mDNS to announce local applications across the network. Users can find local applications using the router’s web-based application portal. Node owners can easily manage and customize application portals for better community application support. The application portal integrates the Serval Project’s key management daemon, which provides transparent message encryption and authentication. Finally, the debugging helper creates custom, downloadable documents for offline debugging by network administrators. Each of these tools still requires thorough testing to ensure they are both stable and well documented. If you are an interested user, developer, hacker, or are just plain interested, we would love to hear your feedback. Following initial internal testing, DR1 will undergo lab testing on an eight-node physical test environment. Then we will install on the Open Technology Institute’s (OTI’s) 18-node testbed community network. Once the software is deemed stable, we will deploy it on an active six-node community wireless network for user testing. We will update the documentation to incorporate user feedback once testing is completed. After the build has been thoroughly tested and DR1 has become stable, we will update the warning label on the downloads page to reflect the capabilities and limitations of this release. We will then bring the other Commotion platforms up to feature parity with the DR1 Commotion OpenWRT release.
+Commotion’s first developer release (DR1) is now available for testing. This version replaces our September 2012 pre-release (PR3) and adds several new features. Though Commotion developers tested each component feature, we will begin extensive pre-release testing of the entire DR1 suite in the coming weeks. We hope you will join us in testing the new components. Pre-built Commotion packages for Ubiquiti routers and Android devices can be found at https://commotionwireless.net/download, with DR1 listed under Nightly Builds and PR3 listed as Stable. The download page also provides links to the Commotion source code for those who wish to build their own packages. We have pre-built images for testing on Ubiquiti wireless hardware. The source code includes instructions for building Commotion’s test release on other hardware for those that wish to test on their own devices. The DR1 release brings a complete overhaul to the Commotion system while still ensuring compatibility with PR3 release Commotion nodes. Forward-facing features include a new theme, easy “quickstart” node configuration, application announcement and discovery, and a one-click troubleshooting tool. Behind the scenes, DR1 contains a core Commotion daemon and new cryptographic system. The quickstart tool provides an easy interface for node configuration. The Commotion daemon provides a common mesh network management interface through an embedded library, and forms the core of future Commotion platform development. Commotion’s new application suite uses mDNS to announce local applications across the network. Users can find local applications using the router’s web-based application portal. Node owners can easily manage and customize application portals for better community application support. The application portal integrates the Serval Project’s key management daemon, which provides transparent message encryption and authentication. Finally, the debugging helper creates custom, downloadable documents for offline debugging by network administrators. Each of these tools still requires thorough testing to ensure they are both stable and well documented. If you are an interested user, developer, hacker, or are just plain interested, we would love to hear your feedback. Following initial internal testing, DR1 will undergo lab testing on an eight-node physical test environment. Then we will install on the Open Technology Institute’s (OTI’s) 18-node testbed community network. Once the software is deemed stable, we will deploy it on an active six-node community wireless network for user testing. We will update the documentation to incorporate user feedback once testing is completed. After the build has been thoroughly tested and DR1 has become stable, we will update the warning label on the downloads page to reflect the capabilities and limitations of this release. We will then bring the other Commotion platforms up to feature parity with the DR1 Commotion OpenWRT release.
-Since 2009, wireless mesh enthusiasts and community networking activists from across the globe have come together for a tournament of a social nature: "Wireless Battle of the Mesh". Each battle is held in a different European location, creating a unique series of testbeds for this band of hacktivists and wireless innovators to examine the performance of the various mesh data routing protocols. Wireless mesh projects are judged on many features including network capacity, recovery, and node-discovery. The creators and implementers of protocols such as Babel, B.A.T.M.A.N., BMX, OLSR, and 802.11s come together each year to compete and swap notes and code. This year’s events will be held at the University of Aalborg, Denmark, from Monday, April 15th through Sunday, April 21st. The Open Technology Institute (OTI) sees Battlemesh as a great knowledge sharing event that has, and continues to be, critically important to groundbreaking innovation in the field of wireless mesh networking. Events like these help foster the development of grassroots community networks around the globe. OTI endorses and supports the Battle of the Mesh v6 for its crucial role in advancing the state of the art. OTI will be sending a team of technologists to the Battle of the Mesh to participate in the event’s talks and to help with network setup. OTI will also donate hardware to help extend the pool of available network devices. To see the list of the endorsers or learn more about the project, please visit the main Battlemesh website.
+Since 2009, wireless mesh enthusiasts and community networking activists from across the globe have come together for a tournament of a social nature: "Wireless Battle of the Mesh". Each battle is held in a different European location, creating a unique series of testbeds for this band of hacktivists and wireless innovators to examine the performance of the various mesh data routing protocols. Wireless mesh projects are judged on many features including network capacity, recovery, and node-discovery. The creators and implementers of protocols such as Babel, B.A.T.M.A.N., BMX, OLSR, and 802.11s come together each year to compete and swap notes and code. This year’s events will be held at the University of Aalborg, Denmark, from Monday, April 15th through Sunday, April 21st. The Open Technology Institute (OTI) sees Battlemesh as a great knowledge sharing event that has, and continues to be, critically important to groundbreaking innovation in the field of wireless mesh networking. Events like these help foster the development of grassroots community networks around the globe. OTI endorses and supports the Battle of the Mesh v6 for its crucial role in advancing the state of the art. OTI will be sending a team of technologists to the Battle of the Mesh to participate in the event’s talks and to help with network setup. OTI will also donate hardware to help extend the pool of available network devices. To see the list of the endorsers or learn more about the project, please visit the main Battlemesh website.
-Developer Release 1.1 is the first stable release of the DR1 series. This release is the beginning of our new stable branch, and represents a significant step forward from our previous stable release.
+Commotion release versions represent a target set of features for the entire project. Software packages for individual platforms (Linux, Windows, etc.) may be in different stages of development, and are labeled according to their supported features.
+Currently, only the OpenWRT-based router firmware is DR1 compatible. Other platforms are under active development and are being brought up to feature parity. Current platform revisions can be found on the Official Version Feature Targets page. Pre-compiled software images are available on the Commotion Download page.
+Innumerable fixes and changes went into this release since Preview Release 3 (PR3), the previous stable branch. A complete list can be found on the Commotion project site’s issue tracker.
+Developer Release 1.1 is the first stable release of the DR1 series. This release is the beginning of our new stable branch, and represents a significant step forward from our previous stable release.
-Commotion release versions represent a target set of features for the entire project. Software packages for individual platforms (Linux, Windows, etc.) may be in different stages of development, and are labeled according to their supported features.
-Currently, only the OpenWRT-based router firmware is DR1 compatible. Other platforms are under active development and are being brought up to feature parity. Current platform revisions can be found on the Official Version Feature Targets page. Pre-compiled software images are available on the Commotion Download page.
-Innumerable fixes and changes went into this release since Preview Release 3 (PR3), the previous stable branch. A complete list can be found on the Commotion project site’s issue tracker.
-On an uncharacteristically chilly May morning, members of the Commotion and Serval projects set out for the National Mall in Washington, DC to test Serval's latest piece of hardware: the Mesh Extender. Commotion Wireless is an open-source toolkit of software, documentation, and training materials that strengthens communities by allowing them to build their own local communication infrastructure. Serval is a mesh networking software designed to act as an ad hoc communications network where other infrastructure is either absent or unavailable – such as in remote areas or disaster scenarios. Some of us stood at the Washington Monument while others were at the Lincoln Memorial – a distance of nearly a mile. Using two Mesh Extenders, we successfully sent text messages and shared files between our phones (running Serval) – entirely independent of the cellular infrastructure. On the way back to the office, we hopped on the Metro – DC's subway system – to run another impromptu field test. From opposite ends of the train, we were able to send and receive messages through six subway cars (and their passengers) while the train was moving. That meant we could do something Metro riders usually can't – send and receive messages while in the subway tunnels. These results represent a significant breakthrough, as until now Serval and Commotion have been limited by the relatively short range and low power of Wi-Fi. In addition to increasing range and power, the Mesh Extender removes a major obstacle to widespread adoption of mesh for mobile phones – rooting. Normally a prerequisite for Androids to connect to a mesh network, this technically challenging process for installing a new operating system can cause problems down the road for the rooted phone. In this case, the Mesh Extender routes the messages, not the users' phones, eliminating the need for rooting. However, the Mesh Extender is still a prototype. Software issues make voice calls possible but indecipherable. Further development, including better error correction and noise cancellation, will allow for not only voice calls but potentially even longer-distance connections. Despite these remaining challenges, the Mesh Extender is a huge step towards reliable decentralized infrastructure. A device with multiple radios and a small processor, the Mesh Extender essentially acts as a relay between phones running Serval software. It is lightweight, portable, and relatively cheap and easy to build. The parts can be purchased and assembled for as little as $99. Impressively, the battery can support three to five days of continuous use. The Mesh Extender uses omni-directional antennas (as opposed to point-to-point links), which make for much easier set up and configuration, and allow for truly mobile networks. The Mesh Extender operates simultaneously on the 2.4 GHz and 900 MHz bands, both of which are unlicensed. This allows phones running Serval to tether to the closest Mesh Extender over Wi-Fi (2.4 GHz), while the Mesh Extenders themselves communicate over the 900 MHz band, which is both less congested and has better propagation characteristics.
+On an uncharacteristically chilly May morning, members of the Commotion and Serval projects set out for the National Mall in Washington, DC to test Serval's latest piece of hardware: the Mesh Extender. Commotion Wireless is an open-source toolkit of software, documentation, and training materials that strengthens communities by allowing them to build their own local communication infrastructure. Serval is a mesh networking software designed to act as an ad hoc communications network where other infrastructure is either absent or unavailable – such as in remote areas or disaster scenarios. Some of us stood at the Washington Monument while others were at the Lincoln Memorial – a distance of nearly a mile. Using two Mesh Extenders, we successfully sent text messages and shared files between our phones (running Serval) – entirely independent of the cellular infrastructure. On the way back to the office, we hopped on the Metro – DC's subway system – to run another impromptu field test. From opposite ends of the train, we were able to send and receive messages through six subway cars (and their passengers) while the train was moving. That meant we could do something Metro riders usually can't – send and receive messages while in the subway tunnels. These results represent a significant breakthrough, as until now Serval and Commotion have been limited by the relatively short range and low power of Wi-Fi. In addition to increasing range and power, the Mesh Extender removes a major obstacle to widespread adoption of mesh for mobile phones – rooting. Normally a prerequisite for Androids to connect to a mesh network, this technically challenging process for installing a new operating system can cause problems down the road for the rooted phone. In this case, the Mesh Extender routes the messages, not the users' phones, eliminating the need for rooting. However, the Mesh Extender is still a prototype. Software issues make voice calls possible but indecipherable. Further development, including better error correction and noise cancellation, will allow for not only voice calls but potentially even longer-distance connections. Despite these remaining challenges, the Mesh Extender is a huge step towards reliable decentralized infrastructure. A device with multiple radios and a small processor, the Mesh Extender essentially acts as a relay between phones running Serval software. It is lightweight, portable, and relatively cheap and easy to build. The parts can be purchased and assembled for as little as $99. Impressively, the battery can support three to five days of continuous use. The Mesh Extender uses omni-directional antennas (as opposed to point-to-point links), which make for much easier set up and configuration, and allow for truly mobile networks. The Mesh Extender operates simultaneously on the 2.4 GHz and 900 MHz bands, both of which are unlicensed. This allows phones running Serval to tether to the closest Mesh Extender over Wi-Fi (2.4 GHz), while the Mesh Extenders themselves communicate over the 900 MHz band, which is both less congested and has better propagation characteristics.
-The Open Technology Institute traveled to Dharamshala, India the first week of June for the first international Commotion Wireless workshop. Working with our local hosting partner AirJaldi, we convened over a dozen community technologists from across India and Nepal in the town nestled in the foothills of the Himalayas to get their feedback on OTI’s Commotion mesh technology. The workshop was an opportunity to strengthen not only the recent Developer Release 1.1 of the software, but also a global network of technology designers, implementers, and users who see users and communities as the prime source of innovation in information and communications technology. Some important ideas from the field, conversation, and debate that we brought home with us included:
+ Over the course of the five day workshop, participants built a pilot Commotion network, developed plans for future networks and rallied around a common belief that communities should be able to build and govern their own communications infrastructure. The workshop took place the first week of June at the beautiful Dolma Ling Nunnery, and was co-hosted by AirJaldi, which has partnered on experimental technologies and workshops for many years. The diverse group of participants included network engineers, broadcast engineers, community organizers, educators and policy advocates from AirJaldi, Digital Empowerment Foundation, Gnowledge, IRMA, Janastu, Mahiti, Mojolab, Nepal Wireless, Nomad, and Open Knowledge Foundation. Attendees at the workshop brought visions for community technology, a desire to use mesh wireless in their work, and network plans to solidify. On the first day, we established a common view that building a network is a complex social process, not only (or even primarily) a technical challenge, and that community governance and training are critical components of this process. In addition, by the end of that first day, participants had installed the Commotion software on Ubiquiti wireless routers, learned to configure and mesh those nodes, and then set off on their own to create a mesh network in and around their hotels, linking to the Commotion-powered node installed on the workshop rooftop across town.
Using a shared visual language to plan and design a network. The second day focused on planning mesh networks. Participants used a common visual language developed in our training programs in Detroit to draw plans for the networks they would like to build with Commotion. Later in the day, we went outside to experiment with Servalmessaging (on Android devices), MediaGrid, and Commotion Linux on a mesh network created with battery-powered nodes. We learned a few good lessons about doing too many experimental things at once! On the third and fourth days, the participants split into two teams and went into the field to build a nine node pilot network, combining three medium-distance links with a denser omni-directional mesh in the town of Norbulingka. The AirJaldi network provided two network gateways for Internet access. During the construction and testing process, we found that, even for a small network, there were many interesting complexities. After spending hours in the sun, OTI staff and the participants returned to the workshop space to experiment with Osmocom, an open implementation of the GSM standard for mobile telephony, and other technologies.
We spent so long trying to get the right angle for the long-distance link, we did not even realize it was working, and we had completed the mesh network. The last day involved more experimentation as well as discussions about the regulatory environment in India, and the possibilities for using mesh technology in crisis response. By the end of the workshop, some participants successfully installed Commotion Linux on their laptops, a participant meshed his Raspberry Pi device, and several maps and plans for new networks hung on the wall. We returned with invaluable suggestions for improvements to Commotion, including a list of accessible and affordable routers that we should actively test and support. The workshop discussions were full of memorable visions for the Internet, community technology, and mesh wireless networks, where different groups of participants envisioned:
You never know when you might need a router and a battery pack! Another common thread throughout the workshop was a shared approach to community tech education. Small groups brainstormed the following guidelines:
To this last point, one participant threw his phone to the ground, picked it up and put it back together - all to highlight the need for people to be able to break and fix the technology they rely on. This theme continued throughout the workshop when the network needed troubleshooting or equipment did not work as expected. The process of troubleshooting and experimentation was an important component of the learning, and led to the discovery of a few bugs in the newest DR1.1 release. Even more valuable was the feedback from participants, which will continue to inform the direction of the Commotion project. The ideas and lessons coming out of the workshop are already being applied in the office to the Commotion code, to the training tools we use in our work, and in the networks we partner with in Detroit and Brooklyn. At the end of the week-long workshop the network was working well, and demonstrated the properties of a dynamic mesh by allowing us to connect a portable node as we moved through a grassy field, down the dirt path to a rooftop restaurant to toast our successes and future collaborations.
+The Open Technology Institute traveled to Dharamshala, India the first week of June for the first international Commotion Wireless workshop. Working with our local hosting partner AirJaldi, we convened over a dozen community technologists from across India and Nepal in the town nestled in the foothills of the Himalayas to get their feedback on OTI’s Commotion mesh technology. The workshop was an opportunity to strengthen not only the recent Developer Release 1.1 of the software, but also a global network of technology designers, implementers, and users who see users and communities as the prime source of innovation in information and communications technology. Some important ideas from the field, conversation, and debate that we brought home with us included:
- Over the course of the five day workshop, participants built a pilot Commotion network, developed plans for future networks and rallied around a common belief that communities should be able to build and govern their own communications infrastructure. The workshop took place the first week of June at the beautiful Dolma Ling Nunnery, and was co-hosted by AirJaldi, which has partnered on experimental technologies and workshops for many years. The diverse group of participants included network engineers, broadcast engineers, community organizers, educators and policy advocates from AirJaldi, Digital Empowerment Foundation, Gnowledge, IRMA, Janastu, Mahiti, Mojolab, Nepal Wireless, Nomad, and Open Knowledge Foundation. Attendees at the workshop brought visions for community technology, a desire to use mesh wireless in their work, and network plans to solidify. On the first day, we established a common view that building a network is a complex social process, not only (or even primarily) a technical challenge, and that community governance and training are critical components of this process. In addition, by the end of that first day, participants had installed the Commotion software on Ubiquiti wireless routers, learned to configure and mesh those nodes, and then set off on their own to create a mesh network in and around their hotels, linking to the Commotion-powered node installed on the workshop rooftop across town.
Using a shared visual language to plan and design a network. The second day focused on planning mesh networks. Participants used a common visual language developed in our training programs in Detroit to draw plans for the networks they would like to build with Commotion. Later in the day, we went outside to experiment with Servalmessaging (on Android devices), MediaGrid, and Commotion Linux on a mesh network created with battery-powered nodes. We learned a few good lessons about doing too many experimental things at once! On the third and fourth days, the participants split into two teams and went into the field to build a nine node pilot network, combining three medium-distance links with a denser omni-directional mesh in the town of Norbulingka. The AirJaldi network provided two network gateways for Internet access. During the construction and testing process, we found that, even for a small network, there were many interesting complexities. After spending hours in the sun, OTI staff and the participants returned to the workshop space to experiment with Osmocom, an open implementation of the GSM standard for mobile telephony, and other technologies.
We spent so long trying to get the right angle for the long-distance link, we did not even realize it was working, and we had completed the mesh network. The last day involved more experimentation as well as discussions about the regulatory environment in India, and the possibilities for using mesh technology in crisis response. By the end of the workshop, some participants successfully installed Commotion Linux on their laptops, a participant meshed his Raspberry Pi device, and several maps and plans for new networks hung on the wall. We returned with invaluable suggestions for improvements to Commotion, including a list of accessible and affordable routers that we should actively test and support. The workshop discussions were full of memorable visions for the Internet, community technology, and mesh wireless networks, where different groups of participants envisioned:
You never know when you might need a router and a battery pack! Another common thread throughout the workshop was a shared approach to community tech education. Small groups brainstormed the following guidelines:
To this last point, one participant threw his phone to the ground, picked it up and put it back together - all to highlight the need for people to be able to break and fix the technology they rely on. This theme continued throughout the workshop when the network needed troubleshooting or equipment did not work as expected. The process of troubleshooting and experimentation was an important component of the learning, and led to the discovery of a few bugs in the newest DR1.1 release. Even more valuable was the feedback from participants, which will continue to inform the direction of the Commotion project. The ideas and lessons coming out of the workshop are already being applied in the office to the Commotion code, to the training tools we use in our work, and in the networks we partner with in Detroit and Brooklyn. At the end of the week-long workshop the network was working well, and demonstrated the properties of a dynamic mesh by allowing us to connect a portable node as we moved through a grassy field, down the dirt path to a rooftop restaurant to toast our successes and future collaborations.
-One challenge of working on a software project is showing a non-developer the vibrancy of the code base. Since Commotion is being developed on multiple platforms and through a variety of interacting packages on each platform, we can’t even point at a specific code repository or downloadable to show what work has taken place. We recently became aware of Gource, a open-source project that aims to make this possible. As described on Gource’s website, “Software projects are displayed by Gource as an animated tree with the root directory of the project at its center. Directories appear as branches with files as leaves. Developers can be seen working on the tree at the times they contributed to the project.”
+ +Commotion Development Progress from OTI Web Team on Vimeo. We made some tweaks to gource to remove much of the clutter, including the more than a dozen developers buzzing around the various projects, to make it easier to focus on how our projects have grown in the past couple of years. We do think our developers deserve loads of credit for the hard work that they do (one of us wrote this post).
+One challenge of working on a software project is showing a non-developer the vibrancy of the code base. Since Commotion is being developed on multiple platforms and through a variety of interacting packages on each platform, we can’t even point at a specific code repository or downloadable to show what work has taken place. We recently became aware of Gource, a open-source project that aims to make this possible. As described on Gource’s website, “Software projects are displayed by Gource as an animated tree with the root directory of the project at its center. Directories appear as branches with files as leaves. Developers can be seen working on the tree at the times they contributed to the project.”
- -Commotion Development Progress from OTI Web Team on Vimeo. We made some tweaks to gource to remove much of the clutter, including the more than a dozen developers buzzing around the various projects, to make it easier to focus on how our projects have grown in the past couple of years. We do think our developers deserve loads of credit for the hard work that they do (one of us wrote this post).
-The Open Technology Institute convened over a dozen community technologists from across India and Nepal for the first international Commotion Wireless workshop in June. Over the next several weeks, we will be highlighting their innovative grassroots community technology projects on our blog. Our first guest post is from Mahabir Pun, co-founder of Nepal Wireless Networking Project.
+ + + +Girish Adhikari (l.) and Subash Gurung from Nepal Wireless install a router during the Commotion workshop in Dharamshala.
+ +Nepal Wireless Networking Project was started in the Nangi village of Nepal. Nangi is an isolated village with about 800 residents. People of the village are subsistence farmers and they use primitive farming tools such as wooden plows, iron spades, axes, and sickles etc. Villagers carry all kinds of loads such as supplies, firewood, building materials, composts and others on their back, which they have been doing for centuries. Before 2001, no villager had any idea as what an Internet was or what a computer looked like. There was no telephone or electricity in the villages. The villagers had to walk five to eight hours to the nearest city just to make outside telephone calls. In the absence of modern communication and transportation means, villagers had to use human messengers to send messages from one village to another. In 2001, when the plan was made to connect Nangi village to Pokhara city through Wi-Fi to bring the Internet, the responses from expert communication engineers were negative. Their main concern was with the simple Wi-Fi equipment that we proposed to use, which had transmit power of 60 mW and maximum outdoor range of 100 meters as specified in the manual. The total aerial distance between Nangi and Pokhara was 40 kilometers. Therefore, the communication engineers concluded that it was impossible to connect Nangi village to Pokhara with Wi-Fi. In spite of the negative feedback, the team members of Nepal Wireless decided to continue the experiment. The experiment was conducted for more than a year and was successful to the surprise of the technical experts, who had been skeptical of the project. As for the power needed at the repeater stations, solar panels and wind generators were used to charge the storage batteries. Thus Nepal Wireless Networking Project was born informally in 2002 by connecting a small village using simple Wi-Fi devices and home built antennas. Technically, we were running the network illegally because we had not gotten the licenses that the government of Nepal required at that time. It was almost impossible to import wireless equipment from abroad – we smuggled all the equipment from Singapore and the US. Moreover it was very risky to our lives to bring the equipment and build the network during that period of political conflict in Nepal. We might have been killed or tortured either by the government or insurgent forces if something had gone wrong. Luckily, we survived. In 2006, the political situation stabilized, followed by de-licensing key wireless bands. The team members of the project at the beginning had planned to connect only six villages of one district. However, the demand for the wireless network came from many villages. Therefore we expanded the network to many villages in a time span of over ten years and it is still growing. Now it has connected more than 160 villages of 15 districts of Nepal. The villages that are connected to the network get Internet and intranet services via servers in big cities like Kathmandu and Pokhara, where internet service providers are available. The servers in Kathmandu and Pokhara (200 kilometers apart) are linked through a leased optical fiber line. A series of mountaintop repeater stations relay the signal from the cities up into the mountain villages. Some of the relay stations are built at 4,000 meters or higher in the mountains. There are also access points at the mountaintop relay stations to distribute Internet to end users in the neighboring villages. Villages are connected to the access points using point-to-point or point-to-multipoint wireless. The high-speed backhaul radios at the relay stations operate on a dedicated core local area network (LAN) that reaches from the base stations (Pokhara and Kathmandu) to different areas through relay stations. The longest point-to-point link of the project is 59 kilometers from one mountaintop to another. The distance of the villages from the access points ranges from two kilometers to eighteen kilometers. The districts connected to the network are divided into different subnets in order to manage the network smoothly. Thus the villages in each of the network’s coverage areas from the relay stations operate on separate local LANs through VLAN switches. Routers at each of the relay stations provide DHCP services to the end users. Step by step, we introduced services through different applications such as e-learning, tele-medicine, tele-teaching, tele-training and e-commerce. Many villagers have built communication centers to learn and use the Internet. People are using the Internet for money transfer services because many young people from the villages go to work abroad and send money to their families on a regular basis. Additionally, Nepal Wireless is working with different research groups to monitor glacial lakes, weather, and climate change in the Himalayas. Nepal Wireless is doing some research and development work with different technical groups to develop applications that will be useful for rural people – such as building simple ECG machines for rural clinics, building poacher tracking system in a national park, and implementing systems for the safety of trekkers travelling on the mountain trails . However, the main goal of the project is to bridge the digital divide. Therefore the project is focused more on connecting as many rural schools as possible and providing computer training to the students, school teachers, and villagers. Every year we send university students from Nepal and abroad as volunteers to provide computer training to the people in rural areas. The second area of focus is to provide health services to the villagers of remote areas through tele-medicine. We found this to be urgent because there are no clinics and medical doctors in the remote villages. The project has connected ten rural clinics to a hospital in Kathmandu on the network. The rural health workers communicate with the medical doctors in the city hospital to help the patients in the villages. It runs computer training for the health workers and teaches them how to use computers to connect to the city hospital through video conferencing. Now the main focus of Nepal Wireless Networking Project is to help the villages located in remote Himalayan valleys get connected to the Internet, where no commercial service providers have reached. Nepal Wireless Networking Project has come a long way, but we are still learning how to provide maximum benefit of information technology to poor people living in rural areas.
+The Open Technology Institute convened over a dozen community technologists from across India and Nepal for the first international Commotion Wireless workshop in June. Over the next several weeks, we will be highlighting their innovative grassroots community technology projects on our blog. Our first guest post is from Mahabir Pun, co-founder of Nepal Wireless Networking Project.
- - - -Girish Adhikari (l.) and Subash Gurung from Nepal Wireless install a router during the Commotion workshop in Dharamshala.
- -Nepal Wireless Networking Project was started in the Nangi village of Nepal. Nangi is an isolated village with about 800 residents. People of the village are subsistence farmers and they use primitive farming tools such as wooden plows, iron spades, axes, and sickles etc. Villagers carry all kinds of loads such as supplies, firewood, building materials, composts and others on their back, which they have been doing for centuries. Before 2001, no villager had any idea as what an Internet was or what a computer looked like. There was no telephone or electricity in the villages. The villagers had to walk five to eight hours to the nearest city just to make outside telephone calls. In the absence of modern communication and transportation means, villagers had to use human messengers to send messages from one village to another. In 2001, when the plan was made to connect Nangi village to Pokhara city through Wi-Fi to bring the Internet, the responses from expert communication engineers were negative. Their main concern was with the simple Wi-Fi equipment that we proposed to use, which had transmit power of 60 mW and maximum outdoor range of 100 meters as specified in the manual. The total aerial distance between Nangi and Pokhara was 40 kilometers. Therefore, the communication engineers concluded that it was impossible to connect Nangi village to Pokhara with Wi-Fi. In spite of the negative feedback, the team members of Nepal Wireless decided to continue the experiment. The experiment was conducted for more than a year and was successful to the surprise of the technical experts, who had been skeptical of the project. As for the power needed at the repeater stations, solar panels and wind generators were used to charge the storage batteries. Thus Nepal Wireless Networking Project was born informally in 2002 by connecting a small village using simple Wi-Fi devices and home built antennas. Technically, we were running the network illegally because we had not gotten the licenses that the government of Nepal required at that time. It was almost impossible to import wireless equipment from abroad – we smuggled all the equipment from Singapore and the US. Moreover it was very risky to our lives to bring the equipment and build the network during that period of political conflict in Nepal. We might have been killed or tortured either by the government or insurgent forces if something had gone wrong. Luckily, we survived. In 2006, the political situation stabilized, followed by de-licensing key wireless bands. The team members of the project at the beginning had planned to connect only six villages of one district. However, the demand for the wireless network came from many villages. Therefore we expanded the network to many villages in a time span of over ten years and it is still growing. Now it has connected more than 160 villages of 15 districts of Nepal. The villages that are connected to the network get Internet and intranet services via servers in big cities like Kathmandu and Pokhara, where internet service providers are available. The servers in Kathmandu and Pokhara (200 kilometers apart) are linked through a leased optical fiber line. A series of mountaintop repeater stations relay the signal from the cities up into the mountain villages. Some of the relay stations are built at 4,000 meters or higher in the mountains. There are also access points at the mountaintop relay stations to distribute Internet to end users in the neighboring villages. Villages are connected to the access points using point-to-point or point-to-multipoint wireless. The high-speed backhaul radios at the relay stations operate on a dedicated core local area network (LAN) that reaches from the base stations (Pokhara and Kathmandu) to different areas through relay stations. The longest point-to-point link of the project is 59 kilometers from one mountaintop to another. The distance of the villages from the access points ranges from two kilometers to eighteen kilometers. The districts connected to the network are divided into different subnets in order to manage the network smoothly. Thus the villages in each of the network’s coverage areas from the relay stations operate on separate local LANs through VLAN switches. Routers at each of the relay stations provide DHCP services to the end users. Step by step, we introduced services through different applications such as e-learning, tele-medicine, tele-teaching, tele-training and e-commerce. Many villagers have built communication centers to learn and use the Internet. People are using the Internet for money transfer services because many young people from the villages go to work abroad and send money to their families on a regular basis. Additionally, Nepal Wireless is working with different research groups to monitor glacial lakes, weather, and climate change in the Himalayas. Nepal Wireless is doing some research and development work with different technical groups to develop applications that will be useful for rural people – such as building simple ECG machines for rural clinics, building poacher tracking system in a national park, and implementing systems for the safety of trekkers travelling on the mountain trails . However, the main goal of the project is to bridge the digital divide. Therefore the project is focused more on connecting as many rural schools as possible and providing computer training to the students, school teachers, and villagers. Every year we send university students from Nepal and abroad as volunteers to provide computer training to the people in rural areas. The second area of focus is to provide health services to the villagers of remote areas through tele-medicine. We found this to be urgent because there are no clinics and medical doctors in the remote villages. The project has connected ten rural clinics to a hospital in Kathmandu on the network. The rural health workers communicate with the medical doctors in the city hospital to help the patients in the villages. It runs computer training for the health workers and teaches them how to use computers to connect to the city hospital through video conferencing. Now the main focus of Nepal Wireless Networking Project is to help the villages located in remote Himalayan valleys get connected to the Internet, where no commercial service providers have reached. Nepal Wireless Networking Project has come a long way, but we are still learning how to provide maximum benefit of information technology to poor people living in rural areas.
-A new video about the Open Technology Institute’s approach to training, community, and technology, using the Commotion Wireless toolkit to support communities’ to take control of their own communications infrastructure. The video highlights the work of the Digital Stewards programs in Detroit and Brooklyn, and the sharing of those training resources and the Commotion technology at a workshop in Dharamshala, India.
+ +A new video about the Open Technology Institute’s approach to training, community, and technology, using the Commotion Wireless toolkit to support communities’ to take control of their own communications infrastructure. The video highlights the work of the Digital Stewards programs in Detroit and Brooklyn, and the sharing of those training resources and the Commotion technology at a workshop in Dharamshala, India.
- -Tiwan Burrus (RHI) and Katherine Ortiz (RHI) attaching a Pico Station to a roof mount.
+ +A 20-computer public computer center hosted at the New York City Housing Authority’s (NYCHA) Miccio Recreation Center now has Internet access following a day of installations by young adults trained by the Open Technology Institute (OTI), the Red Hook Initiative (RHI) and Brooklyn Fiber. Five Red Hook Digital Stewards, young adults engaged in a New York City workforce development effort, installed 6 new wireless routers into the Red Hook WiFi network in the beginning of July 2013. The Stewards connected two new partner institutions to RHI’s existing Red Hook Network with these installations - adding a local school and the NYCHA Miccio Recreation Center to a set of partners including churches, local residents and the Red Hook Initiative’s building. The public areas surrounding these buildings now have access to the Internet as well as local applications running on the neighborhood website. Area of expansion marked in Green. Full Map of Current Coverage: http://goo.gl/maps/2r6np This expansion involved moving the backbone Internet gateway to a new location and setting up a static route configuration to connect the computer center into the mesh network. By moving the Internet gateway to a higher roof, the router now has a better line of sight to the church four blocks away where there are additional Commotion nodes and BK Fiber Internet points of presence. The Stewards set up a static route to enable meshing over ethernet between two directional routers facing away from each other, which allows the Internet gateway to be shared with the computer center at the NYCHA Miccio Recreation Center. There are multiple ways to configure a setup along these lines, but after planning and sketching options, the team decided that this was the best solution. Sketch of configuration plan (left). The team – Eric Vesler (BKFiber), Anthony Evans (RHI), Will Hawkins (OTI, and Nijel Johnson (RHI) – huddling to set the static routes (right). The Digital Stewards have been focusing on learning these skills – installation, configuration, networking, maintenance – during their work the past few months. With this installation, the stewards tested those skills and led the installation process, while OTI team members, Will Hawkins and Georgia Bullen, were available to assist. Following the installations at AMC, the stewards felt prepared and excited to build out the network more in their neighborhood of Red Hook. Looking ahead, the Stewards are thinking about outreach events and training to provide assistance to local residents who want to learn more about how to use the Internet and access valuable resources online, as well as additional installations in the neighborhood in August. Tiwan Burrus (RHI) stringing out cable for a router.
+Tiwan Burrus (RHI) and Katherine Ortiz (RHI) attaching a Pico Station to a roof mount.
- -A 20-computer public computer center hosted at the New York City Housing Authority’s (NYCHA) Miccio Recreation Center now has Internet access following a day of installations by young adults trained by the Open Technology Institute (OTI), the Red Hook Initiative (RHI) and Brooklyn Fiber. Five Red Hook Digital Stewards, young adults engaged in a New York City workforce development effort, installed 6 new wireless routers into the Red Hook WiFi network in the beginning of July 2013. The Stewards connected two new partner institutions to RHI’s existing Red Hook Network with these installations - adding a local school and the NYCHA Miccio Recreation Center to a set of partners including churches, local residents and the Red Hook Initiative’s building. The public areas surrounding these buildings now have access to the Internet as well as local applications running on the neighborhood website. Area of expansion marked in Green. Full Map of Current Coverage: http://goo.gl/maps/2r6np This expansion involved moving the backbone Internet gateway to a new location and setting up a static route configuration to connect the computer center into the mesh network. By moving the Internet gateway to a higher roof, the router now has a better line of sight to the church four blocks away where there are additional Commotion nodes and BK Fiber Internet points of presence. The Stewards set up a static route to enable meshing over ethernet between two directional routers facing away from each other, which allows the Internet gateway to be shared with the computer center at the NYCHA Miccio Recreation Center. There are multiple ways to configure a setup along these lines, but after planning and sketching options, the team decided that this was the best solution. Sketch of configuration plan (left). The team – Eric Vesler (BKFiber), Anthony Evans (RHI), Will Hawkins (OTI, and Nijel Johnson (RHI) – huddling to set the static routes (right). The Digital Stewards have been focusing on learning these skills – installation, configuration, networking, maintenance – during their work the past few months. With this installation, the stewards tested those skills and led the installation process, while OTI team members, Will Hawkins and Georgia Bullen, were available to assist. Following the installations at AMC, the stewards felt prepared and excited to build out the network more in their neighborhood of Red Hook. Looking ahead, the Stewards are thinking about outreach events and training to provide assistance to local residents who want to learn more about how to use the Internet and access valuable resources online, as well as additional installations in the neighborhood in August. Tiwan Burrus (RHI) stringing out cable for a router.
-Developer Release 2 is the latest stable release of the Commotion platform. It features a focus on improved features around network management, including initial compatibility with external visualization tools and internationalization support.
+Commotion release versions represent a target set of features for the entire project. Software packages for individual platforms (Linux, Windows, etc.) may be in different stages of development, and are labeled according to their supported features.
+Currently, only the OpenWRT-based router firmware is DR2 compatible. Other platforms are under active development and are being brought up to feature parity. Current platform revisions can be found on the Official Version Feature Targets page. Pre-compiled software images are available on the Commotion Download page.
+As always, a large number of fixes and changes went into this release since DR1.1, the previous stable branch. We’re currently in the process of overhauling our issue tracking system to use Github, so expect an updated list of fixes soon.
+We were planning on rolling out new default IP addressing ranges and dynamic BSSID selection with this release, but we decided it needed more testing and thought given to a smooth rollout. Look for that in a point release coming soon! Also, within the next couple of weeks we’ll be rolling out new testing releases of our Linux and Android versions compatible with DR1 and above.
+Developer Release 2 is the latest stable release of the Commotion platform. It features a focus on improved features around network management, including initial compatibility with external visualization tools and internationalization support.
-Commotion release versions represent a target set of features for the entire project. Software packages for individual platforms (Linux, Windows, etc.) may be in different stages of development, and are labeled according to their supported features.
-Currently, only the OpenWRT-based router firmware is DR2 compatible. Other platforms are under active development and are being brought up to feature parity. Current platform revisions can be found on the Official Version Feature Targets page. Pre-compiled software images are available on the Commotion Download page.
-As always, a large number of fixes and changes went into this release since DR1.1, the previous stable branch. We’re currently in the process of overhauling our issue tracking system to use Github, so expect an updated list of fixes soon.
-We were planning on rolling out new default IP addressing ranges and dynamic BSSID selection with this release, but we decided it needed more testing and thought given to a smooth rollout. Look for that in a point release coming soon! Also, within the next couple of weeks we’ll be rolling out new testing releases of our Linux and Android versions compatible with DR1 and above.
-During a lunch hour in downtown Washington, DC, the Open Technology Institute set up a proof of concept network for distributing Internet service to a public space using a mesh network of multiple mobile routers. Such a network would be useful where there is a sudden need for Internet connectivity, such as a spontaneous event, or conditions that prevent permanent network installation for a planned event. The same network configuration would work for a mobile event, such as a march, although the deployment team did not test for that scenario in this instance. The deployment team used the 25-Sep-2013 Nightly build of Commotion OpenWRT running on Ubiquiti’s omnidirectional Picostation router, with four routers powered by Energizer XP8000 battery packs. The team connected one router to the Internet in OTI’s office at 1899 L St NW and placed it in the south-facing 5th floor window. Team members took the battery-powered routers to nearby intersections to assess the functionality of the firmware, the link quality between the nodes, and the quality of the Internet service at the far point in the network, which was four hops from the gateway (see illustration below). Approximate location of nodes in the pop-up network. The ad hoc mesh network delivered Internet connectivity to Farragut Square Park from the Open Technology Institute’s 5th floor office several blocks away.
++
OTI team installed a gateway node on the 5th floor glass window of the office building. Then, four team members connected their four respective picostations to battery packs and carried them in backpacks and purses. The team left the first member of the team with the first router, or node, 33 feet away from the gateway node at 1828 L St NW at ground level. They was able to access the Internet through the mesh network at this point. The remaining team members then walked south towards K St NW along 19th St NW to leave the next team member with the second node 500 feet away from the first node. The team ran “Fing”, a network toolkit, on their phones/mobile devices to note if they were able to ping each other’s nodes. The team was also able to access the Internet on their phones through the mesh at this point. Splash page when the team accessed the Internet using the mesh network Using Fing, the team can monitor details of the access point and users of the access point Using Fing, the team can ping other users of the mesh network. The remaining team walked east on K St NW towards 18th St NW, and left the third member with the third node 250 feet away from the second node at 1801 K St NW. The team was still able to get to the Internet using the mesh network which was now three hops (nodes) away from the gateway node. Finally, the team continued east towards Farragut Square on K St NW, with the fourth node in the team member’s purse, 0.1 miles away from the third node. The devices were still connected to each other via the mesh network but the signals were weaker, now that we were four hops and 0.3 miles away from the gateway node on a very busy street. When we raised the fourth access point to a higher level, the connection between nodes three and four improved. Using OLSR-Viz, we see that the connection between the access points is weaker when 4 hops and 0.3 miles away.
+ + + +The fourth access point is now raised in position at Farragut Square park
+ + + +OLSR-Viz shows that the connection gets better when the fourth Picostation is raised so there is better line of sight between the third access point and itself.
+ +At Farragut square park, getting to the Internet was more challenging and slower. At one point during the experiment, all the connections on the mesh network were captured on OLSR-Viz (image below). OLSR-Viz shows the four access points in an “L” shape to the right side of the gateway node. The two other nodes forming a smaller mesh network to the left side of the gateway node are access points located in the OTI office on the same mesh network.
+During a lunch hour in downtown Washington, DC, the Open Technology Institute set up a proof of concept network for distributing Internet service to a public space using a mesh network of multiple mobile routers. Such a network would be useful where there is a sudden need for Internet connectivity, such as a spontaneous event, or conditions that prevent permanent network installation for a planned event. The same network configuration would work for a mobile event, such as a march, although the deployment team did not test for that scenario in this instance. The deployment team used the 25-Sep-2013 Nightly build of Commotion OpenWRT running on Ubiquiti’s omnidirectional Picostation router, with four routers powered by Energizer XP8000 battery packs. The team connected one router to the Internet in OTI’s office at 1899 L St NW and placed it in the south-facing 5th floor window. Team members took the battery-powered routers to nearby intersections to assess the functionality of the firmware, the link quality between the nodes, and the quality of the Internet service at the far point in the network, which was four hops from the gateway (see illustration below). Approximate location of nodes in the pop-up network. The ad hoc mesh network delivered Internet connectivity to Farragut Square Park from the Open Technology Institute’s 5th floor office several blocks away.
--
OTI team installed a gateway node on the 5th floor glass window of the office building. Then, four team members connected their four respective picostations to battery packs and carried them in backpacks and purses. The team left the first member of the team with the first router, or node, 33 feet away from the gateway node at 1828 L St NW at ground level. They was able to access the Internet through the mesh network at this point. The remaining team members then walked south towards K St NW along 19th St NW to leave the next team member with the second node 500 feet away from the first node. The team ran “Fing”, a network toolkit, on their phones/mobile devices to note if they were able to ping each other’s nodes. The team was also able to access the Internet on their phones through the mesh at this point. Splash page when the team accessed the Internet using the mesh network Using Fing, the team can monitor details of the access point and users of the access point Using Fing, the team can ping other users of the mesh network. The remaining team walked east on K St NW towards 18th St NW, and left the third member with the third node 250 feet away from the second node at 1801 K St NW. The team was still able to get to the Internet using the mesh network which was now three hops (nodes) away from the gateway node. Finally, the team continued east towards Farragut Square on K St NW, with the fourth node in the team member’s purse, 0.1 miles away from the third node. The devices were still connected to each other via the mesh network but the signals were weaker, now that we were four hops and 0.3 miles away from the gateway node on a very busy street. When we raised the fourth access point to a higher level, the connection between nodes three and four improved. Using OLSR-Viz, we see that the connection between the access points is weaker when 4 hops and 0.3 miles away.
- - - -The fourth access point is now raised in position at Farragut Square park
- - - -OLSR-Viz shows that the connection gets better when the fourth Picostation is raised so there is better line of sight between the third access point and itself.
- -At Farragut square park, getting to the Internet was more challenging and slower. At one point during the experiment, all the connections on the mesh network were captured on OLSR-Viz (image below). OLSR-Viz shows the four access points in an “L” shape to the right side of the gateway node. The two other nodes forming a smaller mesh network to the left side of the gateway node are access points located in the OTI office on the same mesh network.
-WASHINGTON, DC — New America Foundation’s Open Technology Institute (OTI) today released the first round of its Commotion Construction Kit, a “do it ourselves” guide for building wireless communications infrastructure. The materials are part of the Commotion project, an open-source communications toolkit that uses mobile phones, computers, and other wireless devices to create decentralized mesh networks and share local services. “In an age of pervasive government surveillance and corporate data mining, the Commotion project is an essential resource for taking control of our communications and data,” saidJoshua Breitbart, Director of Field Operations at OTI. “With the guides we are publishing today, you do not have to be a techie or engineer to build a wireless network with your neighbors.” These documents come from the Commotion project’s effort to design tools and resources that facilitate participatory planning and development of community-controlled communications infrastructure. They are divided into five sections: Planning, Installating and Configurating, Networking, Building and Mounting, and Local Applications. Individuals or groups can use the materials for self-guided learning or to teach workshops or trainings. While some modules are Commotion-specific, many are useful for a variety of community-based technology or communications efforts. OTI developed and piloted the first Commotion Construction Kit elements in partnership with community-based training programs in Detroit and Brooklyn—the Digital Stewards training programs at Allied Media Projects and the Red Hook Initiative. The Work Department, also in Detroit, helped to design the visual language of the tools. Commotion’s first international training in Dharamshala, India provided the opportunity to expand the Commotion Construction Kit and evaluate it in collaboration with community technologists from around India and Nepal. The materials will be shared at the upcoming International Summit for Community Wireless Networks in Berlin, to contribute to the global movement for community-controlled communications and technology. Like the Commotion software, these materials are open source, which means development on them continues and community involvement is critical. This first wave of modules represents a work in progress. OTI welcomes all feedback on these materials and will collaboratively expand and update them. View and download the Commotion Construction Kit on the Commotion website.
+WASHINGTON, DC — New America Foundation’s Open Technology Institute (OTI) today released the first round of its Commotion Construction Kit, a “do it ourselves” guide for building wireless communications infrastructure. The materials are part of the Commotion project, an open-source communications toolkit that uses mobile phones, computers, and other wireless devices to create decentralized mesh networks and share local services. “In an age of pervasive government surveillance and corporate data mining, the Commotion project is an essential resource for taking control of our communications and data,” saidJoshua Breitbart, Director of Field Operations at OTI. “With the guides we are publishing today, you do not have to be a techie or engineer to build a wireless network with your neighbors.” These documents come from the Commotion project’s effort to design tools and resources that facilitate participatory planning and development of community-controlled communications infrastructure. They are divided into five sections: Planning, Installating and Configurating, Networking, Building and Mounting, and Local Applications. Individuals or groups can use the materials for self-guided learning or to teach workshops or trainings. While some modules are Commotion-specific, many are useful for a variety of community-based technology or communications efforts. OTI developed and piloted the first Commotion Construction Kit elements in partnership with community-based training programs in Detroit and Brooklyn—the Digital Stewards training programs at Allied Media Projects and the Red Hook Initiative. The Work Department, also in Detroit, helped to design the visual language of the tools. Commotion’s first international training in Dharamshala, India provided the opportunity to expand the Commotion Construction Kit and evaluate it in collaboration with community technologists from around India and Nepal. The materials will be shared at the upcoming International Summit for Community Wireless Networks in Berlin, to contribute to the global movement for community-controlled communications and technology. Like the Commotion software, these materials are open source, which means development on them continues and community involvement is critical. This first wave of modules represents a work in progress. OTI welcomes all feedback on these materials and will collaboratively expand and update them. View and download the Commotion Construction Kit on the Commotion website.
-The Open Technology Institute recently conducted a training on how to build pop-up mesh networks using Commotion. Our goal was to quickly deploy a flexible and mobile mesh network across several square blocks using portable battery-powered routers carried in backpacks. Commotion’s dynamic routing allows a network to shift and transform with the movements of the people, creating a highly resilient temporary infrastructure that can distribute Internet access throughout an area or support local area communications and data sharing. In this blogpost, we describe three field trials conducted by participants during the training. In the field trials we used Ubiquiti omnidirectional PicoStation M2 routers and Energizer XP8000 battery packs. These battery packs are compact and able to provide 3-4 hours of power to the routers, but any battery pack that meets the power requirements of the router would suffice - for example, the PicoStations can run on voltages from 15 to 24 volts. The battery packs supply 20 volts. Refer to the voltage markings on your router’s power supply before choosing a battery. At the beginning of the training, participants learned how to install and configure Commotion, mesh several routers together and assess link quality. With these skills, participants went outside and tested the potential reach of the signal at street level of two routers powered by portable battery packs. Ubiquiti estimates that PicoStations can cover up to 500 meters, but every environment has different properties that impact wireless propagation. As with permanent rooftop wireless networks, pop-up networks are impacted by buildings, vegetation, line of sight and other wireless barriers. Street level networks are also impacted by traffic, parked cars, crowds of people and small hills. In these distance tests, participants found that link quality degraded after approximately 200 meters and broke at approximately 300 meters apart. This estimate proved consistent with our previous fields test near the Open Technology Institute’s offices, although we were in a different location. Participants monitored link quality with their smartphones using the Commotion interface to see ETX values and signal strength and Fing to measure ping times.
++ | + |
Map 1: Two node distance test. We repeated the distance tests and link monitoring exercises, which helped participants develop an intuitive sense of network planning and management. We developed these skills further with our interactive network design and engineering activities, “Wireless Challenges” and “Every Network Tells A Story,” before moving on to more complex network configurations. Participants then created a network and connected it to the Internet through a gateway Commotion node in a window attached to an ADSL Internet connection. Participants tested this new connection across a more diverse streetscape, adding more nodes to the network. With an Internet gateway on the mesh, participants and OTI staff were able to make VOIP calls and check email while spread out along the street corners. Participants spread out along the streets until each network connection became weak, inhibiting those online activities. Participants found that traffic and parked cars negatively impacted the maximum link distance and used the skills from the earlier activities to solve those problems. The network is shown in Map 2. Map 2: 6 node field trial with Internet gateway. In the third field trial, participants deployed a network to cover a larger street in a more crowded area and extend the network into smaller side streets. Participants stationed individuals and their portable mesh nodes at particular corners, establishing a stationary backbone of the network. Other participants were roaming nodes; they walked along the back streets to establish network coverage along those streets and experiment with dynamically changing the network. The general configuration is shown in Map 3, as are network statistics captured during the field trial. Map 3: 8 node field trial with 7 people remaining relatively stationary and two people moving throughout the area. In this configuration, node 50 moved throughout the network while other nodes remained relatively stationary. Nodes 37 and 182 occasionally had difficulty maintaining connections to the rest of the network. This was both because it was difficult to stand within line of sight, and because those participants had less field experience adjusting their position to improve network performance. Image 1: Network visualized with ETX values at point [4] (the last digits of the IP address correspond to the numbers in the map). Image 2: Network visualized with ETX values at point [6] (the last digits of the IP address correspond to the numbers in the map). Image 3: Network visualized with ETX values at point [7] (the last digits of the IP address correspond to the numbers in the map). In this field trial, we did not have an available Internet gateway, but instead, used MediaGrid to facilitate local secure communications across the mesh network. During this exercise, we had MediaGrid running on a single laptop in the network. However, MediaGrid has the ability to sync across multiple laptops, which increases the resilience of the network. MediaGrid has a chat feature that allowed the deployment team to discuss changes to the network node position and report link quality and signal strength over the local area network.
++ | + |
Image 4: Screenshots of the MediaGrid mobile web interface. While we ran a local application on the network for these experiments, the network could also be connected to a 3G modem, an Internet gateway inside of a building, or a long distance link to another part of the city. The field experiments resulted in the following conclusions:
+The Commotion project is currently working on the Commotion Construction Kit, a set of tools that the Open Technology Institute has used in trainings around the world and at home. It is a “do it ourselves” guide to building wireless mesh networks. They are a work in progress, so check back frequently for updates. We welcome feedback and experimentation! These field experiments were conducted using Commotion Developer Release 2, and the network was configured to use WPA2-PSK to encrypt the traffic.
+The Open Technology Institute recently conducted a training on how to build pop-up mesh networks using Commotion. Our goal was to quickly deploy a flexible and mobile mesh network across several square blocks using portable battery-powered routers carried in backpacks. Commotion’s dynamic routing allows a network to shift and transform with the movements of the people, creating a highly resilient temporary infrastructure that can distribute Internet access throughout an area or support local area communications and data sharing. In this blogpost, we describe three field trials conducted by participants during the training. In the field trials we used Ubiquiti omnidirectional PicoStation M2 routers and Energizer XP8000 battery packs. These battery packs are compact and able to provide 3-4 hours of power to the routers, but any battery pack that meets the power requirements of the router would suffice - for example, the PicoStations can run on voltages from 15 to 24 volts. The battery packs supply 20 volts. Refer to the voltage markings on your router’s power supply before choosing a battery. At the beginning of the training, participants learned how to install and configure Commotion, mesh several routers together and assess link quality. With these skills, participants went outside and tested the potential reach of the signal at street level of two routers powered by portable battery packs. Ubiquiti estimates that PicoStations can cover up to 500 meters, but every environment has different properties that impact wireless propagation. As with permanent rooftop wireless networks, pop-up networks are impacted by buildings, vegetation, line of sight and other wireless barriers. Street level networks are also impacted by traffic, parked cars, crowds of people and small hills. In these distance tests, participants found that link quality degraded after approximately 200 meters and broke at approximately 300 meters apart. This estimate proved consistent with our previous fields test near the Open Technology Institute’s offices, although we were in a different location. Participants monitored link quality with their smartphones using the Commotion interface to see ETX values and signal strength and Fing to measure ping times.
-- | - |
Map 1: Two node distance test. We repeated the distance tests and link monitoring exercises, which helped participants develop an intuitive sense of network planning and management. We developed these skills further with our interactive network design and engineering activities, “Wireless Challenges” and “Every Network Tells A Story,” before moving on to more complex network configurations. Participants then created a network and connected it to the Internet through a gateway Commotion node in a window attached to an ADSL Internet connection. Participants tested this new connection across a more diverse streetscape, adding more nodes to the network. With an Internet gateway on the mesh, participants and OTI staff were able to make VOIP calls and check email while spread out along the street corners. Participants spread out along the streets until each network connection became weak, inhibiting those online activities. Participants found that traffic and parked cars negatively impacted the maximum link distance and used the skills from the earlier activities to solve those problems. The network is shown in Map 2. Map 2: 6 node field trial with Internet gateway. In the third field trial, participants deployed a network to cover a larger street in a more crowded area and extend the network into smaller side streets. Participants stationed individuals and their portable mesh nodes at particular corners, establishing a stationary backbone of the network. Other participants were roaming nodes; they walked along the back streets to establish network coverage along those streets and experiment with dynamically changing the network. The general configuration is shown in Map 3, as are network statistics captured during the field trial. Map 3: 8 node field trial with 7 people remaining relatively stationary and two people moving throughout the area. In this configuration, node 50 moved throughout the network while other nodes remained relatively stationary. Nodes 37 and 182 occasionally had difficulty maintaining connections to the rest of the network. This was both because it was difficult to stand within line of sight, and because those participants had less field experience adjusting their position to improve network performance. Image 1: Network visualized with ETX values at point [4] (the last digits of the IP address correspond to the numbers in the map). Image 2: Network visualized with ETX values at point [6] (the last digits of the IP address correspond to the numbers in the map). Image 3: Network visualized with ETX values at point [7] (the last digits of the IP address correspond to the numbers in the map). In this field trial, we did not have an available Internet gateway, but instead, used MediaGrid to facilitate local secure communications across the mesh network. During this exercise, we had MediaGrid running on a single laptop in the network. However, MediaGrid has the ability to sync across multiple laptops, which increases the resilience of the network. MediaGrid has a chat feature that allowed the deployment team to discuss changes to the network node position and report link quality and signal strength over the local area network.
-- | - |
Image 4: Screenshots of the MediaGrid mobile web interface. While we ran a local application on the network for these experiments, the network could also be connected to a 3G modem, an Internet gateway inside of a building, or a long distance link to another part of the city. The field experiments resulted in the following conclusions:
-The Commotion project is currently working on the Commotion Construction Kit, a set of tools that the Open Technology Institute has used in trainings around the world and at home. It is a “do it ourselves” guide to building wireless mesh networks. They are a work in progress, so check back frequently for updates. We welcome feedback and experimentation! These field experiments were conducted using Commotion Developer Release 2, and the network was configured to use WPA2-PSK to encrypt the traffic.
-I had heard about mesh networking before I arrived in Somaliland, but had never been in the position to actually build a mesh network. When I accepted the position as ICT instructor at Abaarso School of Science and Technology in Abaarso, Somaliland, I figured this may be my chance. I knew that the Open Technology Institute (OTI) had been developing a mesh firmware called Commotion, suitable for remote locations. Upon arriving in Somaliland I decided that building a mesh network using Commotion would be one of my top priorities.
It seemed like building a mesh network could be a difficult process. I experimented in the past with other firmware on a variety of routers, but found the configuration to be too time-consuming and difficult to set up. I knew Commotion ran on Ubiquti hardware, designed for rough outdoor environments like Somaliland. Unfortunately, finding Ubiquiti routers in Somaliland – for that matter, getting anything into Somaliland – is no easy task.
Somaliland is an independent autonomous region of Somalia, and is an area that is safe compared to the southern regions of Somalia. While not internationally recognized as a country, Somaliland has its own currency, government, and military.
The analogy I like to use when it comes to traveling to Somaliland is no different than that of getting to Hogwarts. Instead of running head first into an imaginary platform at the train station, you have to land in Dubai, catch a flight that leaves only once a week and then travel across a desert on one of the worst-built roads you can imagine.
While back in the US this past summer I contacted OTI and found that they would be able to provide me with the proper equipment to run and set up a mesh network using Commotion. I was so excited about the possibility of actually getting all of the equipment into Somaliland that I carefully packed everything into my carry-on.
Before I go any further, I should explain my level of experience with building networks. My only experience with networking had been taking a class at a community college in San Francisco and spending the last year troubleshooting our Internet problems at school. However, Commotion is built in such a way that little if any advanced configuration is necessary to set up a mesh network. I first began building my network by identifying where I wanted access points on campus and mapping out distances between each spot. Having a good line of sight between each node was extremely important. Luckily we have a lot of high guard and water towers on campus so placing nodes was not an issue.
One minor problem with placing nodes in towers was that I had to ensure a reliable power source was within range of the node. If all my nodes were solar-powered, I would not have had to worry about running any cable at all!
I next had to “flash” each router, which means loading the Commotion firmware on to each Ubiquti device. I had experience flashing firmware onto routers before but had never “meshed” wireless nodes together. To help with this I referred to the configuration examples on Commotion’s website, which I found extremely helpful. Open source software has been known to be tricky to configure and maintain but it certainly does not have to be. Commotion has proved this to be more than true.
While building the network, I made sure to include students as much as I could. I assembled together a computer club of my top ICT students to discuss and teach the basics of mesh networking, how to flash firmware onto routers, and how to add a node to the network. Together we ran cable and climbed water towers to place the nodes in their proper places. We also had to place some nodes in the guard towers which often times, the guards would unplug accidentally. Students trained the guards on the difference between the LAN and PoE ports as well as the importance of keeping the PoE cable plugged in at all times. A few weeks after school we put up the last two nodes for the girls’ dorms and the boys’ dorms.
Local Applications and Limited Bandwidth
Somaliland is currently the only country in Africa that lacks fiber optic access – cables are laid but access is not predicted to be available until 2014. Somaliland receives its Internet connection via microwaves across the desert from Djibouti. All of the IP address ranges in Somaliland will tell you that you are in Djibouti. The distant gateway connectivity, not to mention unreliable ISPs, equates to some seriously slow Internet.
http://www.ubuntunet.net/sites/ubuntunet.net/files/Intra-Africa_Fibre_Map_v6.pdf © UbuntuNet Alliance; Creative Commons 3.0
A lack of consistent access to the Internet is an ICT instructor’s nightmare. Not being able to teach the most current technologies can be frustrating, and it also hampers sharing files with students. Mesh networking is described as a “peer to peer network:” I wanted to use the full sense of the term and make file sharing among my students easy and manageable. In order to solve this communication problem I decided to rely less on the outside Internet and rely more on local applications installed on our servers. I found the solution to our inconsistent and slow Internet by installing OwnCloud, an open source alternative to Dropbox, on our local server. Now students could share homework assignments with me and other teachers without having to rely on the Internet at all.
Creating a Self-Sufficient Network
As well as the network worked and as much fun as setting it up was, I cannot call this project successful until I can come back to Somaliland a year from now and see the same nodes in place running the same network. I used a few methods to make sure this would be the case. I was careful to document every aspect of the project and create detailed guides for teachers and future network administrators on everything from how to find your IP address on the network to how to ping a node, which is important for isolating a potential problem on the network. Even though mesh networks are “self-healing”, they are not perfect and still have their quirks.
Having all of the knowledge centered in one place with one staff member will only set an organization up for failure, so I’ve made sure to give a series of small trainings to the entire staff. The more transparent you are about how the network works, the more likely the technology will last.
I repeatedly told my students that some of the greatest makers and technologists of our time were self-taught. The excellent support community centered around open source software makes projects such as Commotion sustainable. There is a good chance that if a problem arises, someone else already had that issue or someone in another community across the globe is working on a solution to that problem. I would like to give my sincere gratitude to the Commotion Wireless Project for the support they gave me along with providing me with necessary tools to build this network. Not only did the students at Abaarso School get extremely enthused about mesh networking and learn the meaning of community technology, but now another small part of a country that, technically, does not even exist is more connected to the rest of the world.
I had heard about mesh networking before I arrived in Somaliland, but had never been in the position to actually build a mesh network. When I accepted the position as ICT instructor at Abaarso School of Science and Technology in Abaarso, Somaliland, I figured this may be my chance. I knew that the Open Technology Institute (OTI) had been developing a mesh firmware called Commotion, suitable for remote locations. Upon arriving in Somaliland I decided that building a mesh network using Commotion would be one of my top priorities.
It seemed like building a mesh network could be a difficult process. I experimented in the past with other firmware on a variety of routers, but found the configuration to be too time-consuming and difficult to set up. I knew Commotion ran on Ubiquti hardware, designed for rough outdoor environments like Somaliland. Unfortunately, finding Ubiquiti routers in Somaliland – for that matter, getting anything into Somaliland – is no easy task.
Somaliland is an independent autonomous region of Somalia, and is an area that is safe compared to the southern regions of Somalia. While not internationally recognized as a country, Somaliland has its own currency, government, and military.
The analogy I like to use when it comes to traveling to Somaliland is no different than that of getting to Hogwarts. Instead of running head first into an imaginary platform at the train station, you have to land in Dubai, catch a flight that leaves only once a week and then travel across a desert on one of the worst-built roads you can imagine.
While back in the US this past summer I contacted OTI and found that they would be able to provide me with the proper equipment to run and set up a mesh network using Commotion. I was so excited about the possibility of actually getting all of the equipment into Somaliland that I carefully packed everything into my carry-on.
Before I go any further, I should explain my level of experience with building networks. My only experience with networking had been taking a class at a community college in San Francisco and spending the last year troubleshooting our Internet problems at school. However, Commotion is built in such a way that little if any advanced configuration is necessary to set up a mesh network. I first began building my network by identifying where I wanted access points on campus and mapping out distances between each spot. Having a good line of sight between each node was extremely important. Luckily we have a lot of high guard and water towers on campus so placing nodes was not an issue.
One minor problem with placing nodes in towers was that I had to ensure a reliable power source was within range of the node. If all my nodes were solar-powered, I would not have had to worry about running any cable at all!
I next had to “flash” each router, which means loading the Commotion firmware on to each Ubiquti device. I had experience flashing firmware onto routers before but had never “meshed” wireless nodes together. To help with this I referred to the configuration examples on Commotion’s website, which I found extremely helpful. Open source software has been known to be tricky to configure and maintain but it certainly does not have to be. Commotion has proved this to be more than true.
While building the network, I made sure to include students as much as I could. I assembled together a computer club of my top ICT students to discuss and teach the basics of mesh networking, how to flash firmware onto routers, and how to add a node to the network. Together we ran cable and climbed water towers to place the nodes in their proper places. We also had to place some nodes in the guard towers which often times, the guards would unplug accidentally. Students trained the guards on the difference between the LAN and PoE ports as well as the importance of keeping the PoE cable plugged in at all times. A few weeks after school we put up the last two nodes for the girls’ dorms and the boys’ dorms.
Local Applications and Limited Bandwidth
Somaliland is currently the only country in Africa that lacks fiber optic access – cables are laid but access is not predicted to be available until 2014. Somaliland receives its Internet connection via microwaves across the desert from Djibouti. All of the IP address ranges in Somaliland will tell you that you are in Djibouti. The distant gateway connectivity, not to mention unreliable ISPs, equates to some seriously slow Internet.
http://www.ubuntunet.net/sites/ubuntunet.net/files/Intra-Africa_Fibre_Map_v6.pdf © UbuntuNet Alliance; Creative Commons 3.0
A lack of consistent access to the Internet is an ICT instructor’s nightmare. Not being able to teach the most current technologies can be frustrating, and it also hampers sharing files with students. Mesh networking is described as a “peer to peer network:” I wanted to use the full sense of the term and make file sharing among my students easy and manageable. In order to solve this communication problem I decided to rely less on the outside Internet and rely more on local applications installed on our servers. I found the solution to our inconsistent and slow Internet by installing OwnCloud, an open source alternative to Dropbox, on our local server. Now students could share homework assignments with me and other teachers without having to rely on the Internet at all.
Creating a Self-Sufficient Network
As well as the network worked and as much fun as setting it up was, I cannot call this project successful until I can come back to Somaliland a year from now and see the same nodes in place running the same network. I used a few methods to make sure this would be the case. I was careful to document every aspect of the project and create detailed guides for teachers and future network administrators on everything from how to find your IP address on the network to how to ping a node, which is important for isolating a potential problem on the network. Even though mesh networks are “self-healing”, they are not perfect and still have their quirks.
Having all of the knowledge centered in one place with one staff member will only set an organization up for failure, so I’ve made sure to give a series of small trainings to the entire staff. The more transparent you are about how the network works, the more likely the technology will last.
I repeatedly told my students that some of the greatest makers and technologists of our time were self-taught. The excellent support community centered around open source software makes projects such as Commotion sustainable. There is a good chance that if a problem arises, someone else already had that issue or someone in another community across the globe is working on a solution to that problem. I would like to give my sincere gratitude to the Commotion Wireless Project for the support they gave me along with providing me with necessary tools to build this network. Not only did the students at Abaarso School get extremely enthused about mesh networking and learn the meaning of community technology, but now another small part of a country that, technically, does not even exist is more connected to the rest of the world.
These are the release notes for Commotion Router v1 “Grumpy Cat”, available for download now. This is the first full version of the OpenWRT-based firmware for the Commotion project, which is intended to make it easy for communities to build their own communications technology and to serve as a platform for the development of novel and secure communication tools. For clarity, the Commotion firmware distribution for wireless routers will now be referred to as Commotion Router, rather than Commotion-OpenWRT or CommotionWRT.
+For version 1, we are changing our versioning scheme, and deprecating all “Preview Release,” “Developer Release” style designations. From version 1 forward, we are using whole number versions for each release, analagous to projects such as Firefox and Chrome. So, for instance, this will be release 1, and the next will be release 2, and so on. If critical bugfixes are required, we may put out point releases such as 1.1, 1.2, 2.1, etc. These versions are for each platform; there will be a Commotion Router v1, a Commotion Android v1, and so on. These version numbers will not necessarily be synchronized between platforms. Also, for some platforms, like Commotion Router, we may have release names based on internet memes. Individual software components will continue to be versions according to Semantic Versioning.
+Countless fixes and improvements have gone into this release. Most notably, we have moved from our legacy non-standard IP subnets that we retained for compatibility with another project to new private subnets in order to alleviate routing issues when connected to the internet.
+These are the release notes for Commotion Router v1 “Grumpy Cat”, available for download now. This is the first full version of the OpenWRT-based firmware for the Commotion project, which is intended to make it easy for communities to build their own communications technology and to serve as a platform for the development of novel and secure communication tools. For clarity, the Commotion firmware distribution for wireless routers will now be referred to as Commotion Router, rather than Commotion-OpenWRT or CommotionWRT.
-For version 1, we are changing our versioning scheme, and deprecating all “Preview Release,” “Developer Release” style designations. From version 1 forward, we are using whole number versions for each release, analagous to projects such as Firefox and Chrome. So, for instance, this will be release 1, and the next will be release 2, and so on. If critical bugfixes are required, we may put out point releases such as 1.1, 1.2, 2.1, etc. These versions are for each platform; there will be a Commotion Router v1, a Commotion Android v1, and so on. These version numbers will not necessarily be synchronized between platforms. Also, for some platforms, like Commotion Router, we may have release names based on internet memes. Individual software components will continue to be versions according to Semantic Versioning.
-Countless fixes and improvements have gone into this release. Most notably, we have moved from our legacy non-standard IP subnets that we retained for compatibility with another project to new private subnets in order to alleviate routing issues when connected to the internet.
-The latest Commotion release, R1 “Grumpy Cat”, builds upon and enhances features from previous Commotion releases. Although we strived to keep Commotion familiar and compatible with previous revisions wherever possible, R1 introduced significant changes that both users and developers should know about. These changes affect the basic networking components of Commotion, and have been longstanding development priorities. First, we will discuss the technical details of the changes and the reasoning behind them, and at the end we’ll talk about the compatibility issues this brings up for those running pre-R1 Commotion networks.
+ +IP Addressing The first change is the IP addressing schema we use. If you’ve used previous releases of Commotion, you might have noticed that devices on the mesh network assign themselves IP addresses somewhere in the 5.0.0.0/8 range. Additionally, if you’ve connected to a Commotion router running a previous release, your client device would have gotten a 101.x.x.x, 102.x.x.x, or 103.x.x.x IP address. Readers experienced in computer networking will realize that all of these IP address ranges are technically public space, and using them for Commotion could potentially break routing to devices assigned these IP addresses on the public internet. These address ranges were originally selected to maintain compatibility with one of Commotion’s predecessors. Before Commotion existed in its current form, the Open Technology Institute was working on a project to supplement an existing community wireless network with new mesh routers. The custom software that was written for those devices was created to be backward-compatible with the routers already in place, which were running a version of the R.O.B.I.N. firmware. The default IP address ranges of the R.O.B.I.N. firmware were adopted for our custom software, and that project eventually became the seed of what would become Commotion. For R1, we have moved away from publicly allocatable IP addresses and are now using private ranges. But this introduces another problem: most residential and commercial IPv4 networks use the same handful of private address ranges due to the shortage of public IPv4 addresses. If we use one of these common private address ranges for Commotion, we run the risk of interfering with upstream gateway networks and thus causing routing problems. To solve this problem, we have chosen to use the Carrier-Grade NAT shared address space (RFC6598) for all mesh devices. This allows us to use IP addresses in the range 100.64.0.0/10. In addition, all client networks are now bridged and use the RFC1918 private address range 10.0.0.0/8. Another approach to the problem of IPv4 address collision would be to move to a fully IPv6 address space. However, in order to better support the largest variety of hardware possible, we decided to stay with a default IPv4 network for now, while looking into supporting IPv6 in future releases.
+ +Adhoc Wireless Settings Previous versions of Commotion came preconfigured with default values for the adhoc/mesh wireless network settings. We chose “commotionwireless.net” as the SSID, “02:CA:FF:EE:BA:BE” as the BSSID (a BSSID commonly used in wireless mesh networks), and a default channel of 5. In the R1 version of Commotion, users are asked to choose a channel and SSID during setup, so the old defaults are no longer relevant. The more significant change concerns the adhoc BSSID, a value that, like the adhoc SSID, must be shared by all devices in a particular mesh network. Instead of asking the user to choose a BSSID, which is a string of six bytes represented as twelve hexadecimal characters, we opted to use deterministic BSSID generation. This means that the BSSID is now generated as a hash of the adhoc SSID and channel, an idea originally suggested by frequent Commotion contributors Hans-Christoph Steiner and Sean McIntyre. This change will help to prevent certain wireless drivers from ignoring the requested BSSID and roaming to a matching SSID. In R1, Commotion nodes with the same BSSID always have the same SSID and channel, and vice versa. This also has the added benefit of not bothering the user with an unnecessary technical detail.
+ +Backward Compatibility The unfortunate side effect of these changes is that Commotion R1 is not backward compatible with previous releases. In order to upgrade your pre-R1 Commotion network, we recommend flashing all the nodes on your network to R1 via factory reset or the sysupgrade method (be sure to uncheck “Save settings” when sysupgrading to R1). After flashing the nodes, follow the Setup Wizard to set the relevant settings for the node. Once that is finished, you should be all set! After upgrading to R1, your nodes now have the ability to save their settings during future upgrades. To do this, you can keep the “Save settings” option checked when using the sysupgrade method. Have you given R1 a try? Let us know what you think in our feedback form.
+The latest Commotion release, R1 “Grumpy Cat”, builds upon and enhances features from previous Commotion releases. Although we strived to keep Commotion familiar and compatible with previous revisions wherever possible, R1 introduced significant changes that both users and developers should know about. These changes affect the basic networking components of Commotion, and have been longstanding development priorities. First, we will discuss the technical details of the changes and the reasoning behind them, and at the end we’ll talk about the compatibility issues this brings up for those running pre-R1 Commotion networks.
- -IP Addressing The first change is the IP addressing schema we use. If you’ve used previous releases of Commotion, you might have noticed that devices on the mesh network assign themselves IP addresses somewhere in the 5.0.0.0/8 range. Additionally, if you’ve connected to a Commotion router running a previous release, your client device would have gotten a 101.x.x.x, 102.x.x.x, or 103.x.x.x IP address. Readers experienced in computer networking will realize that all of these IP address ranges are technically public space, and using them for Commotion could potentially break routing to devices assigned these IP addresses on the public internet. These address ranges were originally selected to maintain compatibility with one of Commotion’s predecessors. Before Commotion existed in its current form, the Open Technology Institute was working on a project to supplement an existing community wireless network with new mesh routers. The custom software that was written for those devices was created to be backward-compatible with the routers already in place, which were running a version of the R.O.B.I.N. firmware. The default IP address ranges of the R.O.B.I.N. firmware were adopted for our custom software, and that project eventually became the seed of what would become Commotion. For R1, we have moved away from publicly allocatable IP addresses and are now using private ranges. But this introduces another problem: most residential and commercial IPv4 networks use the same handful of private address ranges due to the shortage of public IPv4 addresses. If we use one of these common private address ranges for Commotion, we run the risk of interfering with upstream gateway networks and thus causing routing problems. To solve this problem, we have chosen to use the Carrier-Grade NAT shared address space (RFC6598) for all mesh devices. This allows us to use IP addresses in the range 100.64.0.0/10. In addition, all client networks are now bridged and use the RFC1918 private address range 10.0.0.0/8. Another approach to the problem of IPv4 address collision would be to move to a fully IPv6 address space. However, in order to better support the largest variety of hardware possible, we decided to stay with a default IPv4 network for now, while looking into supporting IPv6 in future releases.
- -Adhoc Wireless Settings Previous versions of Commotion came preconfigured with default values for the adhoc/mesh wireless network settings. We chose “commotionwireless.net” as the SSID, “02:CA:FF:EE:BA:BE” as the BSSID (a BSSID commonly used in wireless mesh networks), and a default channel of 5. In the R1 version of Commotion, users are asked to choose a channel and SSID during setup, so the old defaults are no longer relevant. The more significant change concerns the adhoc BSSID, a value that, like the adhoc SSID, must be shared by all devices in a particular mesh network. Instead of asking the user to choose a BSSID, which is a string of six bytes represented as twelve hexadecimal characters, we opted to use deterministic BSSID generation. This means that the BSSID is now generated as a hash of the adhoc SSID and channel, an idea originally suggested by frequent Commotion contributors Hans-Christoph Steiner and Sean McIntyre. This change will help to prevent certain wireless drivers from ignoring the requested BSSID and roaming to a matching SSID. In R1, Commotion nodes with the same BSSID always have the same SSID and channel, and vice versa. This also has the added benefit of not bothering the user with an unnecessary technical detail.
- -Backward Compatibility The unfortunate side effect of these changes is that Commotion R1 is not backward compatible with previous releases. In order to upgrade your pre-R1 Commotion network, we recommend flashing all the nodes on your network to R1 via factory reset or the sysupgrade method (be sure to uncheck “Save settings” when sysupgrading to R1). After flashing the nodes, follow the Setup Wizard to set the relevant settings for the node. Once that is finished, you should be all set! After upgrading to R1, your nodes now have the ability to save their settings during future upgrades. To do this, you can keep the “Save settings” option checked when using the sysupgrade method. Have you given R1 a try? Let us know what you think in our feedback form.
-On Saturday, January 11, 2014, members of the Commotion team joined two other open source projects, Cupcake and Cryptocat, at the DC Internet Freedom Hack Day, hosted by CommunityRED and OpenITP at 1776 in Washington, DC. The focus of the hack day was to improve the user interface of these tools, which present unique design challenges. Activists, developers, security experts, journalists, designers and UI/UX specialists gathered to learn about Commotion, Cupcake and Cryptocat, and to work on discrete tasks to help make our projects better. Check out this Storify about the day from the Open Technology Institute. The Commotion Wireless team was excited to bring our 1.0 release of Commotion Router to the event because it provided an opportunity to expose Commotion to people from a variety of backgrounds. We got great feedback on the user interface of Commotion Router and Commotion Website, suggestions on improving our Commotion Construction Kit, had Commotion put through some security testing, and refined ideas for our general communications about Commotion.
Norman and @wbend are putting the Commotion Construction Kit through its paces #dcnethack #commotion Events like the DC Internet Freedom Hack Day give our team opportunities to connect with other organizations as well. CommunityRED, OpenITP and 1776 were great hosts and brought out lots of new people from the community in DC and the internet freedom community broadly! Commotion learned a lot from the hack day and will be incorporating the ideas that were generated into our development and documentation.
On Saturday, January 11, 2014, members of the Commotion team joined two other open source projects, Cupcake and Cryptocat, at the DC Internet Freedom Hack Day, hosted by CommunityRED and OpenITP at 1776 in Washington, DC. The focus of the hack day was to improve the user interface of these tools, which present unique design challenges. Activists, developers, security experts, journalists, designers and UI/UX specialists gathered to learn about Commotion, Cupcake and Cryptocat, and to work on discrete tasks to help make our projects better. Check out this Storify about the day from the Open Technology Institute. The Commotion Wireless team was excited to bring our 1.0 release of Commotion Router to the event because it provided an opportunity to expose Commotion to people from a variety of backgrounds. We got great feedback on the user interface of Commotion Router and Commotion Website, suggestions on improving our Commotion Construction Kit, had Commotion put through some security testing, and refined ideas for our general communications about Commotion.
Norman and @wbend are putting the Commotion Construction Kit through its paces #dcnethack #commotion Events like the DC Internet Freedom Hack Day give our team opportunities to connect with other organizations as well. CommunityRED, OpenITP and 1776 were great hosts and brought out lots of new people from the community in DC and the internet freedom community broadly! Commotion learned a lot from the hack day and will be incorporating the ideas that were generated into our development and documentation.
You can join us using your chat program on IRC in the #commotion channel on the irc.freenode.net server.
+You can join us using your chat program on IRC in the #commotion channel on the irc.freenode.net server.
-Wireless networking is a complex topic for most people and often a source of frustration for the average user. Commotion interfaces should use simple language and offer frequent feedback to guide a user through various processes. If it is designed with the following principles in mind, Commotion can teach users about wireless networking and increase public knowledge about the topic.
Commotion is an evolving project that many people will contribute to over time and across continents. In order to encourage widespread adoption and peer-to-peer education on the project, users must have a consistent experience using the software. Processes, language, and visual style must remain similar across different Commotion implementations. This allows people to transfer their knowledge and skills from old versions to new and from one device to another. Our shared intention is to foster an environment in which people are comfortable trying out Commotion, recommending it to others, and teaching their community how to benefit from it.
Commotion tools should be developed with universal accessibility in mind to ensure that users with visual, mobility, auditory, or other impairments can successfuly use it. Testing should also include users of various abilities. Any interface element that a user can interact with should be accessible using a variety of methods. Here are a few simple principles that should guide Commotion development:
There are many more principles of accessible application development. Numerous resources are available to guide designers and developers — here are a few examples that we've found helpful:
Feedback acknowledges a person’s actions and assures them that they are going through steps in a process. Users should receive a positive message, sound or validation feature when a network has been successfully configured and instructions on what to do next. When an error occurs, an easy-to-understand error message should help the user understand what to do about it.
Depending on the application, you may include animations that show progress in between states, as shown below.
Whenever possible, an application should be developed using the standard Commotion status bar icon. The icon indicates that Commotion software is running and the speed of the network a user is connected to, if applicable. On Android, it is appropriate to place this on the right side with the other standard icons.
On mobile phones and desktop applications, a notification should always be present when a device is connected to a mesh network. When the notification is tapped, the Commotion application should reopen. On Android, this is considered an “ongoing notification” indicating a significant process that continues until the user ends it. It is appropriate to also include an icon in the left side of the status bar when the notification is present. This distinct icon shows how many nodes the device is connected to.
Commotion mobile apps, web applications and websites should be responsive to screen or browser size.
Mobile developers should be especially sensitive to screen orientation. Users can rotate mobile devices at any time and for a variety of reasons. Sometimes a task may feel most natural in a certain orientation -- portrait or landscape. If a device is rotated for any reason, Commotion should respond appropriately and maintain its focus on the primary task at hand. The app should start in the same orientation as the app menu that launches it. On Android phones that have a physical keyboard, the app menu is often in landscape orientation when the keyboard is open.
+Wireless networking is a complex topic for most people and often a source of frustration for the average user. Commotion interfaces should use simple language and offer frequent feedback to guide a user through various processes. If it is designed with the following principles in mind, Commotion can teach users about wireless networking and increase public knowledge about the topic.
Commotion is an evolving project that many people will contribute to over time and across continents. In order to encourage widespread adoption and peer-to-peer education on the project, users must have a consistent experience using the software. Processes, language, and visual style must remain similar across different Commotion implementations. This allows people to transfer their knowledge and skills from old versions to new and from one device to another. Our shared intention is to foster an environment in which people are comfortable trying out Commotion, recommending it to others, and teaching their community how to benefit from it.
Commotion tools should be developed with universal accessibility in mind to ensure that users with visual, mobility, auditory, or other impairments can successfuly use it. Testing should also include users of various abilities. Any interface element that a user can interact with should be accessible using a variety of methods. Here are a few simple principles that should guide Commotion development:
There are many more principles of accessible application development. Numerous resources are available to guide designers and developers — here are a few examples that we've found helpful:
Feedback acknowledges a person’s actions and assures them that they are going through steps in a process. Users should receive a positive message, sound or validation feature when a network has been successfully configured and instructions on what to do next. When an error occurs, an easy-to-understand error message should help the user understand what to do about it.
Depending on the application, you may include animations that show progress in between states, as shown below.
Whenever possible, an application should be developed using the standard Commotion status bar icon. The icon indicates that Commotion software is running and the speed of the network a user is connected to, if applicable. On Android, it is appropriate to place this on the right side with the other standard icons.
On mobile phones and desktop applications, a notification should always be present when a device is connected to a mesh network. When the notification is tapped, the Commotion application should reopen. On Android, this is considered an “ongoing notification” indicating a significant process that continues until the user ends it. It is appropriate to also include an icon in the left side of the status bar when the notification is present. This distinct icon shows how many nodes the device is connected to.
Commotion mobile apps, web applications and websites should be responsive to screen or browser size.
Mobile developers should be especially sensitive to screen orientation. Users can rotate mobile devices at any time and for a variety of reasons. Sometimes a task may feel most natural in a certain orientation -- portrait or landscape. If a device is rotated for any reason, Commotion should respond appropriately and maintain its focus on the primary task at hand. The app should start in the same orientation as the app menu that launches it. On Android phones that have a physical keyboard, the app menu is often in landscape orientation when the keyboard is open.
-Most of the files and assets seen in the previous pages are available for download below.
Commotion Brand Usage Guidlines [PDF, 3.5MB]
Commotion logos [ZIP, 11.14MB]
Commotion Brand Assets (ZIP, 30.12MB]
Human Interface Guidelines graphics [ZIP, 9.15MB]
Get Started / Get Involved graphics [ZIP, 1.65MB]
+
Most of the files and assets seen in the previous pages are available for download below.
Commotion Brand Usage Guidlines [PDF, 3.5MB]
Commotion logos [ZIP, 11.14MB]
Commotion Brand Assets (ZIP, 30.12MB]
Human Interface Guidelines graphics [ZIP, 9.15MB]
Get Started / Get Involved graphics [ZIP, 1.65MB]
-
Commotion is an open-source communication tool that uses mobile phones, computers, and other wireless devices to create decentralized mesh networks. It is currently being developed by multiple organizations around the globe, including the Open Technology Institute, The Work Department, The Guardian Project, and The Serval Project.
These Human Interface Guidelines are intended to unite developers and designers in creating a consistent and accessible user experience across Commotion tools. People working on Commotion software should adhere to these guidelines and make suggestions for improving them as needed. We want Commotion to be accessible to a broad population of users around the world, and a coordinated design approach can facilitate widespread adoption.
The visual styles that you see throughout these guidelines are rooted in the Commotion Brand Identity, which was created in 2012 in collaboration with early Commotion developers. The Commotion brand is easy to use, versatile, and humanistic to complement the useful technology behind it that will ultimately help people connect with one another. It’s important to stick to the core principles -- but there’s also space to adapt the identity to various platforms and applications in a creative way.
Thanks for being a part of the Commotion project. Together, we’ll build software tools that offer an outstanding user interface, are credible, easy-to-use, and flexible enough to evolve around the world but maintain a core set of functions and standards.
Screenshots for Android 4.0 are used throughout this guide.
While Commotion began its life as a package for the OpenWRT router platform, it has grown into a multi-platform project. Its core technology, the OLSR routing daemon, can be compiled and run on many different devices. Commotion serves as a management and configuration layer atop OLSR, providing a reliable and flexible platform for people to set up small-to-medium sized wireless mesh networks.
Because of the project’s history and the nature of the platform, the OpenWRT router interface will tend to have the most robust set of features and serve as a benchmark for other platforms and their interfaces. The Commotion interface extends the default OpenWRT configuration system using LuCI.
To best understand the Commotion OpenWRT user experience, consider how an average small community wireless network would be set up.
Now, consider how this user experience might be different for someone joining an existing network with a mobile phone in order to access a service somewhere on the local network.
(See Developing a use case for tips on brainstorming user scenarios.)
These different user experiences will, of course, require slightly different interfaces. The neighbor setting up four routers on rooftops will require different tools than a visiting friend who wants to log into the network and access a community file server, but both of these users should experience some shared elements. Both of these users will encounter the Commotion product name, and both will learn a few key terms. In the case of the neighbor who is setting up the network, much of this learning will happen while they read through documentation or use the OpenWRT configuration interface. They will spend quite a bit of time entering settings and becoming familiar with user interface look and feel.
In the case of a visitor signing on to the network, they might only come into contact with the Commotion software for a brief moment when they connect to an access point (named “commotion-something”) and click through a captive portal splash page with a Commotion logo and some descriptive information. These are very different uses of Commotion, but both situations should leave the user with a positive impression and some basic knowledge about the project: the name, the logo, and ways to find out more information and get help.
As part of the Commotion development process, UI mockups were created by designers at The Work Department to inspire the software's design. You can see those initial ideas on Flickr. The early ideas were shared with the Commotion community to solicit feedback. The UI examples throughout these guidelines have since been refined and approved by the core Commotion team.
Users expect long-term reliability, speed, and ease of use when using wireless devices. The Commotion user interface should:
Walk a user through the setup process.
+Work well across platforms, browsers, and devices.
+Be as fast as using a non-mesh WiFi access point.
+Help users understand mesh network security.
+Allow for easy monitoring of network status in terms that users can understand.
+Offer troubleshooting suggestions when a network does not work correctly.
+Building a community, either online or offline, requires effective social and cultural organizing. Learning and trust play a key role in creating a neighborhood network that can benefit a wide array of individuals. Commotion software should facilitate positive human interactions that build a social network while building a mesh network.
If a Commotion application allows the user to build or maintain a network, it should reference relevant Commotion documentation regarding neighborhood network building and organizing. You might include some of this content inline in the software and some as links to online sources.
+Commotion is an open-source communication tool that uses mobile phones, computers, and other wireless devices to create decentralized mesh networks. It is currently being developed by multiple organizations around the globe, including the Open Technology Institute, The Work Department, The Guardian Project, and The Serval Project.
These Human Interface Guidelines are intended to unite developers and designers in creating a consistent and accessible user experience across Commotion tools. People working on Commotion software should adhere to these guidelines and make suggestions for improving them as needed. We want Commotion to be accessible to a broad population of users around the world, and a coordinated design approach can facilitate widespread adoption.
The visual styles that you see throughout these guidelines are rooted in the Commotion Brand Identity, which was created in 2012 in collaboration with early Commotion developers. The Commotion brand is easy to use, versatile, and humanistic to complement the useful technology behind it that will ultimately help people connect with one another. It’s important to stick to the core principles -- but there’s also space to adapt the identity to various platforms and applications in a creative way.
Thanks for being a part of the Commotion project. Together, we’ll build software tools that offer an outstanding user interface, are credible, easy-to-use, and flexible enough to evolve around the world but maintain a core set of functions and standards.
Screenshots for Android 4.0 are used throughout this guide.
While Commotion began its life as a package for the OpenWRT router platform, it has grown into a multi-platform project. Its core technology, the OLSR routing daemon, can be compiled and run on many different devices. Commotion serves as a management and configuration layer atop OLSR, providing a reliable and flexible platform for people to set up small-to-medium sized wireless mesh networks.
Because of the project’s history and the nature of the platform, the OpenWRT router interface will tend to have the most robust set of features and serve as a benchmark for other platforms and their interfaces. The Commotion interface extends the default OpenWRT configuration system using LuCI.
To best understand the Commotion OpenWRT user experience, consider how an average small community wireless network would be set up.
Now, consider how this user experience might be different for someone joining an existing network with a mobile phone in order to access a service somewhere on the local network.
(See Developing a use case for tips on brainstorming user scenarios.)
These different user experiences will, of course, require slightly different interfaces. The neighbor setting up four routers on rooftops will require different tools than a visiting friend who wants to log into the network and access a community file server, but both of these users should experience some shared elements. Both of these users will encounter the Commotion product name, and both will learn a few key terms. In the case of the neighbor who is setting up the network, much of this learning will happen while they read through documentation or use the OpenWRT configuration interface. They will spend quite a bit of time entering settings and becoming familiar with user interface look and feel.
In the case of a visitor signing on to the network, they might only come into contact with the Commotion software for a brief moment when they connect to an access point (named “commotion-something”) and click through a captive portal splash page with a Commotion logo and some descriptive information. These are very different uses of Commotion, but both situations should leave the user with a positive impression and some basic knowledge about the project: the name, the logo, and ways to find out more information and get help.
As part of the Commotion development process, UI mockups were created by designers at The Work Department to inspire the software's design. You can see those initial ideas on Flickr. The early ideas were shared with the Commotion community to solicit feedback. The UI examples throughout these guidelines have since been refined and approved by the core Commotion team.
Users expect long-term reliability, speed, and ease of use when using wireless devices. The Commotion user interface should:
Walk a user through the setup process.
-Work well across platforms, browsers, and devices.
-Be as fast as using a non-mesh WiFi access point.
-Help users understand mesh network security.
-Allow for easy monitoring of network status in terms that users can understand.
-Offer troubleshooting suggestions when a network does not work correctly.
-Building a community, either online or offline, requires effective social and cultural organizing. Learning and trust play a key role in creating a neighborhood network that can benefit a wide array of individuals. Commotion software should facilitate positive human interactions that build a social network while building a mesh network.
If a Commotion application allows the user to build or maintain a network, it should reference relevant Commotion documentation regarding neighborhood network building and organizing. You might include some of this content inline in the software and some as links to online sources.
-A successful UI running on multiple devices must share appropriate, accessible and common language. The following list of terms should be used throughout Commotion apps. Some of them include descriptions that can be included in optional tooltips for the user who needs more information. Advanced terminology that requires significant prior knowledge to understand should be reserved for the advanced area of your software.
A successful UI running on multiple devices must shar
The flowchart below describes the steps that a user should go through in order to create or join a mesh network. The process begins with a simple splash screen that includes the Commotion logo and is followed by automatic network detection. After choosing or creating a network that is not encrypted, the user should immiediately see a pop-up warning that reads:
"Activity on this mesh network can be monitored by outside parties. Learn more about security and privacy."
@@ -192,6 +158,42 @@
The flowchart below describes th
When a client joins a mesh network without using mesh software, a standard splash screen should appear when the user first opens a web browser. Here’s an example.
Logo
The full logo is made up of several parts. There is the name or logotype “Commotion”. Then, there are several pink circles that represent “nodes” in the mesh network. The o’s in the word Commotion also represent nodes. These nodes are connected by pink lines, forming a mini mesh network.
The full logo should be used whenever there is enough horizontal space to do so. There are other versions of the logo where the full-size logo doesn't fit.
There is the mid-sized logo and the tiny-logo, which should be used when the space doesn’t allow for the whole Commotion word to be spelled out.
Since a mesh network is flexible and can change shape, so can the logo. The main difference between the digital and print version of the mid logo is that the digital version has a slight drop shadow. This helps it to stand out more on a screen. Otherwise they are exactly the same.
Color
The color palette consists of two primary colors and a set of secondary colors. The primary colors are used for most of the logo and typographic applications. ‘Commotion’ and nodes in the logo are always black and the mesh is generally pink. Depending on the application, the mesh lines may change colors.
The secondary colors will be applied depending on the needs of the various user interfaces and the utility of the network.
Fonts
There are two fonts that are recommended for use with the Commotion brand: Avenir and ASAP. Avenir is made for print, and is recommended when designing anything that will be printed. ASAP, on the other hand, was made for viewing on screen and therefore anything that is designed to be digital should use ASAP.
ASAP is a free and open-source font that can be downloaded here. Avenir can be purchased from numerous font stores. (If you are unable to acquire Avenir, use ASAP instead.)
Headings should be large and easy to read. The subhead should be in all capital letters and in one of the colors from the color palette above. A subhead should be about 1/3 of the size of the heading.
Body copy should also be about 1/3 of the size of the heading and in black. To make the text easier to read, allow for some extra line spacing.
Core components
The core components of the Commotion identity are simple but can be used to make other images. These parts are “the nodes,” and “the line.”
Be creative with these parts and make graphs diagrams or icons or any other graphic that is needed.
Illustration style
For illustrations that are more complex than a simple node and line, we recommend using a thick black outline and adding shading and color using the outlined palette and blocks of color and dot patterns of various sizes and colors.
Standard Icons
We recommend using the following seven standard icons throughout Commotion to represent common processes and menus. You should use these icons whenever practical. This icon set may evolve over time as Commotion and its community grows.
If a certain platform's guidlines recomend native icon use or you are unable to use custom elements, use your platform's native iconography instead. For example, the Create a network and Join a network icons could replaced with native icons if needed:
There are six types of visual language that can be used in Commotion applications:
With the exception of learning language, these messages should be clearly displayed within the application and give the user the option to close or collapse the message. The messages should not disappear based on an arbitrary timeout.
Learning Language can appear as a tooltip (on hover or tap) or persistently below form fields. In the early UI mockups, the designers chose to place the tooltips in the right-hand gutter on a desktop-sized screen. On a mobile device, it would not be practical to place the tooltips in the gutter, so a designer might decide to provide an option to expand the below-field Learning Language to show more information and provide links to external documentation.
The words you use in your application are important. They can either help new users effectively use mesh networks or discourage them from even getting started. Commotion applications should speak to the most basic computer user and guide them through processes while teaching potentially new concepts. See the Common language section for a detailed list of terms to use consistently in the user interface. Advanced terminology that requires significant prior knowledge to understand should be reserved for the advanced area of your software.
Here are useful writing tips from the Android Design guidelines:
Here are some examples of good writing that you may use for Commotion:
"It looks like there is a mesh network you can join! Select a network below or create a new mesh network."
“You're connected to Sparkles mesh network. Your node name is Josh21 and you are using Channel 5. You're connected to 5 nodes and 2 clients are connected to you. You aren't connected to the internet.”
"There aren't any nearby mesh networks. Would you like to create a new mesh network?"
+Logo
The full logo is made up of several parts. There is the name or logotype “Commotion”. Then, there are several pink circles that represent “nodes” in the mesh network. The o’s in the word Commotion also represent nodes. These nodes are connected by pink lines, forming a mini mesh network.
The full logo should be used whenever there is enough horizontal space to do so. There are other versions of the logo where the full-size logo doesn't fit.
There is the mid-sized logo and the tiny-logo, which should be used when the space doesn’t allow for the whole Commotion word to be spelled out.
Since a mesh network is flexible and can change shape, so can the logo. The main difference between the digital and print version of the mid logo is that the digital version has a slight drop shadow. This helps it to stand out more on a screen. Otherwise they are exactly the same.
Color
The color palette consists of two primary colors and a set of secondary colors. The primary colors are used for most of the logo and typographic applications. ‘Commotion’ and nodes in the logo are always black and the mesh is generally pink. Depending on the application, the mesh lines may change colors.
The secondary colors will be applied depending on the needs of the various user interfaces and the utility of the network.
Fonts
There are two fonts that are recommended for use with the Commotion brand: Avenir and ASAP. Avenir is made for print, and is recommended when designing anything that will be printed. ASAP, on the other hand, was made for viewing on screen and therefore anything that is designed to be digital should use ASAP.
ASAP is a free and open-source font that can be downloaded here. Avenir can be purchased from numerous font stores. (If you are unable to acquire Avenir, use ASAP instead.)
Headings should be large and easy to read. The subhead should be in all capital letters and in one of the colors from the color palette above. A subhead should be about 1/3 of the size of the heading.
Body copy should also be about 1/3 of the size of the heading and in black. To make the text easier to read, allow for some extra line spacing.
Core components
The core components of the Commotion identity are simple but can be used to make other images. These parts are “the nodes,” and “the line.”
Be creative with these parts and make graphs diagrams or icons or any other graphic that is needed.
Illustration style
For illustrations that are more complex than a simple node and line, we recommend using a thick black outline and adding shading and color using the outlined palette and blocks of color and dot patterns of various sizes and colors.
Standard Icons
We recommend using the following seven standard icons throughout Commotion to represent common processes and menus. You should use these icons whenever practical. This icon set may evolve over time as Commotion and its community grows.
If a certain platform's guidlines recomend native icon use or you are unable to use custom elements, use your platform's native iconography instead. For example, the Create a network and Join a network icons could replaced with native icons if needed:
There are six types of visual language that can be used in Commotion applications:
With the exception of learning language, these messages should be clearly displayed within the application and give the user the option to close or collapse the message. The messages should not disappear based on an arbitrary timeout.
Learning Language can appear as a tooltip (on hover or tap) or persistently below form fields. In the early UI mockups, the designers chose to place the tooltips in the right-hand gutter on a desktop-sized screen. On a mobile device, it would not be practical to place the tooltips in the gutter, so a designer might decide to provide an option to expand the below-field Learning Language to show more information and provide links to external documentation.
The words you use in your application are important. They can either help new users effectively use mesh networks or discourage them from even getting started. Commotion applications should speak to the most basic computer user and guide them through processes while teaching potentially new concepts. See the Common language section for a detailed list of terms to use consistently in the user interface. Advanced terminology that requires significant prior knowledge to understand should be reserved for the advanced area of your software.
Here are useful writing tips from the Android Design guidelines:
Here are some examples of good writing that you may use for Commotion:
"It looks like there is a mesh network you can join! Select a network below or create a new mesh network."
“You're connected to Sparkles mesh network. Your node name is Josh21 and you are using Channel 5. You're connected to 5 nodes and 2 clients are connected to you. You aren't connected to the internet.”
"There aren't any nearby mesh networks. Would you like to create a new mesh network?"
-These Human Interface Guidelines are maintained by the Open Technology Institute and new versions are released as needed. If you have suggestions for updating them, please contact us.
These additional topics will be useful to include in future iterations of this HIG:
These Human Interface Guidelines are maintained by the Open Technology Institute and new versions are released as needed. If you have suggestions for updating them, please contact us.
These additional topics will be useful to include in future iterations of this HIG:
Commotion-Android currently exists in two forms. The original MeshTether version, which ran on rooted stock Android devices, and the new CyanogenMod-based version. Because ad-hoc wifi is not supported in Android (see: Android Issue #82), the original Commotion-Android, currently in master branch is deprecated. All new development should be based on Commotion-Android's CM branch.
https://github.com/opentechinstitute/commotion-android/tree/cm
See the Commotion-Android Readme for build instructions and prerequisites.
+Commotion-Router is a highly customized version of the OpenWRT embedded Linux distribution. The main project repository (commotion-router) contains only the scripts and default files needed to download OpenWRT and add Commotion's packages to the OpenWRT build system. Those Commotion packages are defined in the packages directory of the Commotion Feed repo. Source code for individual Commotion-Router packages can be found in the repositories (PKG_SOURCE_URL) and branches (PKG_VERSION) specified in their respective Commotion Feed Makefiles.
By default, Commotion-Router is configured to build images for Ubiquiti devices using the master branch of each project repo. New development takes place in feature branches, which are merged to master after function testing. See the GitHub Workflow document on the Commotion Wiki for information on branching and submitting patches.
Commotion-Router can theoretically be built for any OpenWRT-compatible device with sufficient flash storage to install the 5.4MB Commotion image. However, at present, devices using the ar7xxx/ar9xxx have the best wireless driver compatibility.
See the OpenWRT Easy Build guide for OpenWRT's minimum build prerequisites. You may encounter additional dependencies when building or developing specific Commotion packages.
See the Commotion Router Readme on GitHub.
+Commotion runs on multiple software and hardware platforms: Embedded routers, smart phones, desktops and laptops, and open source GSM basestations. Development on each of these platforms occurs in parallel. Where possible, a common set of tools are used to develop Commotion, no matter the platform. However, there are certain platforms where unique tools are required.
All Commotion platforms share a common core: a shared network medium (usually ad-hoc Wifi, known as IBSS) and an IP routing protocol (OLSRd). Read more about the Commotion architecture and how it varies across platforms on the Developer Wiki.
Commotion is written in a combination of C, Lua, Javascript, Python, Java, shell, Objective-C, PHP. All of our source code is hosted on Github. To see the relationship between code repositories and the Commotion architecture, read the architecture documents above.
See the GitHub Workflow page on the Commotion Wiki for information on the Commotion team's GitHub workflow.
Commotion developers rely on a combination of tools, experience, and intuition to debug. We use gdb, ddms and unit testing. Read more about our testing procedures and methodologies and procedures for lab testing on the Developer Wiki.
Read more about common debugging procedures we use on the Developer Wiki. To report bugs and submit fixes, use our issue tracker.
+Commotion runs on multiple software and hardware platforms: Embedded routers, smart phones, desktops and laptops, and open source GSM basestations. Development on each of these platforms occurs in parallel. Where possible, a common set of tools are used to develop Commotion, no matter the platform. However, there are certain platforms where unique tools are required.
All Commotion platforms share a common core: a shared network medium (usually ad-hoc Wifi, known as IBSS) and an IP routing protocol (OLSRd). Read more about the Commotion architecture and how it varies across platforms on the Developer Wiki.
Commotion is written in a combination of C, Lua, Javascript, Python, Java, shell, Objective-C, PHP. All of our source code is hosted on Github. To see the relationship between code repositories and the Commotion architecture, read the architecture documents above.
Commotion developers rely on a combination of tools and intuition to debug. We use gdb, ddms and unit testing. Read more about our testing procedures and methodologies and procedures for lab testing on the Developer Wiki.
Read more about common debugging procedures we use on the Developer Wiki. To report bugs and submit fixes, use our issue tracker.
-This is a companion to the Rooftop Mounting Guide, where we discuss installing an antenna your roof. Of course, when you install any metal pole on your roof, you are creating a lightning rod! Lightning can be very damaging, so we want to make sure we protect against it. It is important to note that if your house or building isn’t the highest thing in the area - for instance if there are tall trees close by or if there are other taller buildings around - your risk of actually being struck by lightning is extremely small. Keep this in mind, and don’t panic about putting up an antenna mast! If you follow a few of these steps here you can protect yourself from damage to your home or electronics. Though lightning is dangerous, it is extremely unlikely to be struck. A more common problem is static build-up from electric charge in the air during a lightning storm. This static can cause a charge to run down the cables from the roof and damage equipment in your house. We want to direct this charge in to the ground, rather than in to your electronics!
Before we talk about what to install, we should talk about what qualifies as ground. There are lots of options, but there are three safe ones:
This is a companion to the The outdoor arrestor should be installed directly below the rooftop Router, as close to the ground as possible. This is to minimize the length of wire between the arrestor and the ground rod or ground conductor, since they should be installed in the ground or in the basement. It should mount with two short screws to the wood, concrete or brick base of the building.
Most of the time, the best place to put a wireless router will be on the roof of your house or organization’s building. Every roof is unique, so this guide can’t cover every possibility! We are just covering your options here, it will be up to your best judgement to decide which method to use.
First and foremost - when working on any roof, be very careful. Any slip or slide could lead to a long fall, and serious injury or death.
If you aren't comfortable working on the roof, don't do it.
Get some help! Ask around your community and see if there are any professional roofers, cable TV or phone installers, or other folks that have experience working in places like this. There are two basic kinds of roof: flat and pitched. Flat roofs are often the easiest to work on, and the safest. Pitched roofs are slanted, and in some cases are very steeply slanted. We advise to only work on a roof with a shallow roof pitch. In the picture below, the roofs in the top row are safest, while the bottom two rows of roofs are likely to be tricky and dangerous.
With either roof type, there are a variety of roof coverings and sealants to be aware of. These all protect the roof and make it waterproof. The most important rule when installing something on a roof: never drill any holes in the roof surface itself. Even if the holes are sealed properly, they will eventually leak, and lead to problems in the long run.
When there is a tall chimney on the roof, we can mount a pole, mast or pipe to the roof using one of two methods: drilling anchors to hold a pipe in to the chimney, or using a strap mount. It is up to you if you want to drill holes in your chimney. NOTE: If your chimney is missing bricks, mortar, or does not look to be in good shape, please do not mount anything to it! These will generally work on either flat or pitched roofs.
The typical anchor mount is made up of two v-shaped pieces of metal, which you attach to the chimney with screws and anchors. Kits are sometimes available at Radio Shack, or online:
Most of the time, the
As a home owner or building owner, use whichever method above you are most comfortable with. It’s your house! Read through your options above and see what works best for you. If you are still not sure, ask around your neighborhood. See what your neighbors use to mount their satellite dishes, TV antennas, or wireless equipment. Ask around, maybe they can help you install it as well! Also keep in mind there might already be something on your roof that you could use to mount a wireless router to. Generally a pipe or antenna mast should be around 1½” in diameter to best fit the equipment. If you can get to the existing mount safely, by all means use it. One last note: be safe!