<div dir="ltr">For the Digital Stewards flashing point, I recommend including a reference to the MagicNet installation checklist, and include it as an appendix: <a href="https://docs.google.com/a/opentechinstitute.org/document/d/1cLLBCwi3XPpUL8Pm3dNQmeMq7FQd3F0yAcyu4jU54z8/edit#heading=h.yn41mcf8hzzw">https://docs.google.com/a/opentechinstitute.org/document/d/1cLLBCwi3XPpUL8Pm3dNQmeMq7FQd3F0yAcyu4jU54z8/edit#heading=h.yn41mcf8hzzw</a><div>
<br></div><div>You may also choose to include as a prologue that creating, going through, and refining this checklist before we left for Detroit was key to finding some of those problems, and that it prompted Dan to make a special build for the AMC.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 26, 2013 at 1:19 PM, Ben West <span dir="ltr"><<a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Awesome, detailed write-up! It's great that you used the opportunity to field feedback from members of the public.<br><br>FWIW, I've found that changing a node's channel only seems to work reliably when you just reboot the node. Likely a limitation of the mac80211 driver library.<br>
<br><div class="gmail_quote"><div><div class="h5">On Tue, Jun 25, 2013 at 5:19 PM, Dan Staples <span dir="ltr"><<a href="mailto:danstaples@opentechinstitute.org" target="_blank">danstaples@opentechinstitute.org</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<div bgcolor="#FFFFFF" text="#000000">
<p><b style="font-weight:normal">
</b></p><p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><b style="font-weight:normal"><span>Here's
an initial reportback from the AMC conference. A more
detailed report will likely follow. Thanks Andy for the help
on this!<b><br>
</b></span></b></p><b style="font-weight:normal">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span><br>
tl;dr: it had a rough start, but <a href="https://docs.google.com/file/d/0B0hY7epZlXFaYjhaRVBPZGpxeUU/edit?usp=sharing" target="_blank">turned
out awesome!</a> <br>
</span></p>
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span><br>
</span></p>
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>-Dan<br>
</span></p>
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span><br>
----<br>
</span></p>
</b><p></p>
<p><b style="font-weight:normal">
</b></p><p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><b style="font-weight:normal"><span></span></b></p><b style="font-weight:normal">
</b><p></p>
<p><b style="font-weight:normal">
</b></p><p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><b style="font-weight:normal"><span></span></b></p><b style="font-weight:normal">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>At
the 2013 Allied Media Conference (AMC), the Open Technology
Institute partnered with local Detroit Digital Stewards and
Red Hook Digital Stewards to construct a conference-wide
mesh network. The purpose was to provide network and
Internet access to the conference attendees, provide an
additional training opportunity for the Detroit and Red Hook
Digital Stewards, and serve as a testing opportunity for
Commotion DR1.1.</span></p>
</b><p></p>
<b style="font-weight:normal"><br>
<span></span>
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>Process</span></p>
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>The
construction process for the network was reminiscent of the
process from the previous AMC, as detailed in the </span><a href="https://docs.google.com/document/d/1rf8VETPlJwbgM9p9cU2evIPPjwqOdhP_S9xlsxdGFFo/edit?usp=sharing" style="text-decoration:none" target="_blank"><span style="font-size:16px;font-family:'Times New Roman';color:rgb(17,85,204);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">AMC 2012 Commotion
Deployment Report</span></a><span>.</span></p>
<ul style="margin-top:0pt;margin-bottom:0pt">
<li dir="ltr">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>Detroit
Digital Stewards spent Wednesday afternoon from around 3PM
until 5PM installing Commotion DR1.1 on PicoStation M2
(PS) and NanoStation M2 (NS) units.</span></p>
</li>
<ul style="margin-top:0pt;margin-bottom:0pt">
<li dir="ltr">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>Basic
information was recorded for each node - it’s name, mesh
IP address, and label.</span></p>
</li>
<li dir="ltr">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>Several
customizations were made - changing the Administrator
password, changing the splash page timeout to 24 hours,
updating the splash text, and changing the node name and
SSID to match it’s location. Nodes were left “stock”
otherwise.</span></p>
</li>
</ul>
<li dir="ltr">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>Installations
were conducted on Thursday, the day prior to the official
start of the conference sessions. This consisted of a tour
of the sites to be installed by the team, which included
OTI staff and Detroit Digital Stewards. In the afternoon
the team was expanded as the Red Hook Digital Stewards
arrived.</span></p>
</li>
<ul style="margin-top:0pt;margin-bottom:0pt">
<li dir="ltr">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>Four
nodes were installed in McGregor conference center, two
in the Education building, two in the Arts building, two
in the Hilberry Student Center, and one in the
Auditorium.</span></p>
</li>
</ul>
<li dir="ltr">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>Jonathan
set up a Tidepools instance for the conference that
included a map, session browser, and twitter feed. It was
added to the nodes' application portal. It received
excellent feedback!</span></p>
</li>
</ul>
<br>
<span></span><br>
<span></span>
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>Challenges
Discovered</span></p>
<br>
<span></span>
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>Several
challenges were discovered through the process of building the
network.</span></p>
<ol style="margin-top:0pt;margin-bottom:0pt">
<li dir="ltr">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>Changing
a node's WiFi channel in the presence of other Ad-Hoc
nodes </span><span>does
not work</span><span>.</span></p>
</li>
<ol style="margin-top:0pt;margin-bottom:0pt">
<li dir="ltr">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>This
was discovered by Will Hawkins and Dan Staples while
preparing for the AMC.</span></p>
</li>
<li dir="ltr">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>The
problem occurs if you have two nodes meshing on channel
A, and then try to change one of them to channel B, it
will go to channel B and then right back to channel A a
few seconds later. This is due to the way adhoc cells
try to converge. We were unable to coerce iw into
staying on a channel when upping the adhoc interface.
This is unsolved.</span></p>
</li>
</ol>
<li dir="ltr">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>We
found immediately that the nodes in McGregor, which were
all connected via wire to the WSU LAN, were not getting
DHCP leases from the gateway.</span></p>
</li>
<ol style="margin-top:0pt;margin-bottom:0pt">
<li dir="ltr">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>This
issue was solved by increasing the DHCP timeout in the
/lib/netifd/proto/commotion.sh script. We had to
increase it to 60 seconds in order to get DHCP leases
from the WSU gateway. A feature has been added in the
LuCI interface to set the DHCP timeout .</span></p>
</li>
</ol>
<li dir="ltr">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>The
first major issue discovered during the conference was
high packet loss and long ping times to the access points.</span></p>
</li>
<ol style="margin-top:0pt;margin-bottom:0pt">
<li dir="ltr">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>This
was first seen when connecting to any of the access
points in the McGregor building, but was not seen in the
other buildings.</span></p>
</li>
<li dir="ltr">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>At
first we thought this was a problem of RF interference.
We first tried turning down the TX power on all of the
nodes, and sometimes even turning off nodes. This would
help for a short period of time, but eventually the
problems returned.</span></p>
</li>
<li dir="ltr">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>Finally,
we turned off the wireless adhoc interfaces on all the
McGregor nodes, put all their APs on different channels,
and had them mesh over Ethernet. This solved the
latency/packet loss issues within McGregor.</span></p>
</li>
</ol>
<li dir="ltr">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>Another
major problem was establishing good mesh wireless links
between the buildings. This proved to be an extremely
challenging problem, and consumed several hours of
troubleshooting.</span></p>
</li>
<ol style="margin-top:0pt;margin-bottom:0pt">
<li dir="ltr">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>The
initial task was to get two NanoStations in McGregor to
wirelessly mesh with Picostations in the adjacent
buildings. The NanoStations were aimed from second floor
windows towards the adjacent buildings. The signal
strength at the neighboring buildings was marginal or
nonexistent. This was first thought to be an aiming
problem, or interference between the nodes.</span></p>
</li>
<li dir="ltr">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>To
combat the possible interference or RF saturation, one
of the NS units was powered off. We then optimized the
output power of the remaining NS and PS units nearby, so
that each would show a received signal strength of
around -40 to -50 dBm (very strong). We then replaced
the NanoStation with a PicoStation, thinking DR1 might
have compatibility problems with the NS units, or issues
with MIMO streams. After this change and the TX power
optimization, the packet loss and ping times (~5
seconds) were still excessively high.</span></p>
</li>
<li dir="ltr">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>Andy
Gunn determined that the building's windows through
which we were trying to mesh were shielded, and were
attenuating the RF signal. To verify, a NanoStation was
extended to the outside of the building, and the link
immediately improved. One way to diagnose this
consistently was discussed: look at your cell phone's
reception as you go from outside the building to inside;
if reception drops significantly, even next to a window,
the windows are likely shielded.</span></p>
</li>
<li dir="ltr">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>The
underlying problem was linked to the NS or PS node that
was meshing via Ethernet and Ad-Hoc wireless to bridge
from McGregor to the adjacent buildings. After meshing
on Ethernet was disabled, packet loss and latency
disappeared. Will Hawkins suggested the olsrd-dnssd
plugin was also causing problems - once that was
disabled on </span><span>all</span><span>
the nodes, meshing over Ethernet was re-enabled and
everything worked fine. It is still unclear what exactly
about the dnssd plugin caused the problems.</span></p>
</li>
</ol>
<li dir="ltr">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>Since
the McGregor nodes were connected to a LAN, the default
firewall rules blocked incoming connections to their web
interface from the LAN.</span></p>
</li>
<ol style="margin-top:0pt;margin-bottom:0pt">
<li dir="ltr">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>Firewall
exceptions to allow WAN connections to port 80 needed to
be manually added in order to access the nodes' web
interfaces from the WSU LAN. Since ssh connections from
the WAN zone are allowed by default, it is probably no
less secure to allow http connections from the WAN zone.
It is worth considering changing this in the default
firewall config.</span></p>
</li>
</ol>
<li dir="ltr">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>It
was not possible to disable the AP, but leave the wireless
ad-hoc interface in place. However, disabling the Ad-Hoc
interface while leaving the AP up does work.</span></p>
</li>
<ol style="margin-top:0pt;margin-bottom:0pt">
<li dir="ltr">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>This
is due to when the AP is disabled from the web
interface, it adds a 'disabled' flag to the AP in
/etc/config/wireless, then restarts the wifi interfaces.
This has the effect of taking down wlan0-1 (the Ad-Hoc
interface) and leaving wlan0 (the AP), the opposite of
the intended effect. It also has the effect of creating
an invalid olsrd config (via commotiond), and the wifi
interfaces are displayed incorrectly in the web
interface. Unresolved.</span></p>
</li>
</ol>
<li dir="ltr">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>One
of the nodes would spew tons of duplicate packets when
pinged.</span></p>
</li>
<ol style="margin-top:0pt;margin-bottom:0pt">
<li dir="ltr">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>This
may have been a hardware malfunction. It was replaced
with a newly flashed PS, and the problem disappeared.</span></p>
</li>
</ol>
<li dir="ltr">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>Some
people were confused by the splash page.</span></p>
</li>
<ol style="margin-top:0pt;margin-bottom:0pt">
<li dir="ltr">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>I
got some feedback from some of the more tech-savvy folks
at the AMC that the port 80-only captive portal was
potentially confusing, especially if a user has an
SSL-encrypted homepage in their browser.</span></p>
</li>
</ol>
</ol>
<br>
<span></span><br>
<span></span>
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>Recommendations
for future Development</span></p>
<br>
<span></span>
<ul style="margin-top:0pt;margin-bottom:0pt">
<li dir="ltr" style="vertical-align:baseline;list-style-type:disc;font-variant:normal;font-style:normal;font-size:13px;background-color:transparent;text-decoration:none;font-family:Verdana;font-weight:normal">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>Fix
the adhoc wifi channel hopping issue</span></p>
</li>
<li dir="ltr" style="vertical-align:baseline;list-style-type:disc;font-variant:normal;font-style:normal;font-size:13px;background-color:transparent;text-decoration:none;font-family:Verdana;font-weight:normal">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>Implement
dynamic gain control so nodes don't drown each other out</span></p>
</li>
<li dir="ltr" style="vertical-align:baseline;list-style-type:disc;font-variant:normal;font-style:normal;font-size:13px;background-color:transparent;text-decoration:none;font-family:Verdana;font-weight:normal">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>Increase
default DHCP timeout and add option to change it in the
web interface (these fixes have already been submitted)</span></p>
</li>
<li dir="ltr" style="vertical-align:baseline;list-style-type:disc;font-variant:normal;font-style:normal;font-size:13px;background-color:transparent;text-decoration:none;font-family:Verdana;font-weight:normal">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>Check
for shielded windows when doing a deployment</span></p>
</li>
<li dir="ltr" style="vertical-align:baseline;list-style-type:disc;font-variant:normal;font-style:normal;font-size:13px;background-color:transparent;text-decoration:none;font-family:Verdana;font-weight:normal">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>Refactor
the olsrd-dnssd plugin</span></p>
</li>
<li dir="ltr" style="vertical-align:baseline;list-style-type:disc;font-variant:normal;font-style:normal;font-size:13px;background-color:transparent;text-decoration:none;font-family:Verdana;font-weight:normal">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>Add
firewall rule to allow port 80 connections from the WAN
zone</span></p>
</li>
<li dir="ltr" style="vertical-align:baseline;list-style-type:disc;font-variant:normal;font-style:normal;font-size:13px;background-color:transparent;text-decoration:none;font-family:Verdana;font-weight:normal">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>Fix
the bug preventing disabling the AP and leaving adhoc.</span></p>
</li>
<li dir="ltr" style="vertical-align:baseline;list-style-type:disc;font-variant:normal;font-style:normal;font-size:13px;background-color:transparent;text-decoration:none;font-family:Verdana;font-weight:normal">
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span>Captive
portal port 443 traffic with a self-signed cert by
default.</span></p>
</li>
<li dir="ltr" style="vertical-align:baseline;list-style-type:disc;font-variant:normal;font-style:normal;font-size:13px;background-color:transparent;text-decoration:none;font-family:Verdana;font-weight:normal"><span>Setup
network monitoring before doing a deployment. It would have
been immensely useful to know how many folks used the
MagicNet, and if they used the local apps at all. It would
also have been useful to solicit feedback on the network and
what issues the users ran into.</span></li><span><font color="#888888">
</font></span></ul><span><font color="#888888">
</font></span></b><span><font color="#888888">
<pre cols="72">--
Dan Staples
Open Technology Institute
<a href="https://commotionwireless.net" target="_blank">https://commotionwireless.net</a></pre>
</font></span></div>
<br></div></div>_______________________________________________<br>
Commotion-dev mailing list<br>
<a href="mailto:Commotion-dev@lists.chambana.net" target="_blank">Commotion-dev@lists.chambana.net</a><br>
<a href="https://lists.chambana.net/mailman/listinfo/commotion-dev" target="_blank">https://lists.chambana.net/mailman/listinfo/commotion-dev</a><br>
<br></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><br>-- <br>Ben West<div><a href="http://gowasabi.net" target="_blank">http://gowasabi.net</a><br><a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a><br>
<a href="tel:314-246-9434" value="+13142469434" target="_blank">314-246-9434</a><br>
</div>
</font></span><br>_______________________________________________<br>
OTI-Field mailing list<br>
<a href="mailto:OTI-Field@lists.opentechinstitute.org">OTI-Field@lists.opentechinstitute.org</a><br>
<a href="https://lists.opentechinstitute.org/mailman/listinfo/oti-field" target="_blank">https://lists.opentechinstitute.org/mailman/listinfo/oti-field</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Preston Rhea<br>Program Associate, Open Technology Institute<br>New America Foundation<br>+1-202-570-9770<br>Twitter: @prestonrhea
</div>