Blog: Updates from Networks

Announcing collaboration with wlan slovenija (2015-04-22)

The Commotion project is pleased to announce our collaboration with wlan slovenija! ...

Do-it-yourself antennas for Community Networks (2014-11-05)

For people around the world planning or building wireless networks, the cost and accessibility of the equipment can often be a challenge. There are usually a few models of wireless routers, but they are generally for home or office use, and not intended to be mounted outdoors. In addition, most router antennas are designed to connect with nearby devices, within 100 meters or less. ...

Mesh Bukavu - Designing a network from scratch (2014-10-27)

The Open Technology Institute recently discussed options for community wireless networks with Free Press Unlimited – a NGO based in the Netherlands that works on press freedom issues around the world. Their response was to organize a workshop with interested individuals in the town of Bukavu, a town on the eastern border of the Democratic Republic of Congo. The report on the workshop below is a guest post from Pepijn Kalis – an organizer with Free Press Unlimited based in the Democratic Republic of Congo. It discusses the first steps towards building a community-owned and run network. ...

Commotion Router v1.1 "Grumpy Cat" Released! (2014-10-15)

We are very pleased to announce the v1.1 release for our Commotion Router firmware! This release finalizes many bugfixes and stability enhancements in our stable v1.x “Grumpy Cat” branch. ...

Call for Proposals: International Commotion Mesh Wireless Projects (2014-10-08)

The Open Technology Institute is pleased to announce its first call for proposals from groups interested in implementing Commotion-based wireless mesh networks in their communities. This project is supported by the Bureau of Democracy, Human Rights and Labor Affairs at the United States Department of State. Due to funding restrictions, projects must be located outside of the United States and Europe. ...

Is Commotion Vulnerable to the Shell Shock/Bash Bug? (2014-09-26)

A new and serious vulnerability in the Linux Bourne-again shell (Bash) has been making the rounds in the media lately, termed either Shell Shock or the Bash Bug. The vulnerability is potentially even more significant than the Heartbleed vulnerability earlier this year, and likely affects a huge number of servers on the internet. ...

Transparent Tor Gateway on OpenWRT (2014-09-15)

This post originally appeared on disman.tl. ...

The 2014 Allied Media Conference MagicNet - Third Time's the Charm (2014-08-06)

OTI works with Digital Stewards to construct this year’s conference-wide network. ...

Commotion Router v1.1 "Grumpy Cat" Release Candidate 2 (2014-06-13)

We are excited to announce the second release candidate for our Commotion Router firmware bugfix release v1.1. The following fixes have been added since v1.1rc1: ...

Commotion Pi: Build an RPi MESH Node (2014-06-12)

Editors note: This is a community post which originally appeared here. If you are writing about working with Commotion let us know, we are happy to repost and share what folks are doing with Commotion!! ...

Open Wifi and Copyright - A Primer for Network Operators (2014-05-27)

This article originally appeared on the EFF website. ...

Little Box of Routers - Expanding Commotion Support for More Router Models (2014-05-13)

The Commotion team often gets email from people interested in trying out our router software on their devices, as well as inquiries about supporting more than just Ubiquiti models. Since the Commotion Router 1.0 release, we’ve been working on expanding support for more routers and we’d love to get your help! ...

Commotion and Security (2014-04-21)

One of the major goals of the Commotion project has been to introduce security tools open-source wireless mesh networks, while emphasizing ease-of-use and reusing existing technologies as much as possible. Now that our first stable releases are out, it’s worthwhile to revisit that goal and see what the project has accomplished. ...

Digital Stewardship and your community (2014-04-18)

OTI has partnered with groups around the world to develop the concept of Digital Stewardship, and hopes to refine it as more communities adopt and adjust it for local needs. Digital Stewardship is a principled approach to community technology that emphasizes self-governance and sustainability. Digital Stewards grow and maintain the technology their communities need to foster healthy relationships, build resilience, and increase access to critical information. OTI works with local partners to integrate the Digital Stewards approach into the group’s existing projects, missions, and goals. ...

Case Study - Mesh Sayada (2014-04-18)

The Sayada community network, Mesh Sayada, is a collaboratively designed and built wireless network. The town of Sayada is located on the Tunisian coast, 140 kilometers from Tunis. The network serves as a platform for locally-hosted content, such as Wikipedia and Open Street Maps, and is expected to expand to include locally created content. Local residents and CLibre, a Sayada-based free technology association, initiated the network in December, 2013. ...

How much does it cost to build a Commotion network? (2014-04-14)

If you are thinking of building a Commotion wireless network, no matter what the size, one of your first questions might be “how much does it cost?” When planning any project, the total cost (now and in the future) is often a big concern, and building a wireless network is no different. OTI has written about this before, but we want to add some detailed information to our colleague Seamus’ earlier blog post on the subject. ...

Commotion Router v1.1 "Grumpy Cat" Release Candidate 1 (2014-04-11)

This is the release candidate for our v1.1 bugfix release for our Commotion Router firmware. It is built on OpenWRT Attitude Adjustment trunk, OLSRd v0.6.5, libseval, and other software. It also includes the Commotion-specific components listed below with the features and enhancements included in this release: ...

Exploring Commotion with Wireshark - a Tutorial (2014-02-04)

The program Wireshark, a network analyzer for Windows and Linux, allows you to monitor network traffic to see the actual packets of data being sent around you. This will allow us to look at the difference between encrypted and unencrypted traffic on a router running Commotion to see if encryption is working. This guide is written for Wireshark running on a Linux device, but can be applied to wireshark debugging on any compatible device. ...

Commotion Team participates in DC Internet Freedom Hack Day (2014-01-14)

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

Commotion R1 Breaking Changes (2014-01-10)

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

