|
|
| Line 14: |
Line 14: |
| An additional goal is that users not actively participating in the mesh network (i.e., not running mesh routing software on their devices) can make use of the network without having to install anything new, jailbreak their phone, or pry the information out of a hacker infected with the Exsurgent virus. | | An additional goal is that users not actively participating in the mesh network (i.e., not running mesh routing software on their devices) can make use of the network without having to install anything new, jailbreak their phone, or pry the information out of a hacker infected with the Exsurgent virus. |
|
| |
|
| == Sprint 1 ==
| |
|
| |
|
| Goal - Reliably bridge two different and separate wireless networks without using existing internet infrastructure.
| | === Sprints === |
| | | [[Byzantium Sprint 1|Sprint 1 Details]] |
| Design goals
| | [[Byzantium Sprint 2|Sprint 2 Details]] |
| 1) There should be a webserver on each network providing a service of some kind (microblogs, web chat, file dump).
| | [[Byzantium Sprint 3|Sprint 3 Details]] |
| 2) Nodes in either network should be able to reach both webservers.
| |
| 3) Nodes on one network should be able to talk to nodes on the other network and vice versa.
| |
| 4) Networks should have at least 3-5 nodes each.
| |
| | |
| Tentative schedule is as follows:
| |
| | |
| Friday - 8:00pm Pizza and planning (any particular request should email me off list). (COMPLETE!)
| |
| Saturday - 9:00am Start showing up (IN PROGRESS!)
| |
| Saturday - 10:00am Divide into groups and start the sprint.
| |
| Sunday - 10:00am Start showing up.
| |
| Sunday - 11:00am Finish the sprint!
| |
| Sunday - Evening Debriefing (I'll be taking extensive notes to update the wiki).
| |
| | |
| Notes:
| |
| *[[BATMAN]]
| |
| *[[BATMAN-Advanced Setup]]
| |
| *[[Babel]]
| |
| *[[Babel Setup]]
| |
| | |
| Plans!
| |
| We're gonna have two teams each will implement a mesh network using some existing mesh protocol. One team will be working with BATMAN-Advanced and the other with BABEL. Each network will use at least one openwrt device the rest will be laptops and netbooks.
| |
| | |
| from Wikipedia: [http://en.wikipedia.org/wiki/Byzantine_fault_tolerance#Origin Byzantine]
| |
| [http://p2pfoundation.net/Mesh_Networks From p2pfoundation.net]
| |
| [http://drwho.virtadpt.net/archive/2011/03/15/project-byzantium-sprint-1 The Doctor's writeup.]
| |
| | |
| Interesting threads:
| |
| [http://lists.alioth.debian.org/pipermail/babel-users/2008-August/000151.html A few comments on the BATMAN routing protocol]
| |
| [http://lists.alioth.debian.org/pipermail/babel-users/2008-August/000156.html A few more comments on the BATMAN routing protocol]
| |
| | |
| === Distributed DNS === | |
| [http://en.wikipedia.org/wiki/Distributed_hash_table Distributed Hash Table (DHT)] - Wikipeda page on DHTs. Has a decent overview of how they work. | |
| | |
| [http://www.bamboo-dht.org/ Bamboo DHT] - A DHT implementation in Java. | |
| | |
| [http://code.google.com/p/upright/ UpRight] - A library for building fault-tolerant distributed systems. Incorporates innovations from modern solutions to Byzantine fault tolerance.
| |
| | |
| [https://secure.wikimedia.org/wikipedia/en/wiki/Gossip_protocol Gossip Protocols]: Nodes in a network pseudorandomly select peers to exchange information with. Could be useful for distributing the contents of a DHT-based DNS implementation within a mesh network. | |
| [https://secure.wikimedia.org/wikipedia/en/wiki/Kademlia Kademlia] has an interesting way of handling the entry distribution problem. When inserting an entry, it iterates through the table to find suitable nodes in the network to hold that entry and propagates it to them as well as saving a copy locally. | |
| | |
| [http://conferences.sigcomm.org/sigcomm/2004/papers/p292-ramasubramanian1111.pdf CoDoNS paper] - A very good paper from 2004 on a distributed DNS alternative. It still relies on centralized domain name registration.
| |
| [http://www.cs.cornell.edu/people/egs/beehive/codons.php CoDoNS main page] - It appears that CoDoNS is operational and running on PlanetLab.
| |
| Unfortunately, I don't see any code. I see no reason why we can't simply hijack their design.
| |
| | |
| [http://www.surfnet.nl/Documents/DNSSSEC-web.pdf Tutorial on DNS and DNSSEC]
| |
| | |
| [http://nms.lcs.mit.edu/projects/ins/ Intentional Naming System] - "INS is a new naming system intended for naming and discovering a variety of resources in future networks of devices and services. It has the following interesting characteristics about the way it names resources and the way names are resolved."
| |
| | |
| == Sprint 2 ==
| |
| Summary: Build at least one long-haul link to bridge two meshes.
| |
| | |
| Planning meeting: Thu Mar 3 2011 after the bike maintenance class (done)
| |
| Planning meeting #2: Wed Mar 16 2011 after the elements of computing class (doneish)
| |
| | |
| '''Sprint Date: Fri-Sun March 25-27'''
| |
| [[Byzantium Sprint 2 Inventory|Inventory]]
| |
| | |
| ===Schedule===
| |
| FRI: 8:00pm Pizza, sprint 1 recap, and prep (mostly ripping thing apart and some assembly)
| |
| SAT:
| |
| *Noon Brunch and final assembly followed by bench tests and midrange tests depending on speed of success
| |
| *Dinner Time: Dinner outside the space. This must occur outside the space.
| |
| *9:00pmish? Discussion and general planning for Sunday optionally followed by more testing/making
| |
| SUN:
| |
| *Noon Brunch prep for long distance tests followed by long distance tests
| |
| *Dinner Time: Dinner outside the space. This must occur outside the space.
| |
| *9:00pmish? Discussion and planning for the next sprint
| |
| | |
| ===Stuff to bring (proposed)===
| |
| *FMRS/GMRS radios that you wouldn't mind hacking.
| |
| *Childrens' walkie-talkies. [[User:Drwho]] knows where to buy cheap pairs of them locally.
| |
| *Webcams ''that are known to work with Linux''. That's closer to black magick than computer science, so do your homework first (or on your smartphone while at the store). The feature to look for is called [http://en.wikipedia.org/wiki/USB_video_device_class UVC] though webcam boxes still might not mention it.
| |
| *Laser pointers (the more exotic the colors the better). Buy them when you find them. When you go looking for them you can never find them.
| |
| *Really bright LEDs
| |
| *Photocells, photoresistors, photodetectors.
| |
| *Microcontrollers. They may come in handy for modulating/demodulating signals.
| |
| *Hackable wireless access points. Here are some [http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&DEPA=0&Order=BESTMATCH&Description=dd+wrt examples] that might work.
| |
| *old headphones/headsets/stereo audio cables and phone cords for cutting up and making into modem to radio connectors
| |
| | |
| ===Radio===
| |
| *radio shack/hardware store high bandwidth unlicensed spectrum
| |
| *Hacked FRS/GMRS radios
| |
| **[http://takethingsapart.blogspot.com/2010/07/note-before-constructing-device-such-as.html Text messages over walkie-talkies.]
| |
| **[http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1270645507 Forum post with some ideas.]
| |
| **Pros:
| |
| ***cheap
| |
| ***longish range (35mi allegedly)
| |
| **Cons:
| |
| ***Need an automated PTT switch or two radios per node
| |
| *Develop improvised antennae to improve signal quality, distance covered.
| |
| **anything + aluminium foil = bouncy bouncy for radio waves
| |
| The FCC has designated a number of channels in the 27 MHz band that can be used for signaling and radio control. They are unnumbered and in-between CB channels 1-13 ([http://forum.servomagazine.com/viewtopic.php?f=1&t=2736 source])
| |
| | |
| ===Optical===
| |
| *Modified Ronja-like
| |
| **with lasers
| |
| **with balloon targets
| |
| **with lasers and balloon targets
| |
| **with lasers and self-adhesive mirrored decals.
| |
| *All Electronics Magazine had a couple of articles on building lasercomm devices on the cheap. Somebody remind the Doctor to go through his magazine collection.
| |
| *[http://www.make-digital.com/make/vol16/?pg=69#pg69 How to make a simple laser communicator.] (I do have this issue. Have bought parts to build a pair of transceivers. --The Doctor)
| |
| *[http://www.imagineeringezine.com/files/air-bk2.html Handbook of Optical Through-the-Air Communications] is a good read on the basics of an LED-based hardware setup, though he's aiming at voice comms. (Elliot)
| |
| | |
| ===Inspiration===
| |
| *[[Ronja]]
| |
| | |
| ===Homework===
| |
| *read up on [http://ronja.twibright.com/ Ronja]
| |
| *read up on FMRS/GMRS
| |
| *read up on and talk to the HacDC Spaceblimp team about soundcard modems: like [http://www.baycom.org/~tom/ham/soundmodem/ this] (also available via apt [[Notes on Soundmodem|like so]])
| |
| **[http://www.linux-ax25.org/wiki/Soundmodem Howto](go here last it's a bit short on soundmodem specific info)
| |
| **[[Notes on Soundmodem]]
| |
| **[http://www.qbjnet.com/packet.html#soundmodem Soundmodem in the field.]
| |
| *Read up on [[AX.25]].
| |
| | |
| ===Goals (proposed)===
| |
| *Optimize for hackability. Could your average geek build a few of these using junk around zir house and deploy them in an emergency situation?
| |
| *Determine the optimum speed in bits per second for a mesh-to-mesh link.
| |
| *Measure the bandwidth of a point-to-point long haul connection at a particular distance.
| |
| *Determine the maximum practical distance for a long haul connection between two meshes in an urban environment.
| |
| *Mathematically describe the way to maximize throughput with a minimum number of nodes.
| |
| *Run an ssh session over whatever link is established.
| |
| *Interact with a web page over whatever link is established.
| |
| *Develop methods to minimize latency.
| |
| *Determine the efficiency of the mesh routing protocol we settle on.
| |
| **How many active nodes per mesh can be reasonably supported before connectivity breaks down?
| |
| | |
| ===Apps running on Windbringer (laptop/node) to prove functionality===
| |
| *[http://status.net/open-source status.net v0.9.6]
| |
| *[http://www.mediawiki.org/wiki/MediaWiki Mediawiki]
| |
| | |
| ===Lessons Learned===
| |
| *"how hard can it be" ... oops :(
| |
| | |
| ==Sprint 3==
| |
| possible projects:
| |
| *revisit sprint 1
| |
| **Gather metrics on traffic to determine efficiency of protocol.
| |
| ***Number of packets per second per node with no other activity.
| |
| ***Average size of packets.
| |
| ***Average amount of traffic during normal operation.
| |
| *revisit sprint 2 (possibly with different methods)
| |
| *new project
| |
| **long haul point-to-point links between meshes
| |
This project was launched with a sprint on Feb 25-27, 2011.
Another sprint will be held Mar 25-27, 2011.
Project Goals
The goal of Project Byzantium is to develop a communication system by which users can connect to each other and share information in the absence of convenient access to the Internet.
The use cases for such a system would be:
- The infrastructure for accessing the internet has become damaged or inaccessible. (Eg, a natural disaster such as Hurricane Katrina.)
- A central authority has decided to explicitly block or shutdown key infrastructure. (Eg, Egypt's recent internet blackout.)
- A zombie apocalypse in which the personnel responsible for maintaining key infrastructure have all been turned.
The project aims to develop and publish the necessary documentation, best practices, and software to construct and support such a system. Our current approach is to start by investigating and documenting the existing technologies which would support such a system. In particular, mesh networking protocols, wireless networking technologies, and decentralized (or less-centralized) alternatives to internet addressing/naming systems such as DNS. In designing the system, we aim to reduce the dependency on exotic hardware or skill sets so that the system can be deployed quickly and easily by average internet users.
An additional goal is that users not actively participating in the mesh network (i.e., not running mesh routing software on their devices) can make use of the network without having to install anything new, jailbreak their phone, or pry the information out of a hacker infected with the Exsurgent virus.
Sprints
Sprint 1 Details
Sprint 2 Details
Sprint 3 Details
