Commotion R1 Breaking Changes

2014-01-10 / Dan Staples

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 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 In addition, all client networks are now bridged and use the RFC1918 private address range 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 “” 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.


R1, upgrade