Commotion Router v1 Release Notes (2013-12-30)

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. A Note About Releases 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. New Features **New user interface:** We have conducted an extensive usability review that has contributed to a complete overhaul of the Commotion user interface. The result is that our user interfaces are easier to use, more powerful, and more closely integrated with the rest of the software. We plan on revisiting the usability review process on a regular basis in order to keep our interfaces friendly and current. **Multi-interface support:** We now support more flexible configurations of devices that include multiple wired and wireless interfaces. This allows us to support more routers, and allows for the deployment of more complex networks. **Greater stability, fewer resources:** Work on reducing our processing and storage overhead on embedded platforms has resulted in greater stability and smaller software images. **Better Serval mesh support:** The Serval encrypted overlay mesh is now more closely integrated throughout our software, and provides an API for developers to create truly end-to-end encrypted applications on top of a mesh network. Developer docs and an example messaging application forthcoming. **Easier upgrades:** Commotion now supports retaining configuration between upgrades, so that you do not have to reconfigure your device each time. We intend to retain upgrade compatibility as much as possible from this point forward. Bug Fixes 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. Included Components commotion-service-manager v0.3: Provides automatic network service discovery luci-commotion-apps v2.0: Web-based local application portal for Commotion-OpenWRT commotion-dashboard-helper v0.2: A script for sending analytics information to a dashboard commotion-debug-helper v1.0: A LuCI-based reporting tool to simplify the process of router troubleshooting commotion-lua-helpers v1.0: A set of lua helpers and extensions maintained by the Commotion project. luci-i18n-commotion v0.2.1: GUI translation support luci-commotion-splash v1.2: A LuCI interface for configuring nodogsplash captive portal commotiond v0.2: An extensible daemon and library bundle that will form Commotion’s core administrative API and simplify the process of porting to new platforms luci-theme-commotion v2.0: HIG-compliant Commotion theme for OpenWRT routers luci-commotion v1.0: Complete Commotion web interface built on the LuCI framework. OLSRd v0.6.5.4: Open-source mesh routing daemon implementing the Open Link State Routing protocol. olsrd-dnssd v0.3: Propagates multicast DNS (mDNS) service discovery advertisements (DNSSD) over an OLSR mesh network olsrd-mdp v0.3: Plugin for signing OLSR mesh traffic serval-dna v0.91: Cryptographic libraries and API for secure and delay-tolerant communication OpenWRT Linux 12.09.1 "Attitude Adjustment": Extensible Linux distribution for embedded devices. LuCI v0.11: Lua-based model-view-controller web framework for embedded devices. ...

Building a Mesh Network in Rural Somaliland (2013-12-12)

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. An Intra-Africa Fiber Map © 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. ...

Building Pop-up Mesh Networks (2013-10-30)

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: Because the network can be highly dynamic, people must adequately plan and constantly coordinate to both maintain solid network links and provide adequate coverage by remaining spaced apart. This is easier when some nodes are relatively stationary. The network was most resilient when there were multiple redundant links. Although links could stretch several blocks, it was often ideal to place nodes on opposite sides of the street but only one block apart and create redundancy in the network. Adding height to the ground-level nodes improved performance by reducing the number of wireless barriers (for example, people standing between the nodes). Going up half a flight of stairs improved network quality between those links. Coordinating across a large geography is difficult, making pre-planning important. Especially for purposes of field experiments, everyone should have all positions mapped, everyone’s IP address and a method of communication. 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. ...

PRESS RELEASE - New Tools Support Communities to Build Own Wireless Communications Infrastructure (2013-10-01)

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

Commotion Field Test - Pop-up mesh network, downtown Washington, DC (2013-09-29)

