1. Routing over Ethernet
   ---------------------
   This was a very cool feature that I got to work on. This feature allowed one
   to connect two Meraki routers using an ethernet cable and form a link
   between them automatically. What this means is that if two wireless routers
   are operating on two different channels, then by simply connecting them with
   an ethernet cable, it was possible to "bridge" these two networks on
   different channels with the abstraction of a very high quality link. This
   has several applications, easy extension of networks, experimenting with
   multi-channel mesh networks. The beauty of the whole idea was now this link
   acted like any other wireless link and nothing had to be changed in the
   routing code!	

2. Routing code bug fixes
   ----------------------
   As an artefact of spending so much time on writing a new
   routing-over-ethernet module in Roofnet (Meraki) implementation in Click, I
   stumbled across several critical bugs in the routing code. The highlights
   were two bugs in particular, one of which was a security vulnerability which
   could cause a person to launch a denial of service attack on all the Meraki
   routers in it's vicinity bringing down an entire mesh network. The other bug
   was in the Dijkstra routing code which allowed routes to persist in the
   routing table indefinitely once discovered, a condition which could possibly
   lead to route flapping. 

3. Outdoor mesh network design and planning (San Francisco network)
   ----------------------------------------
   Developed a GPS integrated Meraki wifi scanner (using OpenWRT port on Meraki
   routers), which was used to do site survey (war-driving) of a large site and
   making it easy and portable enough for even a non-technical (read sales guy)
   to gather important site information. The setup (contraption!) comprised of
   a GPS attached to a MEraki router with an external antenna and a battery
   pack, running Kismet and collecting stats. 

   I tested out a bunch of antenna and hardware boards (ex. routerboards and
   others) for their performance. This involved a numberof fun field trips to
   San Francisco and also certain  desolate parts (waste lands) in the
   bay-area. 

4. Peer to peer traffic support (in the absence of a gateway)
   -----------------------------
   Due to the inherent network design (gateway oriented and dijkstra based
   routing), the Meraki networks did not allow for nodes to communicate with
   each other on an ad-hoc basis. I did some work trying to enable this support
   and fixed a number of routing related bugs which could bring down the
   network within a matter of seconds if this feature was enabled at any point
   of time.  (Routing loops)

5. Outdoor Solar product
   ---------------------
   I familiarized myself with the Solar product (in production still) design
   and architecture. I briefly worked on coming up with its firmware.