Introduction: 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. **Results and Observations: ** OTI staff was able to set up a successful pop-up network using “Commotion WRT Nightly Build 09.25.13” on omnidirectional Ubiquiti Picostation routers up to 4 hops/3 blocks/0.3 miles away from the gateway node in a crowded location in an urban setting. Routers in backpacks were able to maintain links roughly one block apart. This distance was impacted by the number of trees, people, and buildings in the area, as well as the height of the router. **Equipment details: ** 4 Ubiquiti Picostations HP (6dBi) Omnidirectional routers (spec) 4 Energizer XP8000 battery packs (spec) Commotion Firmware: Commotion-OpenWRT 25-Sep-2013 DR2 Nightly build (https://commotionwireless.net/download/routers) 4 Ethernet Cables to connect Picostation to the battery pack 4 Passive PoE Injector Cable Sets **Location Details: ** Moderately busy street during lunch hours with many people walking in the area Approximately 10-12 feet tall trees along K St NW Closely located 4-6 floor buildings in the area Gateway router on the 5th floor of 1899 L St NW Mesh network with moving access points within 3 blocks (0.3miles) of the gateway node located at the following intersections: 1828 L St NW: right across the street (33 feet) from the gateway node but at ground level with clear line of sight 1875 K St NW: clear line of sight from first access point at ground level (500 feet) 1801 K St NW: clear line of sight from second access point at ground level but with more trees, buildings, and people around (250 feet) Farragut Square at the junction of K St NW and Connecticut Avenue: satisfactory line of sight from third access point at the ground level with more trees, buildings, and people around. (0.1miles) **Steps followed in the Pop-up Test:** 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. ...

Commotion DR2 Release Notes (2013-09-19)

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. What is a Commotion 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. Platform Availability 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. New Features **Dashboard support: **We've added initial support for Commotion nodes to voluntarily opt-in to reporting basic analytics information to external, web-based dashboards for visualizing the network. The first such dashboard we're supporting is based on the network map for the Freifunk project. **Internationalization support:** All web-based Commotion interfaces have had support added for translation into multiple languages, building off of the support included with OpenWRT's LuCI platform. We've included a French translation of the interface, and will be continuing to add other translations. **Secure administration interface: **Previously, the web-based admin interface for the nodes was only available via an unencrypted connection. We've now integrated a tutorial into the Quickstart process that introduces users to setting up and manually verifying their SSL connection to the node after setup. Fixes 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. Upcoming changes 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. Included Components avahi-client v0.1: Provides automatic network service discovery commotion-apps v1.2: Web-based local application portal for Commotion-OpenWRT commotion-bigboard-send v0.1.1: A script for sending analytics information to a dashboard commotion-debug-helper v0.1: A LuCI-based reporting tool to simplify the process of router troubleshooting commotion-luci-i18n v0.1: GUI translation support commotion-quick-start v0.2.1: A one-click tool to simplify router configuration on first boot commotion-splash v1.1: A LuCI interface for configuring nodogsplash captive portal commotiond v0.1.1: An extensible daemon and library bundle that will form Commotion’s core administrative API and simplify the process of porting to new platforms luci-theme-commotion v1.2: HIG-compliant Commotion theme for OpenWRT routers luci-commotion v0.1.1: Commotion configuration pages for the LuCI web interface luci-commotion-dash v0.1: Configuration for dashboard reporting. olsrd-dnssd v0.2: Propagates multicast DNS (mDNS) service discovery advertisements (DNSSD) over an OLSR mesh network olsrd-mdp v0.2: Plugin for signing OLSR mesh traffic serval-crypto v2.1: Cryptographic libraries and API for signing mDNS service advertisements ...

OTI's Red Hook Digital Stewards Bring Internet Access to New York City Housing Authority Facility (2013-07-30)

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

Video- Community, Technology, and Training (2013-07-26)

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

Mountain-top repeaters and solar-powered Wi-Fi - Guest Post from Nepal Wireless (2013-07-26)

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

Commotion Development Progress Visualized (2013-07-11)

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

Commotion Travels to India for first International Workshop (2013-07-01)

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: Good community technology is defined by the ability of that community to break and repair it themselves. Successful technology training and adoption needs a clear and common use in the participant's life. If they don't use it regularly, they won't retain the information, or use the technology. Internet access is not always the most important consideration - a local network can and should provide a local application first and foremost. Strong, lasting networks are built through participatory planning and community engagement. 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: “The internet as a free, secure, decentralized, and inclusive media for all communities to overcome economic marginalization and local problems.” Community-owned networks “that are built with low-cost devices, equally accessed, and resistant to blackouts.” Community technology that is “by communities, for communities and integrating across various devices and technologies,” “peer-to-peer without centralized control or surveillance,” and “enabling local content creation and consumption and in the local context and language.” 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: engage in peer-to-peer learning because it helps demystify technology create a level of comfort around technology build an awareness in communities about the available technology, so they can build from the knowledge and resources available above all, break the fear of technology and show users that technology can be taken apart and put back together. 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. ...

Serval Mesh Extender Field Trial on the National Mall (2013-06-05)

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

Commotion DR1 Stable Release Notes (DR1.1) (2013-06-05)

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. What is a Commotion 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. Platform Availability 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. Features: **Easy-to-use setup wizard:** The Commotion Quickstart wizard provides a simple, one-step interface for setting up a Commotion node. **Local applications:** The Commotion Apps Portal is an interface for creating and browsing for local network applications. **Common platform for managing settings:** The Commotion Daemon provides a common management interface for maintaining the configurations of different community networks. **Encryption tools:** Commotion configures industry-standard IBSS-RSN encryption by default, and provides the Serval crypto API to aid developers in creating secure applications. **Consistent visual style:** New Commotion releases are all styled in accordance with the Commotion Human Interface Guidelines (http://commotionwireless.net/docs/hig/introduction). **Simplified debugging:** A new Commotion Debugging Helper tool makes it easy to retrieve useful troubleshooting information from a node in the event of a network problem. Fixes 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. Included Components avahi-client v0.1: Provides automatic network service discovery commotion-apps v1.1: Web-based local application portal for Commotion-OpenWRT commotion-debug-helper v0.1: A LuCI-based reporting tool to simplify the process of router troubleshooting commotion-quick-start v0.2: A one-click tool to simplify router configuration on first boot commotion-splash v1.0: A LuCI interface for configuring nodogsplash captive portal commotiond v0.1: An extensible daemon and library bundle that will form Commotion’s core administrative API and simplify the process of porting to new platforms luci-theme-commotion v1.1: HIG-compliant Commotion theme for OpenWRT routers luci-commotion v0.1: Commotion configuration pages for the LuCI web interface olsrd-dnssd v0.1: Propagates multicast DNS (mDNS) service discovery advertisements (DNSSD) over an OLSR mesh network olsrd-mdp v0.1: Plugin for signing OLSR mesh traffic serval-crypto v2.0: Cryptographic libraries and API for signing mDNS service advertisements ...

The Open Technology Institute endorses the Battle of the Mesh v6 (2013-03-28)

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

New Commotion Release (DR1) Ready for Testing (2013-03-13)

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

Warning Label Development, Part 2 (2013-02-25)

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]: Instructions are more likely to be followed if consequences are described.Sentences that include a long string of effects or other items can be made clearer by putting them into list.Keep sentences short and direct. Use no more than two subordinate clauses. Use the active voice as much as possible. Use short words of one or two syllables as much as possible. Choose commonly used, familiar words, but avoid colloquialisms and slang.Use only common abbreviations and acronyms, and then give their definition as soon after their first use as possible. Occasionally, however, an abbreviation or acronym may be so familiar to intended audiences that it may be used without a definition. In fact, some may be more familiar than the full name (e.g., OSHA, EPA, SARA, F, C, TLV, and TWA) 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: Cannot hide your identityDoes not prevent monitoring of internet trafficDoes not provide strong security against monitoring over the meshCan be jammed with radio/data-interference 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. Refrenceshttps://www.osha.gov/dsg/hazcom/hc2inf2.html#3.2.1http://www.diriwa.org/https://www.torproject.org/http://killerapps.foreignpolicy.com/posts/2012/11/05/internet_in_a_suitcase_ready_for_field_testinghttps://www.nytimes.com/2011/06/12/world/12internet.html?pagewanted=all&_r=1&http://www.wired.com/threatlevel/2011/12/internet-suitcase-dc/all/https://commotionwireless.net/http://www.usability.gov/articles/newsletter/pubs/032010news.htmlhttps://www.osha.gov/dsg/hazcom/hc2inf2.html#3.3.2https://www.osha.gov/dsg/hazcom/hc2inf2.html#3.1.8.1http://www.ismp.org/newsletters/acutecare/articles/20060824.asphttps://www.osha.gov/dsg/hazcom/hc2inf2.html#3.1.6.8 ...

Warning Label Development, Part 1 (2013-02-25)

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: Provide anonymityProvide delay tolerant communicationsPrevent monitoring of your internet useAllow you to call to non-Commotion enabled phonesProvide a simple user interface for installation or customizationPrevent monitoring of Commotion mesh communicationPrevent jamming/DoS attacks against a Commotion meshProvide access without powerProvide strong encryptionProvide protection from malware on devices 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: Provide anonymityPrevent monitoring of internet trafficProvide strong security over the meshResist jamming or DDoS attacksProtect your device from Malware In Part 2, we'll go over how we used this list of unimplemented security features to develop a warning label. ...

Case Study - Red Hook Initiative WiFi and Tidepools (2013-02-02)

This Case Study will be published in the forthcoming edition of Wireless Networking in the Developing World and is cross-posted at oti.newamerica.net. ...

Commotion and the Declaration of Internet Freedom (2012-11-20)

Over the past few decades, networks have become as important as borders, strategies of inclusion as vital as policies of coercion, and governments everywhere are struggling with the fact that increased participation means relinquished control. The Declaration of Internet Freedom, written during the summer of 2012, comes at an important tipping point. Across the world, citizen expectations to participate in building a common future have outpaced governments’ ability to provide this shared destiny. Global dynamics are dramatically shifting. Nations the world over face a common dilemma: our top-down governance structures are incapable of building the kind of widespread social resilience that modern self-determination requires. The rise of a networked globe means that civil society—organizations and individuals outside of formal government—will play an increasingly powerful role in determining the future. The Declaration of Internet Freedom intends to help guide and bolster this important change. The Commotion project aims to create a free and open Internet, supporting the goals of the Declaration both in spirit and in practice. Commotion is an open source communication tool that uses common devices to create distributed, mesh networks. Commotion embodies the five Declaration principles in the following ways: **“Expression: Don't censor the Internet”** Commotion is a distributed system that aims to prevent ease of monitoring and censorship that is enabled by the centralized nature of conventional communications infrastructure. The need for this kind of dis-aggregated capacity to connect has been evident during the ongoing uprisings of the Middle East and North Africa. With Commotion, there is no possibility for a single power switch for use by a dictator that are increasing being seen on centralized systems around the world. **“Access: Promote universal access to fast and affordable networks”** Commotion will be available to individuals using a wide range of technical devices—including mobile phones. The mesh system is decentralized and readily extensible which makes it inclusive by its very structure. **“Openness: Keep the Internet an open network where everyone is free to connect, communicate, write, read, watch, speak, listen, learn, create and innovate.”** The freedom of humans to communicate is the paramount belief and motivation behind Commotion. The open source nature of the Commotion project also emphasizes our commitment to this principle in Commotion's creation and by freeing the code for innovation. **“Innovation: Protect the freedom to innovate and create without permission. Don’t block new technologies and don’t punish innovators for their users' actions.”** The world’s future depends on shared prosperity, which will require a default to openness and innovation at every level of human interaction. Commotion aims to create an open local network which innovators can extend and build upon to create novel applications that serve the needs of their communities. **“Privacy: Protect privacy and defend everyone’s ability to control how their data and devices are used”** Commotion is a global alliance of individuals and organizations, some of whom are exclusively dedicated to individual privacy and the prevention of unwanted intrusion and surveillance. A global capacity to prosper and to live a safe life may seem like an overwhelming ambition. Yet never before has humankind owned the tools that will allow us to immediately call upon each other for support to persevere through challenges, to adapt, change and grow. Our individual destinies are wrapped up in the destiny of life across the globe—the communications revolution has collapsed time and space, and has created both mayhem and empathy. The Commotion project intends to put in place an infrastructure that will democratize today’s communication. As governments struggle with a world where power is being rapidly redistributed out of formal institutions and into the hands of people, the developers of Commotion intend to work with other like minds who, together, will take these ingredients and help discover the alchemy of modern democracy. ...

The Cost of Mesh Networks (2012-11-14)

A common question Commotion technologists hear is “How much does it cost to set up a mesh network?” Like any other infrastructure, the cost of organizing a mesh network varies depending on the desired coverage area and what services the network will host. But, there are some basic figures to keep in mind while you plan a mesh network. The following five points outline the costs of a “last-mile” network designed to spread internet connectivity throughout a mesh network. ...

Brainstorming how neighborhood power grids could work with community mesh networks (2012-11-06)

A community wireless network can provide a reliable conduit for many types of communication. We might initially think of this communication within a human context — sharing music with your friend across town, spreading news to your city about an upcoming event, responding to an emergency, or asking questions of a local politician on a discussion forum. But, in a world that runs parallel to the Internet we use everyday, our communication networks are used by all sorts of machines to make our society an exponentially more productive and automated place. These “robots” in our communities, all of those appliances and devices with embedded computers, could also benefit from a community mesh network. Moving into the future, we’ll be inspired to redesign some of these helpful robots and algorithms to be more decentralized and useful on hyperlocal levels. In Detroit, we’re thinking more about what role a community wireless network could play in organizing automated communication to better sustain our human neighborhoods and communities. For example, a house produces a never-ending stream of usage data ranging from kilowatt-hours of electricity to gallons of water to cubic-feet of gas. Hobbyists have taken an interest in this data, especially electrical usage. The current trend of home energy information technology is inspirational yet clearly missing some components that would increase democratic control. Energy companies have certainly accumulated a wealth of innovative and efficient systems for large-scale electricity distribution, but what if we came up with simple systems that enable neighbors to easily share power grid information over a community wireless network? Here, we enter the realm of local energy sharing and distribution built on locally owned and controlled data systems. Beyond the benefits of each home knowing its impact on the energy use of the community, this distributed monitoring could be useful to people who use alternative energy sources like wind or solar power. These energy systems require a charge controller and other electronics which often have data sharing systems or APIs similar to usage monitors. This software could use community wireless networks to manage energy sharing. For example, a house with solar panels could share energy with its neighbor with wind turbines on sunny days, and the neighbor with wind turbines could share energy with the solar house on windy days. On days that are both windy and sunny, both houses could contribute to a shared pool of batteries or donate the excess power to local community services at no cost to themselves. Household energy usage data could be aggregated within applications like Tidepools so community members could compare location-specific energy consumption. And, because of the self-healing nature of mesh networks, these energy-sharing systems could be more resilient during times of disaster or failing infrastructure. In Detroit, the team at The Work Department has also been brainstorming with two community projects: Power House Productions and Mt. Elliott Makerspace. Whether through youth workshops or architectural installations, these groups work to introduce people to alternative energy and neighborhood-level systems — concepts that can be related to community wireless networks. We're also keeping tabs on an exciting project called the “Solar Pocket Factory” because small-scale solar technology could play a crucial role in letting a delay-tolerant mesh network scale. As our conversations progress, we’ll post more notes on this blog. ...

Updating a Commotion package (2012-11-01)

In our previous blog post, we walked through the process of creating an OpenWRT package to provide a ws-routing server. We've since continued development on this, and would like to share our process for updating the OpenWRT package after making bugfixes. We'd also like to introduce the commotion-chat package that puts the ws-routing server to use. After we fixed the bug in the ws-routing server code, we needed to update the OpenWRT package to reference the most recent Git revision. Below, you can find a quick guide on how to update an OpenWRT package. First, you need to update the Git revision. Do this by editing the package's Makefile and changing a variable: ...

Step-by-step - creating and installing a package for Commotion (2012-10-08)

Here at The Work Department, we've been busy cooking up systems to experiment with applications that utilize node-to-node mesh connections and are eager to share them with you. In particular, some of the example applications that we proposed in our Exploring "Meshaging" post have been taking form. We want to offer you the tools to experiment with what is possible given the unique architecture of a mesh network. The Commotion router software is built atop OpenWRT, a Linux distribution designed for routers and other small devices. OpenWRT has a package management system, and Commotion’s code is kept in a separate feed and package. A developer can integrate additional features into a Commotion network by writing or porting applications and packaging them for OpenWRT. Below, we explain the process of porting and packaging an application (in this case, a small websockets server, ws-routing, and dependencies). Ingredients You'll need a few things to follow along: **A computer! **Assuming you are currently using a computer, this should be easy. Make sure you have some space on your hard drive to download the packages.**Terminal access and a few common commands.** You'll need these tools, including GIT and Make, to download and compile the latest code from the repositories.**Wireless Router(s).** This hardware is necessary to serve your mesh network. You can read more details on the hardware that we use here: Installing Commotion on Wireless Nodes.**Time. **Like a good stew, some of these scripts can take time before they are complete. You might anticipate about one or two hours until you are up and running.**Friends.** Not required, but collaboratively learning and working together can be an important part of setting up mesh networks. Step-by-step to mesh networking delight Once you have the essentials listed above you can start mixing it all together. First, let's build the packages! You can do this by opening your terminal and entering the commands listed below in order. Anything after a number sign (#) is there to provide additional instruction and shouldn't be entered into the command line. The setup scripts and make commands can take time to run, so that would be a great time to read more of the blog or the Mesh Resources wiki. ...

Diving deeper into "meshaging" (2012-10-08)

In our recent blog post about messaging, we introduced our “meshaging” (basic chat) application and explained some of the plans for our future work with it. We are still working on this project and have diagrammed how exactly communication happens in the application. This has improved our internal process and we think it's beneficial to share. Compared to centralized, server-based systems, decentralized networking applications are a bit messy: with the benefit of decentralization comes the cost of increased complexity. Maintaining consistency of data across a mesh network is a hard problem to solve, and there are plenty of interesting approaches to address this problem. As designers, we became interested in embracing inconsistency: what systems could exist, or even thrive, in a network of inconsistent connections or transient devices? This is important to consider because a mesh network could be constantly changing. To explore the subject of decentralized communication, we decided to work through the design of a mesh network chat application in which nodes would serve as chat hubs. We considered what a decentralized chat application would look like with varying levels of message-sharing or replication between neighbor nodes. We used the analogy of a chat application because of its simplicity and its generality, but you can replace “chats” with any sort of one-to-many message. Actually, as an exercise, you really should try and think of other types of messages that might be transported over a mesh network! Imagine a network of thermometers in a greenhouse, or a network of motion sensors that trigger floodlights, or many other possibilities. Diagram 1 (above) illustrates a chat application in which nodes broadcast messages only to locally connected clients (zero hops). The numbers 1, 2, and 3 represent nodes connected to the mesh network, and the little people icons designated with letters represent the people connected to each of those nodes. In this scenario, users can chat with other users on the same node. For example, Person H can chat with Person J because they are both connected to Node 2. They cannot however chat with Person K or Person D, because those users, though connected to the mesh network, are on different nodes. Diagram 2 **(above) illustrates users on Node 1 communicating (zero-hop/no-broadcast chat system). **Diagram 3 (above) illustrates a next-neighbor broadcast chat system, in which nodes would broadcast all messages to nodes within a one-hop distance. This system would allow a person to chat with people connected to their own node or their next neighbors, but not nodes two or more hops away. In Diagram 3, Person G can chat with Person C because they are both connected to Node 1. But in this stage Person G can also chat with Person J because J is connected to G’s next neighbor, Node 2. Person G could not chat with Person L though, because Node 3, which Person L is connected to, is two hops away. Diagram 4 (above) shows the next-neighbor broadcast chat system, illustrating users on Node 1 communicating with each other and users on Node 2. We hope that these diagrams can help spur conversations about decentralized application development. Stay tuned for more meshages. ...

The making of... (2012-09-19)

This site has been in the making for months and we’re excited to share it with the public! It’s intended to be the online home for the Commotion project — connecting both developers and users to mesh networking tools. We’ve been working with the Open Technology Institute (OTI) and the Commotion community of developers for over a year and this marks a major milestone in our collaborative relationship. Many steps have brought us to this point and many minds have contributed to the process. We’d like to share those key steps with you. Creating the brand identity In May we finished the brand identity for Commotion, which has informed all of our work to date. The versatile and accessible identity (a complete set of logos, typefaces, colors, usage standards, and language) was created for use in multiple environments — online, in print, on mobile phones, and in software. It’s important to us that people experience the Commotion identity consistently, no matter how they are interacting with the project. So, for those of you who have been following Commotion, the look and feel of this website should be no surprise. It adheres well to the brand identity and gives us an opportunity to demonstrate how to implement the identity and expand the visual palette — in a very public and ready-to-use way. Conducting user research We include user research in our planning and design process whenever possible because it’s essential to know what the actual users and surrounding community are thinking. In the early stages of the project, we conducted simple surveys among the Commotion community. Deeper into the process we conducted interviews with four users who were working with neighborhood mesh networks being used as testbeds for Commotion. This research shed some light on how people thought about Commotion, how users actually experienced its early software tools, and what common problems users were facing. This new knowledge informed how we organized the site to speak to two major audiences: developers and end users of the software. Dreaming of user interfaces We spent time prototyping user interfaces and developing Human Interface Guidelines (which are a set of recommendations for developers) with the useful input of many people in the Commotion community. This helped us build a visual framework for Commotion’s user experience and begin to set some standards for how the tools will work across multiple platforms. We established visual languages (descriptive, action, learning, warning, and in-progress languages) that carry through to this website. By interacting with other developers and designers during this “dreaming” stage, we incorporated more ideas and eventually settled on Human Interface Guidelines that meet the community’s needs. Researching other communities There are many successful open-source software projects out there, and it was important to take a look at their structures so we could learn from others and find out what we could improve on. We produced a brief report about four different open-source software communities, which is available here. We compared documentation, support, issue tracking, and governance systems, among others, for each community. This research provided a good overview of what systems were available and widely used. It informed how we structured this site, especially the home page. Drafting designs We started our website design process by creating a sitemap and set of wireframes to outline the navigational structure and content. We went through several iterations (over the course of a few weeks) based on feedback from Commotion developers and OTI staff members. Once this was complete, we began drafting designs for the home page and a few interior pages. We went through a similar revision process with OTI and created several iterations before coming to a final version which is the site you see today. The home page is the primary way in which we invite two different audiences to find what's relevant to them — new visitors and returning visitors. Because Commotion is such a young project and because the public has little experience with mesh networking, we wanted to create an easy introduction to the project while allowing returning visitors to access the main navigation menu. The details This site is run on Drupal and the Omega base theme. It is responsive to browser size (try changing the size of your browser!) and has been built with visual accessibility in mind (with sufficient contrast and without relying on color coding). It makes frequent use of the Context, Media, Panels, Wikitools, and Book modules in Drupal. Using Drupal’s basic role distinctions, different areas of the site will eventually be edited by different teams or staff members as the Commotion community evolves. Team leaders will have access to specific areas of the site that they are responsible for. And, blog submissions are welcomed from anyone working in the Commotion community. In fact, if you have something you’d like to write about, contact us! Thanks to everyone who has been involved in this design process! We look forward to a vibrant online community that helps newcomers try out and understand mesh networking. Please share your feedback about the new site by submitting a comment below. ...

MeshTether test release (2012-08-23)

Commotion MeshTether is an Android app that aims to make it possible to connect to OLSR meshes with a single click of a button. It comes configured for the Commotion mesh by default, but can be entirely configured, and can have multiple mesh "profiles" to choose from. There are two information tabs: Links and Info. Links shows all of the first-hop links and Info shows the entire wifi config and olsrd.conf settings. Additionally, you can share/email debug information from the app's menu. Its working pretty well on the Nexus One I'm using for testing. I've also tried the HTC Wildfire, Motorola Droid, and HTC myTouch 3G. The mesh profiles are implemented like this: (default) uses the wifi/ip settings from the preferences and the olsrd.conf that is included in the appthe rest are scanned from the file system in two places:in the app's app_bin/ folder/mnt/sdcard/MeshTether (i.e. the MeshTether folder on the SD card)the scanner looks in those folders for *.properties files and takes the filename as the profile name (i.e. myprofile.properties will be linked to the "myprofile" item in the profiles menu)if there is also a myprofile.conf next to the myprofile.properties then it will use that as the olsrd.conf. otherwise, it'll use the included olsrd.confthe properties options are:ssid=commotionwireless.netbssid=02:CA:FF:EE:BA:BEchannel=5ip=172.29.0.0ipgenerate=truenetmask=255.255.0.0dns=8.8.8.8all are required, except 'ipgenerate', which marks the 'ip' as the root for the IP generation algorithm. If 'ipgenerate' is unset or not 'true', then the 'ip' is used as is. Here's a test apk: https://guardianproject.info/builds/CommotionMeshTether/2012-08-22/md5: 176008560f00d8cef65f0e3e781884e1sha1: b9151fb635185880007411fd49e8ab5b254ad750 Give it a whirl and let us know how it works for you! ...

Exploring "meshaging" (2012-08-22)

Over the past few years, The Work Department has been active in building community wireless networks in Detroit. We have experimented with different types of hardware and software, and we have helped neighborhoods build useful networks to share internet connectivity and provide local file sharing. Something we haven’t had much of an opportunity to explore, though, is building more elaborate systems that leverage the unique traits of mesh networks. As we worked through other parts of the Commotion project, we brainstormed ideas for wireless mesh applications. We noticed that our ideas would often replicate existing web services — e.g. a local fileserver for music or movies, or a local message board for neighborhood discussion. We began to wonder what would make a community wireless application more appealing than using a centralized Internet-based application. We agreed that it wouldn’t be enough to offer someone the simple satisfaction of knowing their data is decentralized… there would need to be some other benefits to using a local application. What would these benefits be? What is special about the architecture of a community wireless mesh network? In pondering these questions, we considered what is provided by these networks — earlier, I mentioned that the networks provide internet connection sharing and local file sharing, but that’s only a part of the story. These networks also provide something much grander: they become community institutions. Unlike the Comcast hardware that is bolted out of arm’s reach on a utility pole, our community wireless equipment lives on our porches, in chicken coops, in our bell towers, and next to our desks. Each piece of equipment has a story behind it. We know who held the ladder while it was being installed and who lent their hammer drill to run a cable up to it. A community mesh wireless router’s IP address is more than a 32-bit number. It has history and meaning. How can we build applications that reflect and enhance this? I had the good fortune to meet Adam Magaluk at Detroit’s hackerspace, OmniCorpDetroit. Adam works on mesh wireless systems at Illuminating Concepts, and is deeply interested in OLSR and embedded systems. We are both young programmers and share a preference for modular and decentralized systems. During our initial conversations and research, we ended up favoring web browser based application development. This way, people who might want to use an application wouldn’t have to download anything. Since today’s web browsers have lightweight streaming messaging capabilities with WebSocket, we would have a lot of flexibility in application development. To build a web browser based application, we can start by limiting the amount of work the server does to a bare minimum. In the circumstance of a chat application, we can say that the server should simply keep a record of who is connected to a chat session (in a sort of subscription model) and then, as messages are posted, transfer messages from the publisher to the subscribers. Limiting the duties of each mesh node to passing messages and keeping track of connected clients ends up being beneficial in two ways: it conserves computing resources and encourages decentralized application development. Since most community wireless routers are low power, low cost devices running with MIPS CPUs and 4-16GB memory, the former benefit is clearly attractive. The latter benefit is a bit more complex — do we really need a fully decentralized application? Why can’t we just have a little bit of local node storage? It sure would make things simpler if we could have a local data cache instead of trying to develop a peer-to-peer storage system, but for now we’ll embrace this limitation when designing applications. To begin experimenting with the core concepts of lightweight messaging systems that can work with community wireless network hardware, we built an example application to provide WebSocket service to clients connected to a Commotion access point. This service can be utilized by anything on the network, but in our first example application, it is employed by a web application served from a publicly accessible LuCI URI linked from the splash page. The application provides a simple interface to chat with other people who have connected to the local node’s websocket chat system. Thanks to the work of Hans-Christoph Steiner (from The Guardian Project) on the jsoninfo plugin, OLSRd can easily provide some useful network information as a json object to web applications. Above the network layer, our WebSocket message server can provide data about connected clients and possibly other information in the future. After you get your head wrapped around the WebSocket server, its underlying restrictions, and the mesh network playing field, you can start to imagine various situations where local messaging might be interesting. With an idea in mind, a developer can easily jump into a familiar web application development environment. If you have used things like WebSockets or socket.io, you already understand the core concepts of writing a mesh network application using these building blocks. As we build more features into the platform, it will offer more options for developers. Next Steps Currently, the system provides a messaging service that doesn’t utilize node-to-node mesh connections. As it stands, we can develop some interesting and useful applications, but there is definitely a lot to gain from adding functionality and possibly revamping things in the interest of security or privacy. Our next major task is to begin experimenting with systems that- allow neighboring nodes to subscribe to each others’ connections. To use the chat application as an example of how this might be used: a chat participant might be able to start a conversation with people connected to their own mesh node and its next neighbors, or some other arbitrary number of hops. We would also like to experiment with simple implementations of shared / distributed storage. Again, to use the chat system as an illustration, we could have chat participants store chat logs and offer them to new participants who broadcast a request for the last N minutes of conversation. There is a lot of distributed storage work for us to reference, of course, so we have our work cut out for us! Aside f/rom enhancements and features in the messaging system itself, we have plenty of ideas for the actual applications. We have recently been prototyping games that could use a neighborhood or multi-neighborhood mesh network as a playing field. We have found that prototyping and brainstorming games is an enlightening process: it helps explain the ins and outs of the technology to people, and also presents clear challenges to create obvious and attainable goals within the technology’s limitations. We’ll be sharing some “capture the flag” style game ideas that utilize a “meshaging” system during the next couple of weeks. ...

Building successful online community for open-source development (2012-05-30)

In order to help build the most effective Commotion online community, we’ve conducted basic research to gain an understanding of infrastructures that other software development communities use. We focused on open-source projects that are used widely. We found that, while a variety of communication strategies, governance structures, and social cultures exist, there are some shared elements that appear to make a community strong and effective. In our full report to the Open Technology Initiative, we reviewed Drupal, Mozilla, Android, and Ubuntu Linux. In this post, we include a simplified comparison of those communities and share the conclusions we drew from our research. See an overview of some large open-source projects (PDF) Recommendations for Commotion Online Presence Because Commotion is a new and evolving project, we see an excellent opportunity to build an effective online community by implementing the best practices used by other open-source communities. Commotion’s online presence should easily direct different audiences (developers, users, journalists, funders) to the information they need the most while encouraging community interaction and collaboration. Potential Site Outline Based on our current understanding of Commotion’s needs, we’ve created the following simple outline for the project’s complete website. We will develop a more detailed sitemap in the next phase of our work. Over time, of course, the Commotion website should evolve to meet the needs of developers and users. This will require that Commotion leaders pay close attention to those needs and quickly respond to feedback and innovation from the community. commotionwireless.net Home Page (include a Get Involved area and Getting Started area)Blog (managed by an editing team or committee)AboutDocumentationUser ManualDesign GuidelinesHuman Interface GuidelinesCommunity GovernanceProject Partners (Open Technology Initiative, Guardian Project, OpenBTS, Serval Project)Developers (goes to https://code.commotionwireless.net)Press Open Governance In order to promote long-term investment and encourage a wide array of contributors to get involved, we recommend that OTI establish a clear and written governance structure for the Commotion project. This should include roles of various people in the community and general expectations for how contributors should work together and make key decisions. Many examples are available from other projects. The governance structure should be posted on the Commotion site and be recommended reading for all newcomers to the project. This will help contributors understand how they can be involved and how their work will be valued. Future Considerations Translation and other localization work should be planned at an appropriate time in the future. The communities that we evaluated each have specific areas of their sites dedicated to localization efforts. This is also a good opportunity for non-programmers to contribute to the project. Want more? Read our full report at the Commotion wiki. ...

An audit of current Commotion user interfaces (2012-05-09)

With the goal of creating both an intuitive and accessible user experience (UX) across a sampling of devices that will run Commotion, we surveyed and analyzed the current state of the existing interfaces. We deployed a test network using the three software components currently in development phases: Commotion on an Ubiquiti Picostation (router), The Guardian Project’s OLSR Mesh Tether on an Android handset (phone) and Commotion on Linux (laptop). In anticipation of The Serval Project’s forthcoming work around meshing mobile devices with Commotion, we also researched the current release of Serval Mesh. We documented each step with screenshots, which are compiled here. After the initial audit, we compared and contrasted each workflow, documenting any issues that arose during the process and were then able to make recommendations on how to improve each of the interfaces and workflows and make them consistent across platforms. Our process was unique in that our auditors represented a range of skill levels and backgrounds. We seek to represent this diversity when creating user interfaces that are intended for a broad range of users. For example, Auditor 1 is a self-taught web developer with advanced skills in networks and mesh networks specifically. Auditor 2 is a designer with intermediate knowledge of networks and some experience setting up networks. Auditor 3 is a designer with basic network skills and very little experience setting up a network. We feel that these varied levels of experience with networking are important. The advanced user can help guide the process for successful installation and the inexperienced users can communicate what is helpful while illuminating confusing aspects of the process. Commotion Router: Installing on an Ubiquiti Picostation (See a PDF of the process.) The router interface and workflow was the most complex of the three platforms we tested. The welcome screen includes rules for accessing the network and the option to “accept” or “decline” access. Though that seems straightforward, after clicking “accept” we were redirected to an error message, “302 found.” With no explanation of what caused the error or what to do next, we manually typed in the router’s IP address to attempt to access the network. This seemed to work, as we were then taken to the Commotion login page. The default settings do not require a username and password, though this is not noted anywhere, so we clicked the “login” button and were taken to (another) welcome screen. This welcome screen told us that we were now connected to a mesh network and included a description of what Commotion is, with a link to even more information about the project. To configure the settings of the mesh network, we clicked on “Administration,” which was a link in the upper right corner. Once inside the Administration section, the menu links on the left changed. Initially, the left menu had one link: “Overview.” When inside the Administration section, the menu no longer includes “Overview” but changes to include “Commotion, Status, System, Services, Network, Statistics, Logout, and Voice” links. From the “Commotion” menu we selected “Mesh Config (Manual).” Confusingly, when selecting the “Commotion” menu the “Status” menu link changed color as if we were selecting it instead. Also, the link in the menu is called “Mesh Config (Manual),” though when on this page, the title is “Configuration.” From the “Configuration” page we changed the base-name from “commotion_52_51” to our custom network name “meshshaging.” We then clicked “Save & Apply.” A loading wheel spun and read “waiting for router,” however no validation message ever appeared. A line of text at the top of the pages suggested rebooting the node after changing any settings, so we found the link to “Reboot” under the “System” menu. We were taken to another screen where we could select “Perform Reboot.” A message appeared reading “Please wait: Device rebooting…” However, we never saw any validation message. Once the device was rebooted, which we noticed from watching the status lights on the actual device, we verified that the network had been renamed via the airport/wireless window. This process is also documented in the UX flowchart here. OLSR Mesh Tether Phone: Installing on an Android handset (See a PDF of the process.) Once the OLSR Mesh Tether was installed on the Android device, and the program was launched, we were taken to a screen showing a log of activity, a “Traffic” button, a “Clients” button and a large “Start” button. In order to access the settings, we had to push the physical “Settings” button on the handset, not in the interface. This menu was a long list of settings, some with a bit of explanation underneath and some without any explanation. We selected “SSID” which was the first listing in the settings. A pop-up appeared titled “SSID (Network Name)” with a default value of “olsr.org” and an “OK” and “cancel” button. We changed the name to “meshshaging” and selected “OK.” We then were back at the main Settings menu, where we selected “Channel,” which was third in the list of settings. A pop-up appeared with the title “Channel” and a list of channels, from 1-12, to choose from each with a channel number and the corresponding frequency. We selected channel 7 and were taken back to the main settings menu. These steps are the only steps required to set up the mesh, but when we tried to access the network we received an error message titled, “Root Access,” telling us we needed to have root access in order for the software to actually work. So our process with the Android device had to end there. This process is also documented in the UX flowchart here. Serval Mesh Phone: Installing on an Android handset (See a PDF of the process.) We also looked at the Serval Mesh software on the Android device. The current release of Serval Mesh creates a mesh-based self-powered and self-organizing phone network between WiFi-enabled phones that requires no other infrastructure. We chose to evaluate Serval’s interface as well, because it relies on mesh networks and many of the settings might be similar. When Serval Mesh is launched, the first screen is not a welcome message, but a warning titled “HERE BE DRAGONS!” and a long paragraph about the program still being in development and containing various bugs, and that it may interfere with normal use of your phone. There is an “I Agree” and a “Cancel” button. We chose “I Agree” and were taken to the “Setup Instructions.” The instructions told us that we would have to pick a phone number, which cannot start with “11” and must have more than 5 digits. There is an “OK” button that we clicked after thinking about a number. Then we were prompted to enter the number we chose, which we did, and clicked “OK” - phone calls could now be made. This process is also documented in the UX flowchart here. Commotion Laptop: Installation on a laptop running Linux This installation process has no graphic user interface. All commands are via terminal input and only an experienced user could have success navigating this process. The commands are below and the following analysis is limited. ...

Neighborhood network builders- a summary (2012-05-08)

As part of our research for the Commotion Human Interface Guidelines, we interviewed four people who have been involved in building community wireless networks around Detroit (see earlier blog posts). Based on these interviews and our experience working with various users, we recommend that Commotion developers and organizers implement the following concepts: ...

Integrating design and development to shape Commotion’s brand identity (2012-05-01)

At The Work Department, we’ve had the privilege of creating Commotion’s brand identity from conception to completion. If you haven’t heard about it yet, Commotion is an open, yet secure, circumvention tool to create decentralized mesh networks. We are collaboratively developing the tool with The New America Foundation’s Open Technology Initiative. Our challenge was clear: to create an accessible and flexible visual identity for this evolving open source software project. Our early approach was very open – we began with a discovery phase in which we surveyed the Open Technology Initiative (OTI), The Guardian Project, The Serval Project and a few other members of the mesh development community to understand their views on the software. We quickly found a wide range of opinions about aesthetic preferences and public communication strategies for Commotion. We analyzed input from about 15 people and shared the material with OTI to get additional feedback. We made a few conclusions about our direction. First, we planned to embrace potentially different Commotion audiences. Second, we needed something that would be simultaneously utilitarian, accessible, and trustworthy. Third, we wanted to avoid alienating forms that are often presented alongside emerging technologies and represent that mesh technology works in a humanistic way. We began to define our audience as: people who seek network connectivitypeople who seek communication freedomanyone cut off from the internet, whether by Mubarak, Comcast or Katrina We were excited to take on this branding work because we deeply believe in the power of community wireless networking. We wanted to create an identity that we could be proud of – something that would communicate all of the project’s great values and represent our design philosophy. We began creating the identity while development work was also being done on the Commotion software. This rarely happens, so often design is considered the “icing” or top layer in a process while, in reality, we believe design should be integrated at all phases of a development project. We thought a lot about the agility of the design and how it could flex to accommodate the software’s range of current and future functions. Because the software is under development and will be touched by many developers around the world, we imagined a flexible brand system with a range of utilities. For example, the nodes in our design can be modular and be used in different ways. Creating the logo was a vast process. We started by gathering an audit of existing software to understand what else is out there and look at common visual languages. We noticed trends in technology and networking brands and also began to collect graphic elements that might communicate what “mesh” is. From there we started the sketch process on paper. We then narrowed down our ideas and moved into the digital world. You can take a look at our digital sketches in our Flickr pool. Our client and project partners were able to watch our ideas on Flickr and provide us with feedback throughout the entire process. This type of open and collaborative design fuels our philosophy at The Work Department. We are constantly seeking ways to solicit stakeholder and user input to ensure that our products are relevant and accessible. After spending several weeks auditing existing brands and developing our own design ideas, we presented three full brand options to OTI. They were each distinctively different but stemmed from the same overarching goals – meaning they embodied these themes: easy to useself determiningcircumventionutilitarianmultiusegeneralizedversatilehumanisticeasy to translate in the future (L to R, R to L) You can view our Commotion Identity Proposals here. OTI staff chose the final direction for the identity and we created complete brand identity guidelines. We’re proud to be an integral part of the Commotion project and excited about OTI’s commitment to good design. While other mesh network projects have not created a professional identity, Commotion is being built on a strong foundation of flexible and collaborative design that can be used by all the developers who work on it. This will create lasting consistency and credibility among users, developers, and funders. As designers, this has been a unique opportunity to be involved early in a software development process (instead of at the tail end). We’ve worked with Commotion’s software developers throughout our process. Thanks to this, and our previous experience working on community wireless tools, we are able to significantly inform how the open source development process moves forward. It’s rare that a project takes such an integrated approach – bringing designers and developers together each step of the way. We love working this way, and think that this approach should be used more often. It allows us to ultimately create a better product together – a software tool that offers an outstanding user interface, is credible, is easy to use, and is flexible enough to evolve around the world but maintain a core set of functions and standards. We’re convinced that any software project that integrates designers, developers, and user interface thinkers is far more likely to succeed over the long-term. We’re excited to soon release graphic assets for the Commotion Brand Identity. These files will be publicly available in just a few weeks – check back here for updates! ...