Revert "doc: remove doc/ in preparation for git subtree-add"

This reverts commit 55c7f45824d9d78740ec15e1e30db51acf7e1f8e.

doc/Seccomp.md

@@ -0,0 +1,37 @@
+# Seccomp
+
+SECCOMP (secure computing) is a way for programs to declare to the Linux kernel
+that they will never make certain system calls, thus any attempt to make one of
+these calls is interpreted as a security penetration and the kernel can forcibly
+kill off the program, preventing harm to the computer.
+
+## Seccomp failures in cjdns
+
+If you are reading this because cjdns is halting on you, you are probably getting
+a log message like the following:
+
+        Attempted banned syscall number [232] see docs/Seccomp.md for more information
+
+This number (`232` in the example) is specific to your system and you need to
+run a command to convert it to a syscall name.
+
+        echo '#include <sys/syscall.h>' | cpp -dM | grep '#define __NR_.* 232'
+
+Obviously you'll be replacing `232` with the actual syscall number which your system
+printed. The Result might look something like the following:
+
+        #define __NR_epoll_wait 232
+
+Which would tell you (for example) that the `epoll_wait` syscall was disallowed on
+your system. In this case you'd need to go to `util/Seccomp.c` and inside of the
+`mkfilter()` function where the actual SECCOMP rules are set up, you'll see a set
+of entries such as the following.
+
+        #ifdef __NR_mmap2
+            IFEQ(__NR_mmap2, success),
+        #endif
+
+Add a similar entry for the syscall (make sure you put it with the others and not)
+below the `RET(SECCOMP_RET_TRAP),` line which triggers the failure). When you have
+finished adding your system call rebuild and re-test cjdns. If it works well then
+please make a Pull Request :-)   If not then open a bug report and explain the problem.

doc/SmartOS.md

@@ -0,0 +1,12 @@
+# Installing cjdns on SmartOS
+
+** currently broken - wip
+
+    pkgin in scmgit-1.8.3.1
+    pkgin in gcc47-4.7.3nb1
+    pkgin in cmake-2.8.11
+    pkgin in gmake-3.82nb7
+    git clone git://github.com/cjdelisle/cjdns.git
+    cd cjdns/
+    ./do
+

doc/TrafficAnalisys.md

@@ -0,0 +1,42 @@
+# Some tricks for debugging cjdns issues using traffic analysis
+
+Traffic analysis on cjdns is stupidly hard because everything is encrypted point to point.
+Basically the only thing you have to go on is the size of packets, recently we fixed a bug
+in the switch pinger which was causing packets to be dropped randomly (most of the time).
+
+In order to detect where the packets were dropping, we used ping with a special size and
+tcpdumped for the related packet.
+
+Switch pings sent over UDP will normally appear as 60 bytes. By adding a few bytes of payload
+data to the ping, one can cause packets to appear at the UDP level which are of a very unlikely
+size.
+
+## Step 1: startup tcpdump
+
+        $ sudo tcpdump -n -i eth0 'udp and port 11223' | grep ' 6[0-9]$'
+
+## Step 2: begin sending pings
+
+        $ ./contrib/nodejs/tools/ping -s 0000.0000.0000.0aa3
+
+Observe suddenly 60 byte packets appear:
+
+        18:40:56.292748 IP 123.45.67.8.12345 > 87.65.43.210.11223: UDP, length 60
+        18:40:56.292748 IP 123.45.67.8.12345 > 87.65.43.210.11223: UDP, length 60
+
+## Step 3: vary the size
+
+In order to find a packet size which will filter out noise, add some bytes of data to the ping.
+
+        $ ./contrib/nodejs/tools/ping -d 'x' -s 0000.0000.0000.0aa3
+
+This will create a ping with a single byte payload which will lead to 61 byte packets, a very
+rare packet size in general.
+
+        18:40:56.293030 IP 123.45.67.8.12345 > 87.65.43.210.11223: UDP, length 61
+        18:40:57.289980 IP 123.45.67.8.12345 > 87.65.43.210.11223: UDP, length 61
+        18:40:57.290356 IP 123.45.67.8.12345 > 87.65.43.210.11223: UDP, length 61
+
+Once you find a "quiet" packet size to grep for, you can begin testing to see where the packet
+drops.
+

doc/Whitepaper.md

@@ -0,0 +1,942 @@
+# What?
+
+Imagine an Internet where every packet is cryptographically
+protected from source to destination against espionage and forgery, getting
+an IP address is as simple as generating a cryptographic key, core routers
+move data without a single memory look up, and denial of service is a term
+read about in history books. Finally, becoming an ISP is no longer confined
+to the mighty telecoms, anyone can do it by running some wires or turning on
+a wireless device.
+
+This is the vision of cjdns. 
+
+# Why?
+
+The Internet is built on protocols which largely date back to the late 80's
+or earlier. At a time when it was a network of anarchistic academics and
+scholars showing the ITU that open standards matter, it was absolutely enough.
+Over time the network has gotten bigger and the users have found new needs.
+
+In the age when packet inspection is universal and security breaches are
+commonplace, cryptographic integrity and confidentiality are becoming more of
+a requirement. The US government recognized this requirement and has been
+helping through [IPSEC] and [DNSSEC] efforts.
+
+Another issue is how are we going to route packets in a world where the global
+routing table is simply too large for any one router to hold it all? Despite
+the heroic efforts of core network engineers, the growth of the global routing
+table seems an unstoppable march. Cisco router company has proposed a plan
+called Locater/Identifier Separation Protocol, or [LISP] which aims to solve
+this by re-aggregating the routing table without forcing people to change their
+precious IP addresses. A different view of this problem is IP address
+allocation, currently it is done by a central organization which assigns IP
+addresses in such a way as to make the routing table as small as possible.
+Unfortunately this creates a bar of entry to the ISP sphere because aspiring
+network operators must register with the central organization and apply for an
+allocation of IP addresses while demonstrating that they will not be wasted.
+It is always easier to show that you need IP addresses if you already have a
+network.
+
+Denial of service, an attempt to prevent legitimate users from accessing a
+service[1], is likewise a new problem in the expanding network. To my knowledge,
+there is no general purpose solution to denial of service attacks. Solutions to
+packet flood based denial of service often revolve around hosting a service on
+many computers so that they can handle an enormous amount of traffic.
+
+Finally, the existing protocols are difficult to use, we cannot reasonably
+assign blame to anyone for this, many of these protocols are over thirty years
+old and demonstrate a level of craftsmanship which I can only hope to one day
+achieve. However, thirty years takes its toll on the best of us and as the
+Internet grew and became more complex, the administration interface of the
+typical router has grown a thicket of knobs, buttons and switches to match the
+proliferation of use cases and failure modes. As a result, network operation
+has become a science where students receive degrees and certificates for knowing
+the meanings of the plethora of knobs and switches, it has also become, like the
+tuning of the race car, an art, passed from master to apprentice and shared on
+mailing lists. Suffice to say, the bar of entry into the ISP realm is too high.
+Users, particularly in the ad-hoc wireless network arena, have observed the high
+bar of entry into traditional routing and have developed a menu of alternative,
+self-configuring protocols such as [OSLR], [HSLS], and [BATMAN].
+
+
+## So the problems are already solved?
+
+Not every problem listed has an existing solution and of the ones which do,
+many of the solutions are based on incompatible technology. For example: OSLR
+was not designed to operate with IPSEC and LISP. Even where the solutions exist
+and are ready for deployment, they still require mass technology adoption and
+they don't offer existing ISPs significant immediate gains.
+
+The mismatch is rather absurd. On the one hand there are scholars, engineers,
+hardware and software designers with combined over 1000 years of experience.
+There are mathematical formulae, proofs, papers and specification documents;
+written, circulated, peer reviewed and written again. On the other hand you
+have a single volunteer developer, a clean slate, and an attitude that
+nothing is impossible. How can this be anything short of lunacy?
+
+*In revolutionary times, the old book only weighs you down.*
+
+cjdns is built on the idea that the ISPs and hosting providers which exist
+now will never upgrade, not to LISP, not to DNSSEC, not even to IPv6 in any
+meaningful way. Building new systems to be compatible with old systems is
+catering to the audience you will never have. Asking existing ISPs to upgrade
+for the common good is asking them to take a risk with no immediate benefit.
+cjdns is about throwing out the book and redefining the specifications in a
+way that will be fast, secure, and most importantly, *easy* for the next
+generation of ISPs to deploy and use.
+
+
+## What is this denial of service?
+
+Usage of a service can be interrupted by sending a flood of unwanted packets
+to a host from a large number of infected "zombie" machines. This, known as
+[DDoS], is a problem which worsens every year as the upload speed of all
+infected nodes on the Internet grows in proportion to the download speed of any
+given link. Being infected with a virus and participating in DDoS, though not a
+picnic, is not an emergency for the owner of the infected machine. Nor is it an
+emergency for their ISP. DDoS is always "their problem"... Until it strikes in
+your network. Sadly, a common response from a datacenter is to stop carrying the
+controversial content, making DDoS an effective censorship tool and encouraging
+the practice.
+
+Another form of denial of service which is even more insidious is intimidation
+by threat of faux court action. This form of denial of service is especially
+effective since most people get their IP addresses from their ISP, when their
+ISP is threatened, they need to make a judgment call as to the validity of the
+claim and they often act as judge and jury, disconnecting a customer in order to
+avoid conflict. Those who have their own IP addresses assigned to them, are able
+to essentially be their own ISP and to peer with a multitude of other ISPs
+making it very difficult to threaten anyone but them.
+
+
+## What is the routing table and why does it keep getting bigger?
+
+A more technical issue with the Internet, and one of which many people are
+unaware, is address space deaggregation. Every computer connected to the
+Internet needs an address, a number which uniquely identifies it and which is
+attached to every piece of data which is to be sent to that computer. At every
+stop along its path through the Internet, a packet (unit of data) has its
+address field examined by a router so it can decide which wire that packet
+should be sent down. Routers have an easier time if addresses are in big blocks
+so that a router can look quickly at the first numbers in the address and know,
+for example, that it is destined for somewhere in China, not exact but enough to
+know which wire to send it though. People naturally want as many addresses as
+they can possibly get and they want them in the smallest blocks possible, this
+is so they can then control (or buy and sell) these small blocks independently.
+The smaller the blocks of addresses which are announced, the larger the routing
+tables become and the more work the Internet's core routers must do in order to
+send a packet in the right direction. There have been attempts to aggregate
+addresses back in to groups but nonetheless, the number of small announcements
+in the global routing table has grown every year.
+
+To address the growing routing tables, Cisco has proposed a new protocol called
+Locator/Identifier Separation Protocol or LISP. The idea of LISP is to
+separate the addresses which people use from the addresses which routers use,
+like a lower level version of DNS. LISP allows the edge ISPs and users to see
+the Internet as they want it, deaggregated into small pieces for political
+reasons, and the routers to see the Internet as they want it, centralized
+hierarchical pyramid of addresses emanating from some arbitrary center point.
+This design works well in existing routers since they are designed to get
+packets with a universally unique address and look that address up in a table.
+This is advertised as a design feature but LISP is limited in its vision, if
+one must look up the "real location" of a server before forwarding a packet,
+why not simply look up the fastest path?
+
+
+## I don't care, it's their problem.
+
+Each of these problems is a tragedy of the commons problem. The users of virus
+infected computers are incentivized to save money rather than purchasing a
+product or service to rid their computer of the infection. While there are
+solutions such as egress filtering which decrease the problem, ISPs are
+incentivized to implement as little security as possible because they are not
+directly affected. Denial of service, whether by packet flooding or by faux legal
+action, benefits the attacker who is able to hide the truth or victimize service
+providers as well as organizations who make it their business to provide DoS
+related services. The victim who all too often publishes information for no
+other reason than satisfaction of telling the truth, is the only party harmed
+by this type of attack, and he is the least able to prevent it. Address space
+deaggregation benefits the edge ISPs who gain more flexibility in how their
+network is organized at the cost of the core ISPs whose only defense is the
+"we will not route that" nuclear option which would no doubt bring about a
+revolt from the edge ISPs.
+
+Each of these problems hurts everyone, DDoS forces ISPs to over prevision their
+lines, denial of service through faux legal action increases the cost of running
+a community website or ISP since each accusation must be reviewed and its
+validity assessed, and address deaggregation means everyone must pay more to
+have their packets routed through increasingly high power routers, and
+difficulty of operating a router and getting a block of IP addresses hurts
+competition in the ISP sphere, thus increasing prices and impeding progress.
+
+
+# How?
+
+cjdns is made of three major components which are woven together.
+There is a switch, a router, and a CryptoAuth module. With total disregard for
+the OSI layers, each module is inherently dependent on both of the others. The
+router cannot function without routing in a small world which is made possible
+by the switch, the switch is blind and dumb without the router to command it,
+and without the router and switch, the CryptoAuth has nothing to protect.
+
+
+## The Switch
+
+*He doesn't think about his actions; they flow from the core of his being.*
+
+The switch design is unlike an IP or Ethernet router in that it need not have
+knowledge of the globally unique endpoints in the network. Like ATM switching,
+the packet header is altered at every hop and the reverse path can be derived
+at the end point or at any point along the path but unlike ATM, the switch
+does not need to store active connections and there is no connection setup.
+
+
+### Definitions
+
+* Interface: A point-to-point link to another cjdns switch. This may be
+emulated by Ethernet frames, UDP packets or other means.
+
+* Self Interface: A special Interface in each switch, packets sent for this
+interface are intended for the node which this switch is a part of. Upon
+reaching the ultimate hop in its path, a packet is sent through the Self
+Interface so it can be handled by the next layer in the node.
+
+* Director: A binary codeword of arbitrary size which when received by the
+switch will direct it to send the packet down a given Interface.
+
+* Route Label: An ordered set of Directors that describe a path through the
+network.
+
+* Encoding Scheme: The method by which a switch converts one of its internal
+Interface ID (EG: array index) to a Director and converts a Director back to
+its internal representation. Encoding schemes may be either fixed width or
+variable width but in the case of variable width, the width must be
+self-describing as the Directors are concatenated in the Route Label without any
+kind of boundary markers.
+
+* Encoding Form: A single representation form for encoding of a Director. For
+a given Encoding Form, there is only one possible way to represent a Director
+for a given Interface. A variable width Encoding Scheme will have multiple
+Encoding Forms while a fixed width Encoding Scheme will have only one.
+
+* Director Prefix: For switches which implement variable width encoding, the
+least significant bits of the Director is called the Director Prefix and is
+used to determine the width of the Director. **NOTE** Because the Route Label
+is read from least significant bit to most significant bit, the Director
+Prefix is actually the bits furthest to the *right* of the Director.
+
+
+### Operation
+
+When a packet comes in to the switch, the switch uses its Encoding Scheme to
+read the least significant bits of the Route Label in order to determine the
+Director and thus the Interface to send the packet down. The Route Label is
+shifted to the right by the number of bits in the Director, effectively
+*removing* the Director and exposing the Director belonging to the next switch
+in the path. Before sending the packet, the switch uses its Encoding Scheme to
+craft a Director representing the Interface which the packet came *from*, does
+a bitwise reversal of this Director and places it in the empty space at the left
+of the Route Label which was exposed by the previous bit shift. In this way, the
+switches build a mirror image of the return Label allowing the endpoint, or any
+hop along the path, to derive the return path by simple bitwise reversal without
+any knowledge of the Encoding Schemes used by other nodes.
+
+
+#### Example
+
+Supposing Alice wanted to send a packet to Fred via Bob, Charlie, Dave and
+Elinor, she would send a message to her switch with the first Director
+instructing her switch to send down its interface to Bob, the second Director
+instructing Bob's switch to send to Charlie and so on.
+
+NOTE: Spaces between bits are for illustration only, Route Labels have no
+boundary markers between Directors and switches cannot know how many bits a
+Director uses unless that Director is their own.
+
+Alice's original Route Label, before entering her switch:
+
+    0000000000000000000000000 0001 101011 011010 100101101 10111 0100011
+    ^^^-- unused space --^^^^                                    ^^^^^^^-- Alice's Director Interface(Alice->Bob).
+
+Route Label when it reaches Bob:
+
+    1000000 0000000000000000000000000 0001 101011 011010 100101101 10111
+    ^^^^^^^                                                        ^^^^^-- Bob's Director for Interface(Bob->Charlie).
+          ^-- Alice's Director for her Self Interface (reversed)
+
+Route Label when it reaches Charlie:
+
+    11001 1000000 0000000000000000000000000 0001 101011 011010 100101101
+    ^^^^^ ^^^^^^^                                              ^^^^^^^^^-- Charlie's Director for Interface(Charlie->Dave).
+      ^^^       ^-- Alice's Director for her Self Interface (reversed)
+        ^-- Bob's Director for Interface(Bob->Alice), bit-reversed.
+
+
+Route Label when it reaches Dave:
+
+    110110011 11001 1000000 0000000000000000000000000 0001 101011 011010
+    ^^^^^^^^^ ^^^^^ ^^^^^^^                                       ^^^^^^-- Dave's Director for Interface(Dave->Elinor).
+       ^^^^^^   ^^^       ^-- Alice's Director for her Self Interface (reversed)
+          ^^^     ^-- Bob's Director for Interface(Bob->Alice) (reversed).
+            ^-- Charlie Director for Interface(Charlie->Bob) (reversed).
+
+Supposing Dave cannot forward the packet and needs to send an error, he does
+not know where Charlie's Director ends and Bob's begins so he can't
+re-order them but because they are bit reversed, he can reverse the order by
+bit reversing the entire Route Label.
+
+Route Label after bit reversal:
+
+    010110 110101 1000 0000000000000000000000000 0000001 10011 110011011
+                                                 ^^^^^^^ ^^^^^ ^^^^^^^^^-- Charlie's Director for Interface(Charlie->Bob).
+                                                    ^^^^ ^-- Bob's Director for Interface(Bob->Alice).
+                                                       ^ Alice's Director for her Self Interface.
+
+Dave can then send the packet back to Charlie who need not know what it is in
+order to forward it correctly on to Bob and then to Alice. If the packet had
+reached Fred, he would be able to use the same technique of reversing the Route
+Label in order to determine its origin.
+
+
+
+### Route Label Manipulations
+
+Despite a Route Label's relative opacity, there are still certain functions which
+can be carried out on Labels.
+
+#### Splice
+
+The Splice operation takes a Route Label from pointA to pointB and concatenates
+it with a Label from pointB to pointC yielding a Route Label for a route from
+pointA to pointC.
+
+Splicing is done by XORing the second part with `1` and shifting it left by the
+log base 2 of the first part, then XORing the result with the first part. 
+
+Given:
+
+```
+routeAB =        0000000000000000000000000000000000000000000001011101110101011001
+
+routeBC =        0000000000000000000000000000000000000000000000000000110101010100
+XOR 1            0000000000000000000000000000000000000000000000000000000000000001
+equals           0000000000000000000000000000000000000000000000000000110101010101
+
+shift left by the log base 2 of routeAB
+                 0000000000000000000000000000000000110101010101000000000000000000
+XOR  routeAB     0000000000000000000000000000000000000000000001011101110101011001
+equals routeAC   0000000000000000000000000000000000110101010100011101110101011001
+                                                              ^-- Note the overlap bit
+```
+
+The log base 2 represents the index of the first set bit, starting from the
+right. This means that shifting by the log base 2 leaves 1 bit of overlap, this
+along with the XORing of the second part (`routeBC`) against `1` causes the
+highest bit in the first part to be overwritten.
+
+
+#### Unsplice
+
+The inverse of the splice operation converts a full Route Label to a
+representation which would be useful to a node along the path. That is to say
+from routeAC and routeAB it derives routeBC.
+
+```
+routeAC =        0000000000000000000000000000000000110101010100011101110101011001
+routeAB =        0000000000000000000000000000000000000000000001011101110101011001
+
+routeBC = routeAC shifted left by the log base 2 of routeAB
+
+routeBC          0000000000000000000000000000000000000000000000000000110101010100
+```
+
+
+#### RoutesThrough
+
+Given two routes, it is possible to determine whether one route is an extension
+of another one, this is similar to the reverse of the the splicing routine. To
+determine whether routeAC "routes through" the node at the end of by routeAB,
+one simply removes the most significant 1 in routeAB, trims down the left side
+of routeAC so that both routes are the same length, and compares the results.
+
+```
+routeAC =        0000000000000000000000000000000000110101010100011101110101011001
+
+routeAB =        0000000000000000000000000000000000000000000001011101110101011001
+
+Trimmed to the same length:
+
+routeAC'         0000000000000000000000000000000000000000000000011101110101011001
+routeAB'         0000000000000000000000000000000000000000000000011101110101011001
+```
+
+Equality indicates routeAC routes through the node at the end of routeAB.
+
+
+### Encoding Schemes
+
+Because the conditions under which the switches operate may differ dramatically,
+the actual Encoding Scheme is left as an implementation detail. Some switches
+may be devices with 15 physical ports wherein a 4 bit fixed width Encoding
+Scheme would be wise, other switches may be in wireless networks where the
+number of reachable cjdns nodes, and thus the number of Interfaces may grow and
+shrink. These devices may prefer a variable width encoding in order to save
+Label space without sacrificing expandability. There are however a few
+limitations placed upon encoding methods in order to allow the above
+manipulations.
+
+
+#### Self Interface Director
+
+In order for Route Labels to be able to be spliced together, the most
+significant bit in a Label must always be `1` so that we know where it ends.
+Since every route ends with a Self Interface, the Director which represents the
+Self Interface must always be encoded as `1` with 3 or more leading zeros.
+Furthermore, a node must never send a packet with a Route Label for which the
+highest 3 bits are not zero. This is important so that the reverse route data
+applied by routers along the path is not mistaken for additional forward route.
+
+Finally, a switch should alias any Director ending with `0001` to the Self
+Interface Director. For example: a switch using a 6 bit fixed width Encoding
+Scheme would have to alias `010001`, `100001` and `110001` to the Self Interface
+Director `000001`. The reason for this is because an unsuspecting router might
+splice a valid path which uses every bit of the label space such that the most
+significant three bits of the entire Route Label are `0001`. In this case the
+bits added by the first switch will be right up against the Self Interface
+Director and could be mistaken for another forward Director.
+
+
+#### Variable Width Encoding
+
+If a switch implementation uses variable width encoding, it's obvious that some
+Interfaces will get short Directors while other Interfaces will be stuck with
+the longer Directors. Less obvious is what happens when a packet coming from a
+"small" Interface is sent to a "big" Interface. The switch shifts off the big
+Director leaving a big empty space on the left. To put only a small Director
+in that space would not work because there would be unaccounted for space in the
+reverse route which would cause a failure at the next switch in the path.
+
+In order to make it work, small Interfaces need to be able to be represented
+using big Directors. For any size, all smaller sizes need to be able to be
+represented.
+
+In the other direction, a packet coming from a big Interface with only a small
+next Director must be dropped (and an error sent back) because the return route
+simply cannot be represented. To prevent this problem, when a node on the far
+end of a big Interface inquires about a node behind a small Interface, the first
+Director in the Route Label must be converted by the router to the big form
+before the packet is sent.
+
+A still more subtle problem with variable width encoding is that a Label for the
+route between nodeA to nodeB may be different depending on how one reached
+nodeA. Since this would be a severe hindrance to efficient routing algorithms
+using path inference, a node is required to *describe* (through inter-router
+communication) how it encodes numbers.
+
+
+#### Encoding Scheme Definition
+
+In order to give routers the ability to chain paths from a graph of linked nodes
+while still preserving Variable Width Encoding, a node is required to describe
+its Encoding Scheme to other nodes and adhere to a few rules to make possible
+the conversion of a Director to a wider bit width by other nodes.
+
+The Encoding Scheme Definition consists of a array of representations of the
+Encoding Forms allowed in that Encoding Scheme, each Encoding Form
+representation having the following three fields:
+
+* **prefixLen**: The number of bits in the Director Prefix. This is represented
+on the wire as a 5 bit integer.
+
+* **bitCount**: The number of bits in the Director, not including the Director
+Prefix. This is represented on the wire as a 5 bit integer.
+
+* **prefix**: The Director Prefix used in this Encoding Form, this is
+represented on the wire using as many bits as are given in **prefixLen**. This
+value must be the same as the prefix which will be seen in the Director in the
+label but since it is opaque, no specific byte order is defined.
+
+The Encoding Scheme Definition is represented on the wire as a concatenation
+of Encoding Forms. Each form is represented in *reverse* the order given above
+with **prefix** furthest to the left, followed by **bitCount** then
+**prefixLen** furthest to the right. It is sent over the wire in *little endian*
+byte order allowing the buffer to be read and written forward while the data is
+unpacked from least significant bit to most significant bit.
+
+
+#### Conversion between Encoding Forms
+
+Just telling other nodes how numbers are encoded is not enough to allow
+inference of paths. As routers chain together the Route Labels for paths
+between different nodes, they need to *alter* the Encoding Form for Directors in
+the Route Labels to avoid crafting a Route Label for which the reverse path is
+not expressible.
+
+The two types of alteration which need to be allowed are *extension* and
+*truncation*. Given a route between nodeX and nodeY, a node must be able to
+*extend* the first Director in that route by changing it from one of the forms
+advertised by nodeX to another. This involves changing the Director Prefix and
+then extending the non-prefix section of the first Director by adding zero bits
+to the left side. *Truncation* is much the opposite, one would convert the
+Director from a wider form to a narrower by changing the Director Prefix and
+truncating zero bits from the left side.
+
+In order to remain compatible with these optimizations, a switch must disregard
+a change in the number of most significant zero bits in its Director, in the
+case of multi-byte Directors this may influence byte order decisions. Obviously
+a switch implementor must design their Encoding Scheme so that a Director is
+unambiguous and cannot be confused with the least significant bits of the data
+but since this is a requirement for a successful switch implementation, it goes
+without saying.
+
+
+
+### In Memory Representation
+
+While the switch protocol is inherently linked to the underlying carrier, there
+are certain expectations made by the protocols above the switch layer about how
+a switch header will appear in memory.
+
+
+                        1               2               3
+        0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     0 |                                                               |
+       -                          Route Label                          -
+     4 |                                                               |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     8 |      Type     |                  Priority                     |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+The `Route Label` field unsurprisingly holds the 8 byte `Route Label`, the
+`Type` field indicates the type of packet. Reserved packet types are `0` for
+opaque data, and `1` for switch control messages (eg errors). The `Priority`
+field is reserved for Quality of Service purposes, in the current implementation
+it is always zero.
+
+
+## The Router
+
+A router has 3 functions, it periodically searches for things, responds to
+searches, and forwards packets. When a router responds to a search, it responds
+with nodes which it thinks will get closer to the destination. The responses
+MUST NOT have addresses which are, in address space distance, further from the
+responding node than the search target, and they MUST NOT have routes which
+begin with the same interface as the route to the querying node. These two
+simple rules provide that no search will ever go in circles and no route will
+ever go down an interface, only to be bounced back. While the second rule can
+only be enforced by the honor system, querying nodes MUST double check the first
+rule. The node doing the searching adds the newly discovered nodes to their
+routing table and to the search, then continues the search by asking them.
+
+Upon receiving a search response containing one's own address, a node SHOULD
+purge all entries from its table whose routes begin with that route. This will
+control the proliferation of redundant routes.
+
+The "address space distance" between any two given addresses is defined as the
+of the result of the two addresses XOR'd against one another, rotated 64 bits,
+then interpreted as a big endian integer. The so called "XOR metric" was
+pioneered in the work on [Kademlia] DHT system and is used to forward a packet
+to someone who probably knows the whole route to the destination. The 64 bit
+rotation of the result is used to improve performance where the first bits of
+the address is fixed to avoid collisions in the IPv6 space.
+
+Adding nodes to the routing table from search responses is done by splicing the
+route to the node which was asked with the route to the node in the response,
+yielding a route to the final destination through them.
+
+Router messages are sent as normal UDP/IPv6 packets except that their UDP source
+and destination port numbers are zero and the hop limit (TTL) field in the IPv6
+header is set to zero. Any packet which meets these characteristics is to be
+considered a router message and any packet which doesn't is not. It is critical
+that inter-router communications are themselves, not routed because it would
+break the label splicing for search responses.
+
+The content of the inter-router messages is [bEncoded][bEncode] dictionaries.
+Routers send search queries which have a key called "q", and replies which
+don't. Routers SHOULD reply to a message with a "q" entry but MUST NOT reply if
+there is none, lest they reply to a reply. All messages have a transaction id
+number, a sort of cookie made of a bencoded string containing arbitrary bytes
+which must be reflected back in the reply. The most common query is a find node
+or "fn" query. "fn" queries have a field called "tar" for the target address
+which the node is looking for. Responses to "fn" queries have a field called "n"
+which is a binary string containing the 32 byte public keys and 8 byte switch
+labels for the responses.
+
+Example fn query in JSON:
+
+    {
+        "q":    "fn",
+        "tar":  "abcdefghhijklmno",
+        "txid": "12345"
+    }
+
+Same query bEncoded as the routers use:
+
+    d1:q2:fn3:tar16:abcdefghhijklmno4:txid5:12345e
+
+Example fn reply in JSON:
+NOTE: this reply only shows 2 nodes returned and is for illustration purposes
+in most cases the number would be an implementation specific constant around 8.
+
+    {
+        "n": "cdefghijklmnopqrstuvwxyzabcdefghi1234567qponmlkjihgzyxwvutsrstuvwxyzabcde2345678"
+        "txid": "12345"
+    }
+
+Same reply bEncoded
+
+    d1:n80:cdefghijklmnopqrstuvwxyzabcdefghi1234567qponmlkjihgzyxwvutsrstuvwxyzabcde2345678e
+
+
+The nodes in an fn reply are ordered from worst to best so the best answer is
+the last entry in the reply.
+
+Routers choose the node to forward a packet to in a similar way to how they
+answer search queries. They select nodes from their routing table except in this
+case the selection contains only one node. The packet is sent through the
+CryptoAuth session corresponding to this node and the label for getting to it is
+applied to the packet before sending to the switch. The "search target" for
+forwarding a packet is the IPv6 destination address of the packet.
+
+
+## The CryptoAuth
+
+The CryptoAuth is a mechanism for wrapping interfaces, you supply it with an
+interface and optionally a key, and it gives you a new interface which allows
+you to send packets to someone who has that key. Like the rest of cjdns, it is
+designed to function with best effort data transit. The CryptoAuth handshake
+is based on piggybacking headers on top of regular data packets and while the
+traffic in handshake packets is encrypted and authenticated, it is not secure
+against replay attacks and has no forward secrecy if the private key is
+compromised. The CryptoAuth header adds takes 120 bytes of overhead to the
+packet, causing a fluctuating MTU.
+
+There are 5 types of CryptoAuth header:
+
+1. Connect To Me - Used to start a session without knowing the other node's key.
+2. Hello Packet  - The first message in beginning a session.
+3. Key Packet    - The second message in a session.
+4. Data Packet   - A normal traffic packet.
+5. Authenticated - A traffic packet with Poly1305 authentication.
+
+All CryptoAuth headers are 120 bytes long except for the Data Packet header
+which is 4 bytes and the Authenticated header which is 20 bytes. The first 4
+bytes of any CryptoAuth header is a big endian number which is used to determine
+its type, this is the so-called "Session State" number. If it is the inverse of
+zero, it is a Connect To Me header, if it is zero, it is a Hello Packet, if one
+or two, it is a Hello Packet or repeated Hello Packet, if it is three or four,
+it is a Key Packet or repeated Key Packet. If it is any number larger than four,
+it is either a Data Packet or an Authenticated packet, depending on whether
+authentication was requested during the handshake.
+
+Handshake packet structure:
+
+                          1               2               3
+          0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       0 |                         Session State                         |
+         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       4 |                                                               |
+         +                                                               +
+       8 |                         Auth Challenge                        |
+         +                                                               +
+      12 |                                                               |
+         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      16 |                                                               |
+         +                                                               +
+      20 |                                                               |
+         +                                                               +
+      24 |                                                               |
+         +                         Random Nonce                          +
+      28 |                                                               |
+         +                                                               +
+      32 |                                                               |
+         +                                                               +
+      36 |                                                               |
+         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      40 |                                                               |
+         +                                                               +
+      44 |                                                               |
+         +                                                               +
+      48 |                                                               |
+         +                                                               +
+      52 |                                                               |
+         +                     Permanent Public Key                      +
+      56 |                                                               |
+         +                                                               +
+      60 |                                                               |
+         +                                                               +
+      64 |                                                               |
+         +                                                               +
+      68 |                                                               |
+         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      72 |                                                               |
+         +                                                               +
+      76 |                                                               |
+         +                     Poly1305 Authenticator                    +
+      80 |                                                               |
+         +                                                               +
+      84 |                                                               |
+         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      88 |                                                               |
+         +                                                               +
+      92 |                                                               |
+         +                                                               +
+      96 |                                                               |
+         +                                                               +
+     100 |                                                               |
+         +          Encrypted/Authenticated Temporary Public Key         +
+     104 |                                                               |
+         +                                                               +
+     108 |                                                               |
+         +                                                               +
+     112 |                                                               |
+         +                                                               +
+     116 |                                                               |
+         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+         |                                                               |
+         +        Variable Length Encrypted/Authenticated Content        +
+         |                                                               |
+
+
+### 1) Connect To Me Packet
+
+If "Session State" is equal to the bitwise complement of zero, the sender is
+requesting that the recipient begin a connection with him, this is done in cases
+when the initiator of the connection does not know the key for the recipient.
+If the entire header is not present the recipient MUST drop the packet silently,
+the only field which is read in the packet is the "Permanent Public Key" field,
+all others SHOULD be ignored, specifically, content MUST not be passed on
+because it cannot be authenticated. The recipient of such a packet SHOULD send
+back a "hello" packet if there is no established connection. If there is already
+a connection over the interface, the recipient SHOULD NOT respond but MAY allow
+the connection to time out faster.
+
+
+### 2) Hello Packet
+
+If the "Session State" field is equal to the one or two, the packet is a Hello
+Packet or a repeated Hello Packet. If no connection is present, one MAY be
+established and the recipient MAY send a Key Packet in response but it is
+RECOMMENDED that he wait until he has data to send first. A node who has sent a
+Hello Packet, has gotten no response and now wishes to send more data MUST send
+that data as more (repeat) Hello Packets. The temporary public key and the
+content are encrypted and authenticated using the permanent public keys of the
+two nodes and "Random Nonce" in the header. The content and temporary key is
+encrypted and authenticated using crypto_box_curve25519poly1305xsalsa20()
+function.
+
+
+### 3) Key Packet
+
+If the "Session State" field is equal to two or three, the packet is a Key
+Packet. Key Packets are responses to Hello Packets and like Hello Packets, they
+contain a temporary public key encrypted and authenticated along with the data.
+Once a node receives a Key Packet it may begin sending data packets. A node who
+has received a Hello Packet, sent a Key Packet, gotten no further response, and
+now wishes to send more data MUST send that data as more (repeat) key packets.
+
+
+### 4) Data Packet
+
+The traditional data packet has only 4 bytes of header, these 4 bytes are the
+nonce which is used for the cipher, the packet is enciphered using
+crypto_stream_salsa20_xor() with the nonce, converted to little endian encoding,
+and copied to the first four bytes of the 8 byte nonce required by 
+crypto_stream_salsa20_xor() unless the node is the initiator of the connection
+(the sender of the hello packet), in which case it is copied over the second
+four bytes of the space, thus allowing for a single session to handle 2^32
+packets in either direction.
+
+
+### 5) Authenticated Packet
+
+The Authenticated Packet is sent if Poly1305 authentication was requested by
+either node during the handshake. Like the Data Packet, the first 4 bytes is
+used as the nonce, in this case it is a 24 byte nonce and
+crypto_box_curve25519poly1305xsalsa20() is used to encrypt and decrypt the data,
+but the methodology is exactly the same. If a packet is not authenticated, it
+MUST be silently dropped.
+
+
+#### ReplayProtector
+
+When packet authentication is enabled, the packet is checked for replay attacks
+(intentional or accidental) the replay protection method is to use a 32 bit
+offset and a 32 bit bitfield to create a sliding window. When a packet comes in,
+its nonce is compared to the offset, if it is less then the offset, it is
+discarded. If when subtracted from the offset, the result is less than or equal
+to 32, 1 is shifted left by the result, bitwise ANDed against the bitfield and
+compared to zero, if it is not zero then the packet is a duplicate and is
+discarded. If it is zero then it is OR'd against the bitfield to set the same
+bit is set and the packet is passed along. If the result of subtraction is
+greater than 32, 32 is subtracted from it, this result is added to the offset,
+the bitfield is shifted left by this amount, then the least significant bit in
+the bitfield is set. This is obviously only available when packets are
+authenticated but provides a secure protection against replay attacks and
+accidentally duplicated packets EG: from 802.11 noise.
+
+This solution is limited in that packets which are more then 32 "slots" out of
+order will be discarded. In some cases, this could be a benefit since in best
+effort networking, never is often better than late.
+
+
+### Authentication field:
+
+This field allows a node to connect using a password or other shared secret,
+the AuthType field specifies how the secret should be used to connect.
+
+                       1               2               3
+       0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    0 |   AuthType    |                                               |
+      +-+-+-+-+-+-+-+-+        AuthType Specific                      +
+    4 |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    8 |A|                      AuthType Specific                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+The "A" flag is used to indicate that the node is requesting the session use
+Poly1305 authentication for all of its packets. The "AuthType Specific" fields
+specific to the authentication type.
+
+
+#### AuthType Zero
+
+AuthType Zero is no authentication at all. If the AuthType is set to zero, all
+AuthType Specific fields are disregarded and SHOULD be set to random numbers.
+
+
+#### AuthType One
+
+AuthType One is a SHA-256 based authentication method.
+
+                       1               2               3
+       0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    0 |   Auth Type   |                                               |
+      +-+-+-+-+-+-+-+-+           Hash Code                           +
+    4 |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    8 |A|        Derivations          |           Additional          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+With AuthType One, the shared secret (password) is hashed once and the result is
+appended to the 32 byte output from scalar multiplication of the curve25519 keys
+these 64 bytes are hashed again with SHA-256 to make the symmetric key to be
+used for the session. It is also hashed a second time and the result copied over
+the first 8 bytes of the authentication header before the AuthType field is set.
+The effect being that the "Hash Code" field contains bytes 2 through 8 the hash
+of the hash of the password. This is used as a sort of username so that the
+other end knows which password to try using in the handshake.
+
+If Derivations is non-zero, an additional step is included, the two most
+significant bytes of the password hash are XORed against the two bytes of the
+network representation of Derivations and it is hashed using SHA-256 once
+again before being included in the generation of the symmetric key. This form is
+notably NOT used in the Hash Code field.
+
+This allows a node Alice, to give a secret to Charlie, which he can use to start
+a CryptoAuth session with Bob, without leaking Alice's shared secret. This
+allows nodes to generate, share and derive secrets through trusted connections,
+creating new trusted connections and use them to share more secrets, adding a
+measure of forward secrecy in the event of a cryptographic weakness found in
+the asymmetric cryptography.
+
+
+## Pulling It All Together
+
+The journey of a packet begins at the user interface device (TUN or similar).
+The user sends an IPv6 packet which comes in to the TUN device and enters the
+engine, it is checked to make sure its source and destination addresses are
+valid and then a router lookup is made on the destination address. cjdns
+addresses are the first 16 bytes of the SHA-512 of the SHA-512 of the public
+key. All addresses must begin with the byte `0xFC` otherwise they are invalid,
+generating a key is done by brute force key generation until the result of the
+double SHA-512 begins with `0xFC`.
+
+After the router lookup, the node compares the destination address to the
+address of the next router, if they are the same, the inner layer of
+encryption is skipped. Assuming they are different, the IPv6 header is copied
+to a safe place and a CryptoAuth session is selected for the destination
+address, or created if there is none, and the packet content is passed through
+it. The IPv6 header is re-applied on top of the CryptoAuth header for the
+content, the packet length field in the IPv6 header is notably *not* altered to
+reflect the headers which are now under it.
+
+The packet is now ready to send to the selected router. For sending the packet
+to the router, a CryptoAuth session is selected for the router's address and
+the packet, from IPv6 header down, is passed through it. A switch header is
+applied to the resulting encrypted structure and it is sent down to the switch
+for routing.
+
+The switch takes the packet and sends it to a network module which uses yet
+another CryptoAuth session to encipher and authenticate the packet from the
+switch header down. The resulting data is packaged in a network packet and sent
+to the switch at the next node.
+
+Upon receiving the packet, the next node sends the packet through its
+CryptoAuth session thus revealing the switch header and it sends the packet to
+its switch. The switch most likely will send the packet out to another endpoint
+as per the dictate of the packet label but may send it to its router, eventually
+the node for which the packet is destine will receive it.
+
+The router, upon receiving the packet will examine it to see if it appears to be
+a CryptoAuth Connect To Me packet, Hello packet, or Key packet. If it is one of
+these, it will insert the IPv6 address, as derived from the public key in the
+header, into a hashtable so it can be looked up by the switch label. Otherwise
+it will do a lookup. If the Address cannot be found in its hashtable, it will
+try asking the router if it knows of a node by that label and if all fails, the
+packet will be dropped.
+
+From the IPv6 address, it will lookup the CryptoAuth session or create one if
+necessary, then pass the opaque data through the CryptoAuth session to get the
+decrypted IPv6 header.
+
+If the source address for the packet is the same as the double SHA-512 of the
+public key for the router from which it came, it's assumed to have no inner
+layer of encryption and it is written to the TUN device as it is. If its source
+address is different, it is passed back through a CryptoAuth session as selected
+based on the source IPv6 address. The IPv6 header is then moved up to meet the
+content (into the place where the CryptoAuth header had been) and the final
+packet is written out to the TUN device.
+
+![illustration](https://github.com/cjdelisle/cjdns/raw/master/doc/CjdnsModules.png)
+
+
+[OSLR]: http://tools.ietf.org/html/rfc3626
+
+[HSLS]: http://www.ir.bbn.com/documents/techmemos/TM1301.pdf
+
+[BATMAN]: http://en.wikipedia.org/wiki/B.A.T.M.A.N.
+
+[1]: http://www.cert.org/tech_tips/denial_of_service.html
+
+[2]: http://www.verisigninc.com/assets/whitepaper-ddos-threat-forrester.pdf "DDoS: A Threat You Can’t Afford To Ignore" 
+
+[LISP]: http://lisp.cisco.com/
+
+[Bitcoin]: http://www.bitcoin.org/ "BitCoin: a decentralized electronic cash system using peer-to-peer networking, digital signatures and cryptographic proof to enable irreversible payments between parties without relying on trust."
+
+[Namecoin]: http://dot-bit.org/Main_Page "Namecoin: a peer-to-peer generic name/value datastore system based on Bitcoin technology (a decentralized cryptocurrency)."
+
+[IPSEC]: http://en.wikipedia.org/wiki/IPsec "IPsec: a protocol suite for securing Internet Protocol (IP) communications by authenticating and encrypting each IP packet of a communication session. IPsec also includes protocols for establishing mutual authentication between agents at the beginning of the session and negotiation of cryptographic keys to be used during the session."
+
+[DNSSEC]: http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions "A suite of Internet Engineering Task Force (IETF) specifications for securing certain kinds of information provided by the Domain Name System (DNS) as used on Internet Protocol (IP) networks. It is a set of extensions to DNS which provide to DNS clients (resolvers) origin authentication of DNS data, authenticated denial of existence, and data integrity, but not availability or confidentiality."
+
+[DNS]: https://en.wikipedia.org/wiki/Domain_Name_System "A hierarchical distributed naming system for computers, services, or any resource connected to the Internet or a private network. It associates various information with domain names assigned to each of the participating entities. Most importantly, it translates domain names meaningful to humans into the numerical identifiers associated with networking equipment for the purpose of locating and addressing these devices worldwide."
+
+[P2P]: http://en.wikipedia.org/wiki/Peer-to-peer "Peer-to-peer (P2P) computing or networking is a distributed application architecture that partitions tasks or workloads among peers. Peers are equally privileged, equipotent participants in the application. They are said to form a peer-to-peer network of nodes."
+
+[Internet]: http://en.wikipedia.org/wiki/Internet "A global system of interconnected computer networks that use the standard Internet protocol suite (TCP/IP) to serve billions of users worldwide. It is a network of networks that consists of millions of private, public, academic, business, and government networks, of local to global scope, that are linked by a broad array of electronic, wireless and optical networking technologies."
+
+[DDoS]: http://en.wikipedia.org/wiki/Denial-of-service_attack "An attempt to make a computer or network resource unavailable to its intended users. Although the means to carry out, motives for, and targets of a DoS attack may vary, it generally consists of the concerted efforts of a person, or multiple people to prevent an Internet site or service from functioning efficiently or at all, temporarily or indefinitely."
+
+[bEncode]: http://en.wikipedia.org/wiki/Bencode "The encoding used by the peer-to-peer file sharing system BitTorrent for storing and transmitting loosely structured data."
+
+[DHT]: http://en.wikipedia.org/wiki/Distributed_hash_table "A class of a decentralized distributed system that provides a lookup service similar to a hash table; (key, value) pairs are stored in a DHT, and any participating node can efficiently retrieve the value associated with a given key. Responsibility for maintaining the mapping from keys to values is distributed among the nodes, in such a way that a change in the set of participants causes a minimal amount of disruption. This allows a DHT to scale to extremely large numbers of nodes and to handle continual node arrivals, departures, and failures."
+
+[BitTorrent]: http://en.wikipedia.org/wiki/BitTorrent_(protocol) "A peer-to-peer file sharing protocol used for distributing large amounts of data over the Internet. "
+
+[Kademlia]: http://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf

doc/admin-api.md

@@ -0,0 +1,944 @@
+#Cjdns Admin API
+
+Cjdns is inspected and configured through a UDP socket.
+When cjdroute starts up, it reads the configuration file and spawns cjdns core. The core
+knows nothing but the port which it should bind to and the private key which it should use.
+All other information such as peers, interfaces and passwords is given to the core through the
+admin UDP interface. When cjdroute is finished setting up the core, it exits leaving the core
+running in the background.
+
+You can call all of the functions which are called by cjdroute to collect information and alter
+the core's configuration.
+
+## How a function works
+To call a function you send a udp packet containing a bencoded request to the core and it sends
+back a bencoded response.
+
+    echo -n 'd1:q4:pinge' | nc6 -u -t 1 -n -w3 127.0.0.1 11234
+
+If you are more comfortable writing json then benc, you can use benc2json in reverse mode to
+preprocess your message. **Note**: benc2json has been removed in 2821c81d49 to speed up the build.
+
+    echo '{ "q": "ping" }' | ./build/benc2json -r
+
+Stream the request from json into benc and then make the request to the core:
+
+    echo '{ "q": "ping" }' \
+        | ./build/benc2json -r \
+        | tr -d '\n' \
+        | nc6 -u -t 1 -n -w3 127.0.0.1 11234
+
+Get the result back into json:
+
+    echo '{ "q": "ping" }' \
+        | ./build/benc2json -r \
+        | tr -d '\n' \
+        | nc6 -u -t 1 -n -w3 127.0.0.1 11234 \
+        | ./build/benc2json
+
+
+## Transaction ID
+Because you can send multiple messages at once, you may add a transaction ID to a message and it
+will be reflected back to you in the response.
+
+    echo '{ "q": "ping", "txid": "my request" }' \
+        | ./build/benc2json -r \
+        | tr -d '\n' \
+        | nc6 -u -t 1 -n -w3 127.0.0.1 11234 \
+        | ./build/benc2json
+
+Result:
+
+    {
+      "txid" : "my request",
+      "q" : "pong"
+    }
+
+
+## Arguments
+Some functions require arguments and others allow arguments but assume defaults if they are
+not provided. Arguments are sent to a function through a benc *dictionary* called `args`.
+
+The `Admin_availableFunctions()` function has an optional argument called `page`, this is
+because there are too many functions to be described in a single UDP packet. The following
+command will get the first page of functions from `Admin_availableFunctions` which will
+describe other functions and their required and allowed arguments.
+
+    echo -n '
+    {
+        "q": "Admin_availableFunctions",
+        "args": {
+            "page": 0
+        }
+    }' | ./build/benc2json -r \
+        | tr -d '\n' \
+        | nc6 -u -t 1 -n -w3 127.0.0.1 11234 \
+        | ./build/benc2json
+
+
+## Authentication
+Any function which changes the state of cjdns core requires authentication to carry out.
+Authentication is done on a per-request basis. Functions which don't require authentication
+can still be called with authentication and will still fail if the authentication is incorrect.
+
+* Step 1: Request a cookie from the server.
+
+* Step 2: Calculate the SHA-256 of the cookie and your admin password, place this hash and cookie
+in the request.
+
+* Step 3: Calculate the SHA-256 of the entire request with the hash and cookie added,
+replace the hash in the request with this result.
+
+Steps 1 and 2 securely bind the cookie to the password so that the password hash cannot
+be taken and used again in another request later on, step 3 binds the cookie and password to
+the request so that a man-in-the-middle cannot change the content of the request in flight.
+
+
+### Anatomy of an authenticated request
+
+A plain request such as `{"q": "ping"}` becomes `{"q":"auth", "aq":"ping", "hash":<calculated hash>}`.
+The `q` field is moved to `aq` (authenticated query) and the `q` field says `auth`.
+
+**NOTE:** A cookie is only valid for 10 seconds so requesting and using a cookie must be done
+in the same script.
+
+**NOTE2:** Cookies are reusable *for now* this is not part of the API and is considered a
+bug, you should always request a new cookie for each authenticated request otherwise you may
+be broke by changes in the future.
+
+### By example
+
+**Step 1:** Get the cookie
+
+    RESP=`echo -n 'd1:q6:cookiee' | nc6 -u -t 1 -n -w3 127.0.0.1 11234` \
+    echo response=${RESP}; \
+    COOKIE=`echo ${RESP} | sed 's/d6:cookie10:\([0-9]*\)e/\1/'` \
+    echo cookie=${COOKIE};
+
+**Step 2:** Calculate the hash of the cookie and password:
+For this step, you will need the admin password from your cjdroute.conf file, it's to be found
+inside of the block which says `"admin": {`.
+
+    ADMIN_PASS=you_will_find_this_in_your_cjdroute_dot_conf \
+    REQUEST='{"q": "auth", "aq": "ping", "hash": "__HASH__", "cookie": "__COOKIE__"}' \
+    COOKIE_RESP=`echo -n 'd1:q6:cookiee' | nc6 -u -t 1 -n -w3 127.0.0.1 11234` \
+    COOKIE=`echo ${COOKIE_RESP} | sed 's/d6:cookie10:\([0-9]*\)e/\1/'` \
+    HASH_ONE=`echo -n "${ADMIN_PASS}${COOKIE}" | sha256sum -b | cut -d\  -f1` ; \
+    REQ_ONE=`echo $REQUEST | sed -e "s/__HASH__/${HASH_ONE}/" -e "s/__COOKIE__/${COOKIE}/" \
+            | ./build/benc2json -r | tr -d '\n'` ; \
+    echo "hash of password and cookie is ${HASH_ONE}" ; \
+    echo "Request with cookie and hash added:" ; \
+    echo "${REQ_ONE}" ; \
+    echo "JSON version of request:" ; \
+    echo "${REQ_ONE}" | ./build/benc2json
+
+**Step 3:** Calculate the SHA-256 of the entire request and replace the one in the request:
+This will calculate the final request and send it to cjdns.
+
+    ADMIN_PASS=you_will_find_this_in_your_cjdroute_dot_conf \
+    REQUEST='{"q": "auth", "aq": "ping", "hash": "__HASH__", "cookie": "__COOKIE__"}' \
+    COOKIE_RESP=`echo -n 'd1:q6:cookiee' | nc6 -u -t 1 -n -w3 127.0.0.1 11234` \
+    COOKIE=`echo ${COOKIE_RESP} | sed 's/d6:cookie10:\([0-9]*\)e/\1/'` \
+    HASH_ONE=`echo -n "${ADMIN_PASS}${COOKIE}" | sha256sum -b | cut -d\  -f1` \
+    REQ_ONE=`echo $REQUEST | sed -e "s/__HASH__/${HASH_ONE}/" -e "s/__COOKIE__/${COOKIE}/" \
+        | ./build/benc2json -r | tr -d '\n'` \
+    FINAL_HASH=`echo -n "$REQ_ONE" | sha256sum -b | cut -d\  -f1` \
+    FINAL_REQ=`echo $REQ_ONE | sed -e "s/${HASH_ONE}/${FINAL_HASH}/"` ; \
+    echo -n "$FINAL_REQ" \
+        | nc6 -u -t 1 -n -w3 127.0.0.1 11234 \
+        | ./build/benc2json
+
+
+If you see this:
+
+    {
+      "q" : "pong"
+    }
+
+then it has succeeded, if the password is incorrect, you will see this:
+
+    {
+      "error" : "Auth failed."
+    }
+
+### Tools:
+
+Obviously using bash to craft cjdns admin RPC calls is probably the most awkward way possible,
+there are tools in cjdns/contrib which will help you craft requests, specifically there are
+libraries written in python and perl which will allow users to call cjdns internal functions
+as python/perl native functions. A tool called `cexec` is provided with the python library which
+allows you to call cjdns functions from shell scripts or the command line as follows:
+
+    ./contrib/python/cexec 'ping()'
+
+
+## Cjdns Functions:
+
+    user@ubnta8:~/wrk/cjdns$ ./contrib/python/cexec 'functions()' | sort
+    Admin_asyncEnabled()
+    Admin_availableFunctions(page='')
+    Allocator_bytesAllocated()
+    Allocator_snapshot(includeAllocations='')
+    AuthorizedPasswords_add(password, user, authType='', ipv6=0)
+    AuthorizedPasswords_list()
+    AuthorizedPasswords_remove(user)
+    Core_exit()
+    Core_initTunnel(desiredTunName=0)
+    Core_pid()
+    ETHInterface_beacon(interfaceNumber='', state='')
+    ETHInterface_beginConnection(publicKey, macAddress, interfaceNumber='', password=0)
+    ETHInterface_new(bindDevice)
+    InterfaceController_disconnectPeer(pubkey)
+    InterfaceController_peerStats(page='')
+    IpTunnel_allowConnection(publicKeyOfAuthorizedNode, ip6Address=0, ip4Address=0)
+    IpTunnel_connectTo(publicKeyOfNodeToConnectTo)
+    IpTunnel_listConnections()
+    IpTunnel_removeConnection(connection)
+    IpTunnel_showConnection(connection)
+    memory()
+    NodeStore_dumpTable(page)
+    NodeStore_getLink(parent, linkNum)
+    NodeStore_getRouteLabel(pathParentToChild, pathToParent)
+    NodeStore_nodeForAddr(ip=0)
+    ping()
+    RainflyClient_addKey(ident)
+    RainflyClient_addServer(addr)
+    RainflyClient_minSignatures(count)
+    RouterModule_findNode(nodeToQuery, target, timeout='')
+    RouterModule_getPeers(path, nearbyPath=0, timeout='')
+    RouterModule_lookup(address)
+    RouterModule_pingNode(path, timeout='')
+    SearchRunner_showActiveSearch(number)
+    Security_checkPermissions()
+    Security_dropPermissions()
+    Security_setUser(user)
+    SessionManager_getHandles(page='')
+    SessionManager_sessionStats(handle)
+    SwitchPinger_ping(path, data=0, keyPing='', timeout='')
+    UDPInterface_beginConnection(publicKey, address, interfaceNumber='', password=0)
+    UDPInterface_new(bindAddress=0)
+
+
+###RouterModule_pingNode()
+
+**Auth Required**
+
+Send a node a cjdns ping request.
+
+Parameters:
+
+* required String **path** may be a route such as "0000.0000.0000.1d53" or an ip address such as
+"fc5d:baa5:61fc:6ffd:9554:67f0:e290:7536", or an ip with explicit path
+eg: "fc5d:baa5:61fc:6ffd:9554:67f0:e290:7536@0000.0000.0000.1d53"
+
+* Int **timeout** (optional) the number of milliseconds after which to timeout the ping
+if there is no response. Defaults to router's adaptive ping timeout if unspecified.
+
+Responses:
+
+* **error**: `could not find node to ping` if there was no node by the given address found in the
+routing table
+
+* **result**: `timeout` gives timeout and number of milliseconds since the ping.
+
+* **result**: `pong` gives `version` representing the git hash of the source code which built the
+pinged node, and `ms` which is the number of milliseconds since the original ping.
+
+Examples:
+
+    >>> cjdns.RouterModule_pingNode('fc38:4c2c:1a8f:3981:f2e7:c2b9:6870:6e84')
+    {'version': '5c5e84ccdba3f31f7c88077729700b4368320bc2', 'result': 'pong', 'ms': 79}
+
+    >>> cjdns.RouterModule_pingNode('fc5d:baa5:61fc:6ffd:9554:67f0:e290:7536')
+    {'error': 'could not find node to ping'}
+
+    >>> cjdns.RouterModule_pingNode('0000.0000.0000.0013')
+    {'version': '2b62b9ae911f1044e45f3f28fdd63d0d5a7fc512', 'result': 'pong', 'ms': 0}
+
+    >>> cjdns.RouterModule_pingNode('a')
+    {'error': "Unexpected length, must be either 39 char ipv6 address (with leading zeros)
+    eg: 'fc4f:000d:e499:8f5b:c49f:6e6b:01ae:3120' or 19 char path eg: '0123.4567.89ab.cdef'"}
+
+    >>> cjdns.RouterModule_pingNode('aaaaaaaaaaaaaaaaaaa')
+    {'error': 'parse path failed'}
+
+    >>> cjdns.RouterModule_pingNode('aaaaaaaaaaaaaaaaaaazzzzzzzzzzzzzzzzzzzz')
+    {'error': 'parsing address failed'}
+
+    >>> cjdns.RouterModule_pingNode('fc38:4c2c:1a8f:3981:f2e7:c2b9:6870:6e84', 10)
+    {'result': 'timeout', 'ms': 10}
+
+### ETHInterface Functions:
+
+ETHInterface is a connector which allows cjdns nodes on the same lan to automatically connect
+without the need to IP addresses on the LAN or sharing of connection credentials. It works on
+wireless LANs as well as wired ethernet LANs.
+
+#### ETHInterface_new()
+
+Create a new ETHInterface and bind it to a device.
+**NOTE**: this call will always fail with `'error': 'call to socket() failed. [permission denied]'`
+unless it is running as root and will fail with `process cannot open more files` if
+`Security_setUser()` has already been called.
+
+**Auth Required**
+
+Parameters:
+
+* required String **bindDevice** the name of the ethernet device to bind to, eg: `eth0` or `wlan0`.
+
+Returns:
+
+* Int **interfaceNumber** an number which can be used to carry out other operations on the interface later.
+
+
+#### ETHInterface_beginConnection()
+
+Connect an ETHInterface to another computer which has an ETHInterface running.
+
+**Auth Required**
+
+Parameters:
+
+* required String **publicKey** The public key of the other node, similar to `UDPInterface_beginConnection()`
+* required String **macAddress** The mac address of the other node.
+* Int **interfaceNumber** The interface number to use, assumed 0 (first ETHinterface created) if not supplied.
+* String **password** A password for connecting to the other node if required.
+
+Returns:
+
+* String **error**: `none` if everything went well.
+
+Other errors are self-explanitory.
+
+
+#### ETHInterface_beacon()
+
+Enable or disable sending or receiving of ETHInterface beacon messages.
+ETHInterface uses periodic beacon messages to automatically peer nodes which are on the same LAN.
+Be mindful that if your lan has is open wifi, enabling beaconing will allow anyone to peer with you.
+
+**Auth Required**
+
+Beacon States:
+0. Disabled, no beacons are sent and incoming beacon messages are discarded.
+1. Accepting, no beacons are sent but if an incoming beacon is received, it is acted upon.
+2. Sending and Accepting, beacons are sent and accepted.
+
+Parameters:
+
+* Int **interfaceNumber** The number of the ETHInterface to change the state of, assumed 0 if not provided.
+* Int **state** What state to switch to, if not provided, the current state will be queried only.
+
+Returns:
+
+* String **error**: `none` if all went well.
+* Int **state**: the state number after the call is complete.
+* String **stateName**: a description of the state.
+
+
+Example:
+
+    $ ./contrib/python/cexec 'ETHInterface_beacon(2)'
+    {'txid': 'FYRKHAPIM3', 'error': 'invalid interfaceNumber'}
+
+    $ ./contrib/python/cexec 'ETHInterface_beacon(0)'
+    {'txid': 'Z7KHE7SZ5R', 'state': 2, 'stateName': 'sending and accepting', 'error': 'none'}
+
+    $ ./contrib/python/cexec 'ETHInterface_beacon(0, 0)'
+    {'txid': 'TP1R8PYCNS', 'state': 0, 'stateName': 'disabled', 'error': 'none'}
+
+    $ ./contrib/python/cexec 'ETHInterface_beacon(0, 1)'
+    {'txid': 'UGKKGX4ZC9', 'state': 1, 'stateName': 'accepting', 'error': 'none'}
+
+    $ ./contrib/python/cexec 'ETHInterface_beacon(0, 2)'
+    {'txid': '1B7RXJEH3N', 'state': 2, 'stateName': 'sending and accepting', 'error': 'none'}
+
+
+### IpTunnel Functions
+
+IPTunnel is designed to allow tunneling of IPv4 and IPv6 packets through a cjdns network
+to the external internet or to a virtual LAN. It provides familiar VPN type functionality.
+There are 2 nodes, a client and a server, the server uses `IPTunnel_allowConnection()` and the
+client uses `IPTunnel_connectTo()` the server assigns IPv4 and/or IPv6 addresses to the client
+and the client is required to use only these addresses, subnet assignment is not supported.
+When the client uses `IPTunnel_connectTo()`, it sends a request to the server for addresses and
+continues polling the server periodically until the addresses are provided.
+
+#### IpTunnel_listConnections()
+
+List the connection numbers of all IPTunnel connections.
+
+**Auth Required**
+
+Returns:
+
+* List **connections**: A list of integers representing the connection numbers for each connection.
+* String **error**: `none`
+
+
+Example:
+
+    $ ./contrib/python/cexec 'IpTunnel_listConnections()'
+    {'connections': [0], 'txid': '5ZFPFJ60AT', 'error': 'none'}
+
+
+#### IpTunnel_showConnection()
+
+Show information about a perticular IPTunnel connection.
+
+**Auth Required**
+
+Parameters:
+
+* required Int **connection**: the connection number for the connection to show information about.
+
+Returns:
+
+* Int **outgoing**: 1 if the connection is outgoing, 0 if it's incoming.
+* String **key**: the cjdns public key of the foreign node.
+* String **ip6Address**: the IPv6 address which is assigned to this IPTunnel if applicable.
+* Int **ip6Prefix**: the IPv6 netmask/prefix length which is assigned to this IPTunnel if applicable.
+* String **ip4Address**: the IPv4 address which is assigned to this IPTunnel if applicable.
+* Int **ip4Prefix**: the IPv4 netmask/prefix length which is assigned to this IPTunnel if applicable.
+* String **error**: `none` unless the connection number is invalid.
+
+Examples:
+
+    # Prior to getting it's addresses from the server, they are not listed.
+    $ ./contrib/python/cexec 'IpTunnel_showConnection(0)'
+    {'outgoing': 1, 'txid': 'REIV40SXD9', 'key': 'd5d0wu0usrkufd8s98t19gt7m2ggvbz1xbnuxu82x63uqlnk2kb0.k', 'error': 'none'}
+
+    # After a short wait, the addresses are provided and they are now listed.
+    $ ./contrib/python/cexec 'IpTunnel_showConnection(0)'
+    {'outgoing': 1, 'txid': 'CAQCTWECRD', 'ip4Address': '192.168.10.2', 'key': 'd5d0wu0usrkufd8s98t19gt7m2ggvbz1xbnuxu82x63uqlnk2kb0.k', 'error': 'none', 'ip6Address': '2a02:2498:e000:20::144:3'}
+
+
+#### IpTunnel_removeConnection()
+
+Remove an IPTunnel connection from the list, the other end will nolonger be able to send traffic
+over this connection.
+
+**Auth Required**
+
+**NOT IMPLEMENTED**
+
+
+#### IpTunnel_connectTo()
+
+Initiate an *outgoing* connection to another node and request IP addresses from them.
+
+**Auth Required**
+
+Parameters:
+
+* required String **publicKeyOfNodeToConnectTo** the pubkey of the node to connect to.
+
+Returns:
+
+* String **error**: `none` if all went well
+* Int **connection**: the connection number of the new connection
+
+Examples:
+
+    $ ./contrib/python/cexec 'IpTunnel_connectTo("d5d0wu0usrkufd8s98t19gt7m2ggvbz1xbnuxu82x63uqlnk2kb0.k")'
+    {'connection': 1, 'txid': '9QXRQO1FG8', 'error': 'none'}
+
+
+#### IpTunnel_allowConnection()
+
+Allow in *incoming* connection from another node, they must also use `IPTunnel_connectTo()` in order
+to complete the connection.
+
+**Auth Required**
+
+Parameters:
+* required String **publicKeyOfAuthorizedNode** The key of the node which is authorized to connect.
+* String **ip6Address** The IPv6 address to give them if applicable.
+* String **ip4Address** The IPv4 address to give them if applicable.
+
+Returns:
+
+* String **error** `none` if all went well.
+* Int **connection** the connection number for the new connection.
+
+
+
+### UDPInterface Functions
+
+UDPInterface is the basic cjdns interface which is used to link distant nodes over the internet.
+It will work on a LAN as long as the nodes have IP addresses but for linking on a LAN, ETHInterface
+is easier.
+
+#### UDPInterface_new()
+
+Create a new UDPInterface which is either bound to an address/port or not.
+
+**NOTE**: This call will fail with `'error': 'call to socket() failed [process cannot open more files]'`
+is `Security_noFiles()` has already been called.
+
+Parameters:
+
+* String **bindAddress**: the address/port to bind to, if unspecified, it is assumed to be `0.0.0.0`.
+
+Returns:
+
+* String **error** `none` if all went well
+* Int **interfaceNumber** the number of the interface, usable with `UDPInterface_beginConnection()`
+
+
+#### UDPInterface_beginConnection()
+
+Start a direct connection to another node.
+
+**Auth Required**
+
+Parameters:
+
+* required String **publicKey** the base32 public key for the node to connect to, ending in .k.
+* required String **address** the ip address and port for the node, at this time DNS resolution
+and IPv6 is not supported.
+* Int **interfaceNumber** the number for the UDPInterface to use for connecting, provided by
+*UDPInterface_new()* if not sent, 0 is assumed.
+* String **password** a password to use when connecting.
+
+Note: just because it returns `'error': 'none'` does not mean that the connection was successful.
+The neighbor may still reject our connection attempts.
+
+Example:
+
+    >>> cjdns.UDPInterface_beginConnection("v0zyvrjuc4xbzh4n9c4k3qpx7kg8xgndv2k45j9nfgb373m8sss0.k", "192.168.0.2:10000", "null")
+    {'error': 'none'}
+
+    >>> cjdns.UDPInterface_beginConnection("v0zyvrjuc4xbzh4n9c4k3qpx7kg8xgndv2k45j9nfgb373m8sss0.k", "x", "null")
+    {'error': 'unable to parse ip address and port.'}
+
+    >>> cjdns.UDPInterface_beginConnection("k", "x", "null")
+    {'error': 'publicKey is too short, must be 52 characters long.'}
+
+    >>> cjdns.UDPInterface_beginConnection("------------------------------------------------------", "x", "null")
+    {'error': 'failed to parse publicKey.'}
+
+    >>> cjdns.UDPInterface_beginConnection("zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz0.k", "192.168.0.2:10000", "null")
+    {'error': 'invalid cjdns public key.'}
+
+    >>> cjdns.UDPInterface_beginConnection("v0zyvrjuc4xbzh4n9c4k3qpx7kg8xgndv2k45j9nfgb373m8sss0.k", "[1234::5]:10000", "null")
+    {'error': 'different address type than this socket is bound to.'}
+
+
+### AdminLog Functions:
+
+Since cjdns contains so many logging locations, logging to a file would not only be inefficient
+but it would fill up your disk rather quickly. Because if this, cjdns logging is only enabled on
+request, with these functions you can ask for logs to be enabled on a log level, per-file or even
+per-line basis.
+
+Log levels may be excluded at compile time in which case they will not be available.
+Each log level implies inclusion of every higher level, if you subscribe to **INFO** logging, you
+will also automatically get **WARN**, **ERROR**, and **CRITICAL**.
+
+Cjdns log levels:
+
+* **KEYS** Not compiled in by default, contains private keys and other secret information.
+* **DEBUG** Default level, contains lots of information which is probably not useful unless you are
+diagnosing an ongoing problem.
+* **INFO** Shows starting and stopping of various components and general purpose information.
+* **WARN** Generally this means some system has undergone a minor failure, this includes failures
+due to network disturbance.
+* **ERROR** This means there was a (possibly temporary) failure of a system within cjdns.
+* **CRITICAL** This means something is broken such that the cjdns core will likely
+have to exit immedietly.
+
+
+To see an implementation of cjdns log consumer, look at `contrib/python/cjdnslog`.
+
+
+#### AdminLog_subscribe()
+
+Subscribe to logging of a level/file/line.
+
+**Auth Required**
+
+**NOTE**: Because this function responds asynchronously, using `netcat` or `cexec` to call it
+will not work, additionally it will stop sending asynchronous messages unless an incoming message
+comes in every 10 seconds so you must send periodic messages on the same UDP port.
+See: `Admin_asyncEnabled()` for more information.
+
+Parameters:
+
+* Int **line**: If specified, the logging will be constrained to the log message which appers on
+the given line number in the source file.
+* String **file**: If specified, the logging will be constrained to the named file, names are not
+fully qualified, use "CryptoAuth.c", not "/path/to/CryptoAuth.c".
+* String **level**: If specified, the logging will be constrained to log lines which are of the
+given level or higher.
+
+Returns:
+
+* String **error**: `none` if all goes well.
+* String **streamId**: an opaque string which will be contained in each log message.
+
+Log message structure:
+
+* String **file** the name of the file where the log message came from, eg: "CryptoAuth.c".
+* String **level** the log level, one of `["KEYS", "DEBUG", "INFO", "WARN", "ERROR", "CRITICAL"]`
+* Int **line** the line number of the line where the log function was called.
+* String **message** the log message
+* String **streamId** the streamId for the logging subscription.
+* Int **time** the time in seconds since the unix epoch when the log message was created.
+* String **txid** the same transaction which was used in the call to `AdminLog_subscribe()`.
+
+
+#### AdminLog_unsubscribe()
+
+Unsubscribe from logging.
+
+**Auth Required**
+
+Parameters:
+
+* required String **streamId**: The id returned in the call to `AdminLog_subscribe()`.
+
+Returns:
+
+* String **error**: `none` if the subscription existed and was removed.
+
+**Note**: If the subscription has already timed out, removing it will yield `'error': 'No such subscription.'`.
+
+Example:
+
+    $ ./contrib/python/cexec 'AdminLog_subscribe()'
+    {'txid': '0EKWEP7VXI', 'streamId': 'f1a0e225183397f4', 'error': 'none'}
+
+    $ ./contrib/python/cexec 'AdminLog_unsubscribe("f1a0e225183397f4")'
+    {'txid': 'CB4V7KLYCC', 'error': 'none'}
+
+
+### Admin Functions
+
+These functions are for dealing with the Admin interface, the infrastructure which allows all
+of the other functions throughout cjdns to be accessed from the admin socket.
+
+#### Admin_availableFunctions()
+
+Get a list of functions which are available to the admin socket as well as their required and
+optional parameters, unfortunately their return values are not provided and can only be determined
+by experimentation or by reading the source.
+
+**Note**: The list of functions is paged to make sure each message fits inside of a UDP packet, in
+order to get the whole list of functions, you must increment the `page` parameter until the result
+nolonger contains the `more` field.
+
+Parameters:
+
+* Int **page**: the page of functions to request, if unspecified it will be assumed to be 0.
+
+Returns:
+
+* Dict **availableFunctions**: a map of function descriptions by function name.
+* Int **more**: only present if there are more pages.
+
+##### Function Description:
+
+Each function description is a Dict of function parameters with the parameter name as the key and
+the specifications as the value. The specification `required` is an Int which is either 0 meaning
+the parameter is optional or 1 meaning it is required. `type` is a String which is one of
+`["Int", "String", "Dict", "List"]` and defines the type which the parameter must be.
+
+    'AdminLog_subscribe': {
+        'line': {
+            'required': 0,
+            'type': 'Int'
+        },
+        'file': {
+            'required': 0,
+            'type': 'String'
+        },
+        'level': {
+            'required': 0,
+            'type': 'String'
+        }
+    }
+
+
+#### Admin_asyncEnabled()
+
+This function is for determining whether asynchronous communication is allowed.
+Asynchronous communication, EG: AdminLog responses, is only allowed with clients which satisfy
+certain requirements.
+
+1. They must send an authenticated request, in the case of AdminLog this is no worry because
+`AdminLog_subscribe()` requires authentication.
+2. They must have sent something in the past 10 seconds, because of the statelessness of UDP,
+there is no way to tell a client which is listening quietly from one which has wandered off so
+in order to remain enabled, it must periodically ping (or periodically call `Admin_asyncEnabled()`).
+These calls do not need to be authenticated, there just needs to have been one in history.
+
+Returns:
+
+* Int **asyncEnabled**: 1 if asynchronous communication is allowed for this session, 0 otherwise.
+
+Example:
+This example illustrates how using `cexec` to call it returns true because `cexec` uses
+authenticated calls whereas manually calling it without authentication returns false.
+
+    $ ./contrib/python/cexec 'Admin_asyncEnabled()'
+    {'asyncEnabled': 1, 'txid': '74GF0SS2N0'}
+
+    echo '{ "q": "Admin_asyncEnabled" }' \
+        | ./build/benc2json -r \
+        | tr -d '\n' \
+        | nc -u 127.0.0.1 11234 \
+        | ./build/benc2json
+
+    {
+      "asyncEnabled" : 0
+    }
+
+
+### Security Functions
+
+These functions are available for putting the cjdns core into a sandbox where
+a security breach within the core would be less likely to cause a total system compromize.
+
+
+#### Security_setUser()
+
+Set the user ID which cjdns is running under to a different user. This function allows cjdns
+to shed privileges after starting up.
+
+**NOTE**: This function will always fail with an error about `process cannot open more files` if
+`Security_noFiles()` has already been called.
+
+Parameters:
+
+* required String **user**: the name of the user to change to.
+
+Return:
+
+* String **error**: `none` if all went well, otherwise a description of the failure.
+
+
+#### Security_noFiles()
+
+Set the hard open file limit to zero, while this does not force closed file descriptors which are
+already open, it makes any function requiring the opening of a file to fail providing a powerful
+sandbox. By calling this function after cjdns is started, one can insure that cjdns core cannot
+touch the filesystem or open network sockets which it does not already have open. This will however
+prevent a number of other admin API functions fron working.
+
+Returns:
+
+* String **error**: `none`
+
+Examples:
+
+    $ ./contrib/python/cexec 'UDPInterface_new("[::]:2048")'
+    {'interfaceNumber': 3, 'txid': 'NQGOZXJZIC', 'error': 'none'}
+
+    $ ./contrib/python/cexec 'Security_noFiles()'
+    {'txid': 'CQYQWA5SZY', 'error': 'none'}
+
+    $ ./contrib/python/cexec 'UDPInterface_new("[::]:5000")'
+    {'txid': 'UZH9LIUOG0', 'cause': 'process cannot open more files', 'error': 'call to socket() failed [process cannot open more files]'}
+
+
+
+### Core_initTunnel()
+
+This function is used during cjdns startup to initialize the TUN device, set it's IP address
+and set the MTU, it is hastily designed and may be removed in the future.
+
+Parameters:
+
+* String **desiredTunName**: the name of the TUN device to use, if unspecified it will ask the
+kernel for a new device.
+
+Returns:
+
+* String **error**: `none` if all went well, otherwise the error which occured.
+
+**Note**: an error will be returned if anything goes wrong initializing the tunnel, setting it's
+IP address or setting it's MTU, even if there is an error, the tunnel may work just fine and
+even if the tunnel doesn't work, cjdns will function as a router only without the TUN device.
+
+
+### Core_exit()
+
+A function to stop cjdns.
+
+Returns:
+
+* String **error**: `none` before exiting.
+
+
+
+### ping()
+
+Returns:
+
+    {'q':'pong'}
+
+For checking if the admin connection is functioning.
+
+
+### RouterModule_lookup()
+
+**Auth Required**
+
+Parameters:
+
+* String **address** a 39 character (zero padded) ipv6 address.
+
+Returns:
+
+* A route if one is found in the routing table.
+* An address and route of the node which should be handed the packet,
+if a route is not found in the local table.
+* An error if the address is not parsable.
+
+Examples:
+
+    >>> print cjdns.RouterModule_lookup('fc5d:baa5:61fc:6ffd:9554:67f0:e290:7535')
+    {'result': '0000.0000.0000.1953', 'error': 'none'}
+
+    >>> print cjdns.RouterModule_lookup('fc5d:baa5:61fc:6ffd:9554:67f0:e290:7536')
+    {'result': 'fcf1:a7a8:8ec0:589b:c64c:cc95:1ced:3679@0000.0000.0000.0013', 'error': 'none'}
+
+    >>> print cjdns.RouterModule_lookup('f')
+    {'result': '', 'error': 'address wrong length'}
+
+    >>> print cjdns.RouterModule_lookup('zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz')
+    {'result': '', 'error': 'failed to parse address'}
+
+
+### AuthorizedPasswords_add()
+
+**Auth Required**
+
+Parameters:
+
+* String **password** a password which will allow neighbors to make direct connections.
+* String **user** a friendly string to identify this password.
+* Int **authType** (optional) the method for authenticating,
+defaults to `1` (only currently supported method).
+
+Returns:
+
+* **error**:`none` if everything went well.
+* **error**:`Specified auth type is not supported.` if the auth type is specified and not `1`.
+* **error**:`Password already added.` if you try to add the same user or password twice.
+* **error**:`Out of memory to store password.` if the buffer for storing
+authorized passwords is full.
+
+Examples:
+
+    $ ./contrib/python/cexec 'AuthorizedPasswords_add(user="test",password="yh14wl2ffgcqq6bvut12xrz7g3")'
+    {'error': 'none'}
+
+    $ ./contrib/python/cexec 'AuthorizedPasswords_add(user="test2",password="2yh14wl2ffgcqq6bvut12xrz7g3",authType=300)'
+    {'error': 'Specified auth type is not supported.'}
+
+    $ ./contrib/python/cexec 'AuthorizedPasswords_add(user="test",password="yh14wl2ffgcqq6bvut12xrz7g3")'
+    {'error': 'Password already added.'}
+
+### AuthorizedPasswords_list()
+
+**Auth Required**
+
+Get a list of all the authorized users.
+
+Example:
+
+    $ ./contrib/python/cexec 'AuthorizedPasswords_list()'
+    {'total': 2, 'users': ['Test User1', 'Local Peers'], 'txid': 'W0DUG0D50K'}
+
+### memory()
+
+Get the number of bytes of memory allocated by all memory allocators in the router.
+
+Example:
+
+    >>> cjdns.memory()
+    {'bytes': 779259}
+
+
+### NodeStore_dumpTable()
+
+Parameters:
+
+* Int **page** the page of the routing table to dump,
+allowing you to get the whole table in a series of reasonably small requests.
+
+Response:
+
+* `routingTable` a key which contains a list of dictionaries, each containing `ip`,
+`link` and `path`. `ip` is the IPv6 address of the node, `link` is a unitless number
+between 0 inclusive and 2^32 exclusive, representing the router's opinion of the quality of
+that path, higher is better. `path` is the route to the node.
+
+* `more` to signal that there is another page of results, the engine will add a `more` key
+with the integer 1, if there isn't another page of results, the `more` key will not be added.
+
+What the data looks like:
+
+    {
+        'routingTable': [
+            {
+                'ip': 'fce5:de17:cbde:c87b:5289:0556:8b83:c9c8',
+                'link': 4294967295,
+                'path': '0000.0000.0000.0001'
+            }, {
+                'ip': 'fcfc:2ebe:346c:7fe7:95af:a58b:2631:dead',
+                'link': 235149061,
+                'path': '0000.0000.631a.3b53'
+            }, {
+                'ip': 'fc70:772a:f803:7c4e:38bd:981b:f791:60a1',
+                'link': 271119350,
+                'path': '0000.0000.017b.b333'
+            },
+            ..............................
+        ],
+        'more': 1
+    }
+
+Example:
+
+    >>> cjdns.NodeStore_dumpTable(0)
+    {'routingTable': [{'ip': 'fce5:de17:cbde:c87b:5289:0556:8b83:c9c8', 'link': 4294967295,....
+
+    >>> cjdns.NodeStore_dumpTable(4)
+    {'routingTable': []}
+
+
+### SwitchPinger_ping()
+
+**Auth Required**
+
+Send a switch level ping. There is no routing table lookup and the router is not involved.
+Pinging IP addresses this way is not possible.
+
+Parameters:
+SwitchPinger_ping(required String path, String data, Int timeout)
+* String **path** the route to the node to ping eg: `0000.0000.04f5.2555`
+* String **data** (optional) for diagnosing data-dependent errors.
+* Int **timeout** (optional) milliseconds to wait for a response.
+If unspecified, will default to `DEFAULT_TIMEOUT` as defined in `SwitchPinger_admin.c` (2 seconds).
+
+Examples:
+
+    >>> cjdns.SwitchPinger_ping('0000.0000.04f5.2555')
+    {'path': '0000.0000.04f5.2555', 'data': '', 'result': 'pong', 'ms': 281}
+
+    >>> cjdns.SwitchPinger_ping('fca5:9fe0:3fa2:d576:71e6:8373:7aeb:ea11')
+    {'error': 'path was not parsable.'}
+
+    >>> cjdns.SwitchPinger_ping('0000.0000.04f5.2555', '12345abcdefg')
+    {'path': '0000.0000.04f5.2555', 'data': '12345abcdefg', 'result': 'pong', 'ms': 326}
+
+    >>> cjdns.SwitchPinger_ping('0000.0000.0405.2555')
+    {'path': '0000.0000.0405.2555', 'data': '', 'result': 'ping message caused switch error', 'ms': 278}
+
+    >>> cjdns.SwitchPinger_ping('0000.0000.04f5.2555', '', 30)
+    {'result': 'timeout', 'ms': 77}
+

doc/autostart-at-login.md

@@ -0,0 +1,20 @@
+Autostart cjdns when you log-in
+===============================
+
+You can configure your session to autostart cjdroute when you log-in to your
+computer. Just add a file in `~/.config/autostart/cjdoute.desktop` containing:
+
+    [Desktop Entry]
+    Comment=
+    Terminal=false
+    Name=cjdroute
+    Exec=xterm -class cjdroute -e bash -c '...path/to/cjdns/cjdroute <~/.config/cjdns/cjdroute.conf; echo "Terminated ($?)"; read'
+    Categories=Network
+    Keywords=cjdns
+    StartupWMClass=cjdroute
+    Type=Application
+    Icon=modem
+    Version=1.0
+
+As you can see, you should put your cjdroute configuration in
+`~/.config/cjdns/cjdroute.conf`.

doc/benchmark.txt

@@ -0,0 +1,1606 @@
+Results of benchmarking cjdns on different systems:
+To make your own benchmark:
+./cjdroute --bench
+cat /proc/cpuinfo
+git log | head -n 1
+
+Paste results to https://ezcrypt.it/ and tell us about it in the IRC channel!
+Weird processors wanted :D
+
+
+
+user@debo8:~/wrk/play/mygit/cjdns/build$ ./cjdroute --bench
+These metrics are speed of encryption and decryption similar to the usage pattern
+when decrypting a packet, switching it, and re-encrypting it with another key.
+Test sending 1000 64 byte	hello packets.	packet auth enabled.	Finished in 466ms. 1098 Kb/s
+
+Test sending 1000 1500 byte	hello packets.	packet auth enabled.	Finished in 432ms. 27776 Kb/s
+
+Test sending 1000 64 byte	key packets.	packet auth enabled.	Finished in 671ms. 763 Kb/s
+
+Test sending 1000 1500 byte	key packets.	packet auth enabled.	Finished in 683ms. 17568 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth disabled.	Finished in 101ms. 506930 Kb/s
+
+Test sending 100000 1500 byte	data packets.	packet auth disabled.	Finished in 1021ms. 1175318 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth enabled.	Finished in 360ms. 142222 Kb/s
+
+This is the switch configuration so this indicates expected switch throughput:
+Test sending 100000 1500 byte	data packets.	packet auth enabled.	Finished in 1708ms. 702576 Kb/s
+
+user@debo8:~/wrk/play/mygit/cjdns/build$ cat /proc/cpuinfo | head
+processor	: 0
+vendor_id	: AuthenticAMD
+cpu family	: 16
+model		: 9
+model name	: AMD Opteron(tm) Processor 6128
+stepping	: 1
+microcode	: 0x10000c4
+cpu MHz		: 800.000
+cache size	: 512 KB
+physical id	: 0
+user@debo8:~/wrk/play/mygit/cjdns/build$ git log -n 1
+commit c2cfff7b4ef1339942f3e98eb0d99a093d307a9b
+
+
+
+
+
+
+
+cjdns@abacus:~/cjdns/build$ ./cjdroute --bench
+These metrics are speed of encryption and decryption similar to the usage pattern
+when decrypting a packet, switching it, and re-encrypting it with another key.
+Test sending 1000 64 byte	hello packets.	packet auth enabled.	Finished in 96628ms. 5 Kb/s
+
+Test sending 1000 1500 byte	hello packets.	packet auth enabled.	Finished in 100130ms. 119 Kb/s
+
+Test sending 1000 64 byte	key packets.	packet auth enabled.	Finished in 149438ms. 3 Kb/s
+
+Test sending 1000 1500 byte	key packets.	packet auth enabled.	Finished in 152898ms. 78 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth disabled.	Finished in 2241ms. 22846 Kb/s
+
+Test sending 100000 1500 byte	data packets.	packet auth disabled.	Finished in 34007ms. 35286 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth enabled.	Finished in 12059ms. 4245 Kb/s
+
+This is the switch configuration so this indicates expected switch throughput:
+Test sending 100000 1500 byte	data packets.	packet auth enabled.	Finished in 151882ms. 7900 Kb/s
+
+cjdns@abacus:~/cjdns/build$ cat /proc/cpuinfo
+Processor	: Feroceon 88FR131 rev 1 (v5l)
+BogoMIPS	: 1196.85
+Features	: swp half thumb fastmult edsp 
+CPU implementer	: 0x56
+CPU architecture: 5TE
+CPU variant	: 0x2
+CPU part	: 0x131
+CPU revision	: 1
+
+Hardware	: Marvell OpenRD Client Board
+Revision	: 0000
+Serial		: 0000000000000000
+cjdns@abacus:~/cjdns/build$ git log -n 1
+commit c2cfff7b4ef1339942f3e98eb0d99a093d307a9b
+
+
+# after the update to nacl
+
+cjdns@abacus:~/cjdns/build$ time ./cjdroute --bench && cat /proc/cpuinfo && git log | head -1
+These metrics are speed of encryption and decryption similar to the usage pattern
+when decrypting a packet, switching it, and re-encrypting it with another key.
+Test sending 1000 64 byte	hello packets.	packet auth enabled.	Finished in 12076ms. 42 Kb/s
+
+Test sending 1000 1500 byte	hello packets.	packet auth enabled.	Finished in 13298ms. 902 Kb/s
+
+Test sending 1000 64 byte	key packets.	packet auth enabled.	Finished in 12304ms. 41 Kb/s
+
+Test sending 1000 1500 byte	key packets.	packet auth enabled.	Finished in 12752ms. 940 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth disabled.	Finished in 1034ms. 49516 Kb/s
+
+Test sending 100000 1500 byte	data packets.	packet auth disabled.	Finished in 20350ms. 58968 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth enabled.	Finished in 3685ms. 13894 Kb/s
+
+This is the switch configuration so this indicates expected switch throughput:
+Test sending 100000 1500 byte	data packets.	packet auth enabled.	Finished in 30179ms. 39762 Kb/s
+
+Processor	: Feroceon 88FR131 rev 1 (v5l)
+BogoMIPS	: 1196.85
+Features	: swp half thumb fastmult edsp 
+CPU implementer	: 0x56
+CPU architecture: 5TE
+CPU variant	: 0x2
+CPU part	: 0x131
+CPU revision	: 1
+
+Hardware	: Marvell OpenRD Client Board
+Revision	: 0000
+Serial		: 0000000000000000
+
+real	1m43.216s
+user	1m21.520s
+sys	0m1.000s
+cjdns@abacus:~/cjdns/build$ 
+
+
+
+
+
+
+
+cjdns@ks397481:~/cjdns/build$ ./cjdroute --bench
+These metrics are speed of encryption and decryption similar to the usage pattern
+when decrypting a packet, switching it, and re-encrypting it with another key.
+Test sending 1000 64 byte	hello packets.	packet auth enabled.	Finished in 3420ms. 149 Kb/s
+
+Test sending 1000 1500 byte	hello packets.	packet auth enabled.	Finished in 3491ms. 3437 Kb/s
+
+Test sending 1000 64 byte	key packets.	packet auth enabled.	Finished in 3413ms. 150 Kb/s
+
+Test sending 1000 1500 byte	key packets.	packet auth enabled.	Finished in 3465ms. 3462 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth disabled.	Finished in 103ms. 497087 Kb/s
+
+Test sending 100000 1500 byte	data packets.	packet auth disabled.	Finished in 1581ms. 759013 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth enabled.	Finished in 724ms. 70718 Kb/s
+
+This is the switch configuration so this indicates expected switch throughput:
+Test sending 100000 1500 byte	data packets.	packet auth enabled.	Finished in 4257ms. 281888 Kb/s
+
+cjdns@ks397481:~/cjdns/build$ cat /proc/cpuinfo | head
+processor	: 0
+vendor_id	: GenuineIntel
+cpu family	: 6
+model		: 28
+model name	: Intel(R) Atom(TM) CPU D425   @ 1.80GHz
+stepping	: 10
+cpu MHz		: 1799.735
+cache size	: 512 KB
+physical id	: 0
+siblings	: 2
+cjdns@ks397481:~/cjdns/build$ git log | head -n 1
+commit fd4964634de971c888bb079d0e62b411c471803a
+
+
+
+
+
+
+
+
+
+user@ubntfusion2:~/cjdns/build$ ./cjdroute --bench
+These metrics are speed of encryption and decryption similar to the usage pattern
+when decrypting a packet, switching it, and re-encrypting it with another key.
+Test sending 1000 64 byte	hello packets.	packet auth enabled.	Finished in 916ms. 558 Kb/s
+
+Test sending 1000 1500 byte	hello packets.	packet auth enabled.	Finished in 939ms. 12778 Kb/s
+
+Test sending 1000 64 byte	key packets.	packet auth enabled.	Finished in 1341ms. 381 Kb/s
+
+Test sending 1000 1500 byte	key packets.	packet auth enabled.	Finished in 1368ms. 8771 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth disabled.	Finished in 134ms. 382089 Kb/s
+
+Test sending 100000 1500 byte	data packets.	packet auth disabled.	Finished in 2291ms. 523788 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth enabled.	Finished in 526ms. 97338 Kb/s
+
+This is the switch configuration so this indicates expected switch throughput:
+Test sending 100000 1500 byte	data packets.	packet auth enabled.	Finished in 3386ms. 354400 Kb/s
+
+user@ubntfusion2:~/cjdns/build$ cat /proc/cpuinfo | head
+processor	: 0
+vendor_id	: AuthenticAMD
+cpu family	: 20
+model		: 1
+model name	: AMD E-350 Processor
+stepping	: 0
+microcode	: 0x5000028
+cpu MHz		: 800.000
+cache size	: 512 KB
+physical id	: 0
+user@ubntfusion2:~/cjdns/build$ git log | head -n 1
+commit 3d2ce46d3c9df964ddf37dbdb03dccbcac862d5a
+user@ubntfusion2:~/cjdns/build$
+
+
+
+
+
+
+
+
+These metrics are speed of encryption and decryption similar to the usage pattern
+when decrypting a packet, switching it, and re-encrypting it with another key.
+Test sending 1000 64 byte	hello packets.	packet auth enabled.	Finished in 1361ms. 376 Kb/s
+
+Test sending 1000 1500 byte	hello packets.	packet auth enabled.	Finished in 1551ms. 7736 Kb/s
+
+Test sending 1000 64 byte	key packets.	packet auth enabled.	Finished in 1334ms. 383 Kb/s
+
+Test sending 1000 1500 byte	key packets.	packet auth enabled.	Finished in 1365ms. 8790 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth disabled.	Finished in 323ms. 158513 Kb/s
+
+Test sending 100000 1500 byte	data packets.	packet auth disabled.	Finished in 1893ms. 633914 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth enabled.	Finished in 708ms. 72316 Kb/s
+
+This is the switch configuration so this indicates expected switch throughput:
+Test sending 100000 1500 byte	data packets.	packet auth enabled.	Finished in 2805ms. 427807 Kb/s
+
+processor	: 0
+vendor_id	: GenuineIntel
+cpu family	: 15
+model		: 4
+model name	: Intel(R) Pentium(R) 4 CPU 3.00GHz
+stepping	: 3
+cpu MHz		: 2994.307
+cache size	: 2048 KB
+physical id	: 0
+siblings	: 2
+core id		: 0
+cpu cores	: 1
+apicid		: 0
+initial apicid	: 0
+fdiv_bug	: no
+hlt_bug		: no
+f00f_bug	: no
+coma_bug	: no
+fpu		: yes
+fpu_exception	: yes
+cpuid level	: 5
+wp		: yes
+flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pebs bts pni dtes64 monitor ds_cpl est cid cx16 xtpr
+bogomips	: 5988.61
+clflush size	: 64
+cache_alignment	: 128
+address sizes	: 36 bits physical, 48 bits virtual
+power management:
+
+processor	: 1
+vendor_id	: GenuineIntel
+cpu family	: 15
+model		: 4
+model name	: Intel(R) Pentium(R) 4 CPU 3.00GHz
+stepping	: 3
+.....
+
+cjdns@xubuntu-27-120:~/cjdns$ git log | head -n 1
+commit 06522239acde31a01633033d9c4229baa7fad229
+
+
+
+
+
+
+
+
+
+These metrics are speed of encryption and decryption similar to the usage pattern
+when decrypting a packet, switching it, and re-encrypting it with another key.
+Test sending 1000 64 byte	hello packets.	packet auth enabled.	Finished in 9996ms. 51 Kb/s
+
+Test sending 1000 1500 byte	hello packets.	packet auth enabled.	Finished in 10459ms. 1147 Kb/s
+
+Test sending 1000 64 byte	key packets.	packet auth enabled.	Finished in 10429ms. 49 Kb/s
+
+Test sending 1000 1500 byte	key packets.	packet auth enabled.	Finished in 10982ms. 1092 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth disabled.	Finished in 3588ms. 14269 Kb/s
+
+Test sending 100000 1500 byte	data packets.	packet auth disabled.	Finished in 34265ms. 35021 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth enabled.	Finished in 8723ms. 5869 Kb/s
+
+This is the switch configuration so this indicates expected switch throughput:
+Test sending 100000 1500 byte	data packets.	packet auth enabled.	Finished in 46702ms. 25694 Kb/s
+
+
+processor	: 0
+vendor_id	: GenuineIntel
+cpu family	: 6
+model		: 5
+model name	: Pentium II (Deschutes)
+stepping	: 2
+cpu MHz		: 267.274
+cache size	: 512 KB
+fdiv_bug	: no
+hlt_bug		: no
+f00f_bug	: no
+coma_bug	: no
+fpu		: yes
+fpu_exception	: yes
+cpuid level	: 2
+wp		: yes
+flags		: fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pse36 mmx fxsr up
+bogomips	: 534.54
+clflush size	: 32
+cache_alignment	: 32
+address sizes	: 36 bits physical, 32 bits virtual
+power management:
+
+cjdns@wl-4-253:~/cjdns$ git log | head -n 1
+commit 06522239acde31a01633033d9c4229baa7fad229
+
+
+
+
+
+
+
+
+$ ./cjdroute --bench
+These metrics are speed of encryption and decryption similar to the usage pattern
+when decrypting a packet, switching it, and re-encrypting it with another key.
+Test sending 1000 64 byte       hello packets.  packet auth enabled.    Finished in 334ms. 1532 Kb/s
+
+Test sending 1000 1500 byte     hello packets.  packet auth enabled.    Finished in 342ms. 35085 Kb/s
+
+Test sending 1000 64 byte       key packets.    packet auth enabled.    Finished in 547ms. 936 Kb/s
+
+Test sending 1000 1500 byte     key packets.    packet auth enabled.    Finished in 507ms. 23667 Kb/s
+
+Test sending 100000 64 byte     data packets.   packet auth disabled.   Finished in 51ms. 1003921 Kb/s
+
+Test sending 100000 1500 byte   data packets.   packet auth disabled.   Finished in 618ms. 1941747 Kb/s
+
+Test sending 100000 64 byte     data packets.   packet auth enabled.    Finished in 226ms. 226548 Kb/s
+
+This is the switch configuration so this indicates expected switch throughput:
+Test sending 100000 1500 byte   data packets.   packet auth enabled.    Finished in 1068ms. 1123595 Kb/s
+
+
+$ cat /proc/cpuinfo
+processor       : 0
+vendor_id       : GenuineIntel
+cpu family      : 6
+model           : 26
+model name      : Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz
+stepping        : 5
+microcode       : 0x11
+cpu MHz         : 2261.000
+cache size      : 8192 KB
+fpu             : yes
+fpu_exception   : yes
+cpuid level     : 11
+wp              : yes
+flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni ssse3 cx16 sse4_1 sse4_2 popcnt hypervisor lahf_lm ida dts
+bogomips        : 4522.00
+clflush size    : 64
+cache_alignment : 64
+address sizes   : 40 bits physical, 48 bits virtual
+power management:
+
+......
+
+$ git log | head -n 1
+commit 65204735fac8a27a1057f100b0a1285633eaf29e
+
+
+
+
+
+
+
+
+
+[user@ps3 build]$ ./cjdroute --bench
+These metrics are speed of encryption and decryption similar to the usage pattern
+when decrypting a packet, switching it, and re-encrypting it with another key.
+Test sending 1000 64 byte	hello packets.	packet auth enabled.	Finished in 54330ms. 9 Kb/s
+
+Test sending 1000 1500 byte	hello packets.	packet auth enabled.	Finished in 54805ms. 218 Kb/s
+
+Test sending 1000 64 byte	key packets.	packet auth enabled.	Finished in 54304ms. 9 Kb/s
+
+Test sending 1000 1500 byte	key packets.	packet auth enabled.	Finished in 54792ms. 218 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth disabled.	Finished in 607ms. 84349 Kb/s
+
+Test sending 100000 1500 byte	data packets.	packet auth disabled.	Finished in 8470ms. 141676 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth enabled.	Finished in 3224ms. 15880 Kb/s
+
+This is the switch configuration so this indicates expected switch throughput:
+Test sending 100000 1500 byte	data packets.	packet auth enabled.	Finished in 54903ms. 21856 Kb/s
+
+[user@ps3 build]$ cat /proc/cpuinfo
+processor	: 0
+cpu		: Cell Broadband Engine, altivec supported
+clock		: 3192.000000MHz
+revision	: 5.1 (pvr 0070 0501)
+
+processor	: 1
+cpu		: Cell Broadband Engine, altivec supported
+clock		: 3192.000000MHz
+revision	: 5.1 (pvr 0070 0501)
+
+timebase	: 79800000
+platform	: PS3
+[user@ps3 build]$ git log | head -n 1
+commit 06522239acde31a01633033d9c4229baa7fad229
+
+
+
+
+
+
+
+Linux 2.6.26-2-686 #1 SMP Sat Jun 11 14:54:10 UTC 2011 i686 GNU/Linux
+
+893ac7148b76bed44c589617f0655a857b05b9e4
+
+processor	: 0
+vendor_id	: GenuineIntel
+cpu family	: 6
+model		: 23
+model name	: Intel(R) Core(TM)2 CPU         E7400  @ 2.80GHz
+stepping	: 10
+cpu MHz		: 2793.090
+cache size	: 3072 KB
+physical id	: 0
+siblings	: 2
+core id		: 0
+cpu cores	: 2
+apicid		: 0
+initial apicid	: 0
+fdiv_bug	: no
+hlt_bug		: no
+f00f_bug	: no
+coma_bug	: no
+fpu		: yes
+fpu_exception	: yes
+cpuid level	: 13
+wp		: yes
+flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni monitor tm2 ssse3 lahf_lm
+bogomips	: 5590.46
+clflush size	: 64
+power management:
+
+processor	: 1
+vendor_id	: GenuineIntel
+cpu family	: 6
+model		: 23
+model name	: Intel(R) Core(TM)2 CPU         E7400  @ 2.80GHz
+stepping	: 10
+cpu MHz		: 2793.090
+cache size	: 3072 KB
+physical id	: 0
+siblings	: 2
+core id		: 1
+cpu cores	: 2
+apicid		: 1
+initial apicid	: 1
+fdiv_bug	: no
+hlt_bug		: no
+f00f_bug	: no
+coma_bug	: no
+fpu		: yes
+fpu_exception	: yes
+cpuid level	: 13
+wp		: yes
+flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni monitor tm2 ssse3 lahf_lm
+bogomips	: 5586.38
+clflush size	: 64
+power management:
+
+These metrics are speed of encryption and decryption similar to the usage pattern
+when decrypting a packet, switching it, and re-encrypting it with another key.
+Test sending 1000 64 byte	hello packets.	packet auth enabled.	Finished in 704ms. 727 Kb/s
+
+Test sending 1000 1500 byte	hello packets.	packet auth enabled.	Finished in 670ms. 17909 Kb/s
+
+Test sending 1000 64 byte	key packets.	packet auth enabled.	Finished in 700ms. 731 Kb/s
+
+Test sending 1000 1500 byte	key packets.	packet auth enabled.	Finished in 709ms. 16924 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth disabled.	Finished in 105ms. 487619 Kb/s
+
+Test sending 100000 1500 byte	data packets.	packet auth disabled.	Finished in 639ms. 1877934 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth enabled.	Finished in 316ms. 162025 Kb/s
+
+This is the switch configuration so this indicates expected switch throughput:
+Test sending 100000 1500 byte	data packets.	packet auth enabled.	Finished in 1159ms. 1035375 Kb/s
+
+
+
+
+
+
+
+
+OpenWRT on Linksys WRT54GL V1.1
+
+system type              : Broadcom BCM47XX
+processor             : 0
+cpu model             : Broadcom BMIPS3300 V0.8
+BogoMIPS              : 198.65
+wait instruction      : yes
+microsecond timers    : yes
+tlb_entries           : 32
+extra interrupt vector        : yes
+hardware watchpoint   : no
+ASEs implemented      :
+shadow register sets  : 1
+kscratch registers    : 0
+core                  : 0
+VCED exceptions               : not available
+VCEI exceptions               : not available
+
+These metrics are speed of encryption and decryption similar to the usage pattern
+when decrypting a packet, switching it, and re-encrypting it with another key.
+Test sending 1000 64 byte     hello packets.  packet auth enabled.    Finished in 687837ms. 0 Kb/s
+
+Test sending 1000 1500 byte   hello packets.  packet auth enabled.    Finished in 695086ms. 17 Kb/s
+
+Test sending 1000 64 byte     key packets.    packet auth enabled.    Finished in 688509ms. 0 Kb/s
+
+Test sending 1000 1500 byte   key packets.    packet auth enabled.    Finished in 695686ms. 17 Kb/s
+
+Test sending 100000 64 byte   data packets.   packet auth disabled.   Finished in 6485ms. 7895 Kb/s
+
+Test sending 100000 1500 byte data packets.   packet auth disabled.   Finished in 85105ms. 14100 Kb/s
+
+Test sending 100000 64 byte   data packets.   packet auth enabled.    Finished in 45765ms. 1118 Kb/s
+
+This is the switch configuration so this indicates expected switch throughput
+Test sending 100000 1500 byte data packets.   packet auth enabled.    Finished in 764380ms. 1569 Kb/s
+
+real  59m 43.33s
+user  59m 39.59s
+sys   0m 2.98s
+
+ircerr@EFNet/#cjdns 20120506
+
+
+
+
+
+
+
+
+user@debian-mips:~/cjdns/build$ time ./cjdroute --bench
+These metrics are speed of encryption and decryption similar to the usage pattern
+when decrypting a packet, switching it, and re-encrypting it with another key.
+Test sending 1000 64 byte	hello packets.	packet auth enabled.	Finished in 271027ms. 1 Kb/s
+
+Test sending 1000 1500 byte	hello packets.	packet auth enabled.	Finished in 314701ms. 38 Kb/s
+
+Test sending 1000 64 byte	key packets.	packet auth enabled.	Finished in 288595ms. 1 Kb/s
+
+Test sending 1000 1500 byte	key packets.	packet auth enabled.	Finished in 271643ms. 44 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth disabled.	Finished in 8016ms. 6387 Kb/s
+
+Test sending 100000 1500 byte	data packets.	packet auth disabled.	Finished in 63388ms. 18931 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth enabled.	Finished in 24010ms. 2132 Kb/s
+
+This is the switch configuration so this indicates expected switch throughput:
+Test sending 100000 1500 byte	data packets.	packet auth enabled.	Finished in 332790ms. 3605 Kb/s
+
+
+real	25m37.560s
+user	25m4.378s
+sys	0m29.726s
+user@debian-mips:~/cjdns/build$ cat /proc/cpuinfo
+system type		: MIPS Malta
+processor		: 0
+cpu model		: MIPS 24Kc V0.0  FPU V0.0
+BogoMIPS		: 532.48
+wait instruction	: yes
+microsecond timers	: yes
+tlb_entries		: 16
+extra interrupt vector	: yes
+hardware watchpoint	: yes, count: 1, address/irw mask: [0x0ff8]
+ASEs implemented	: mips16
+shadow register sets	: 1
+core			: 0
+VCED exceptions		: not available
+VCEI exceptions		: not available
+
+user@debian-mips:~/cjdns/build$ git log | head -n 1
+commit 929f4785dcd62b2dc4201ceb40e7bdb0d49462e5
+
+
+
+# after update to nacl
+
+git log | head -1~/cjdns$ time ./build/cjdroute --bench && cat /proc/cpuinfo &&  
+These metrics are speed of encryption and decryption similar to the usage pattern
+when decrypting a packet, switching it, and re-encrypting it with another key.
+Test sending 1000 64 byte	hello packets.	packet auth enabled.	Finished in 242437ms. 2 Kb/s
+
+Test sending 1000 1500 byte	hello packets.	packet auth enabled.	Finished in 298387ms. 40 Kb/s
+
+Test sending 1000 64 byte	key packets.	packet auth enabled.	Finished in 325285ms. 1 Kb/s
+
+Test sending 1000 1500 byte	key packets.	packet auth enabled.	Finished in 300940ms. 39 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth disabled.	Finished in 3183ms. 16085 Kb/s
+
+Test sending 100000 1500 byte	data packets.	packet auth disabled.	Finished in 70822ms. 16943 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth enabled.	Finished in 21674ms. 2362 Kb/s
+
+This is the switch configuration so this indicates expected switch throughput:
+Test sending 100000 1500 byte	data packets.	packet auth enabled.	Finished in 122875ms. 9766 Kb/s
+
+
+real	22m33.470s
+user	22m2.123s
+sys	0m28.946s
+system type		: MIPS Malta
+processor		: 0
+cpu model		: MIPS 24Kc V0.0  FPU V0.0
+BogoMIPS		: 550.91
+wait instruction	: yes
+microsecond timers	: yes
+tlb_entries		: 16
+extra interrupt vector	: yes
+hardware watchpoint	: yes, count: 1, address/irw mask: [0x0ff8]
+ASEs implemented	: mips16
+shadow register sets	: 1
+core			: 0
+VCED exceptions		: not available
+VCEI exceptions		: not available
+
+commit 8562e4298a64a7b7aa9d05d03ab357b572940b71
+user@debian-mips:~/cjdns$ 
+
+
+
+
+
+
+
+
+
+commit 51c041d6b87f139e74ab31ca125cdfc9685900b4
+Linux sql.bt-chat.com 2.6.26-2-686 #1 SMP Sat Jun 11 14:54:10 UTC 2011 i686 GNU/Linux
+processor	: 0
+vendor_id	: GenuineIntel
+cpu family	: 6
+model		: 23
+model name	: Intel(R) Core(TM)2 Duo CPU     E7400  @ 2.80GHz
+stepping	: 10
+cpu MHz		: 2786.096
+cache size	: 3072 KB
+physical id	: 0
+siblings	: 2
+core id		: 0
+cpu cores	: 2
+apicid		: 0
+initial apicid	: 0
+fdiv_bug	: no
+hlt_bug		: no
+f00f_bug	: no
+coma_bug	: no
+fpu		: yes
+fpu_exception	: yes
+cpuid level	: 13
+wp		: yes
+flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm
+bogomips	: 5576.40
+clflush size	: 64
+power management:
+
+processor	: 1
+vendor_id	: GenuineIntel
+cpu family	: 6
+model		: 23
+model name	: Intel(R) Core(TM)2 Duo CPU     E7400  @ 2.80GHz
+stepping	: 10
+cpu MHz		: 2786.096
+cache size	: 3072 KB
+physical id	: 0
+siblings	: 2
+core id		: 1
+cpu cores	: 2
+apicid		: 1
+initial apicid	: 1
+fdiv_bug	: no
+hlt_bug		: no
+f00f_bug	: no
+coma_bug	: no
+fpu		: yes
+fpu_exception	: yes
+cpuid level	: 13
+wp		: yes
+flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm
+bogomips	: 5572.35
+clflush size	: 64
+power management:
+
+These metrics are speed of encryption and decryption similar to the usage pattern
+when decrypting a packet, switching it, and re-encrypting it with another key.
+Test sending 1000 64 byte	hello packets.	packet auth enabled.	Finished in 650ms. 787 Kb/s
+
+Test sending 1000 1500 byte	hello packets.	packet auth enabled.	Finished in 706ms. 16996 Kb/s
+
+Test sending 1000 64 byte	key packets.	packet auth enabled.	Finished in 698ms. 733 Kb/s
+
+Test sending 1000 1500 byte	key packets.	packet auth enabled.	Finished in 663ms. 18098 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth disabled.	Finished in 101ms. 506930 Kb/s
+
+Test sending 100000 1500 byte	data packets.	packet auth disabled.	Finished in 633ms. 1895734 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth enabled.	Finished in 310ms. 165161 Kb/s
+
+This is the switch configuration so this indicates expected switch throughput:
+Test sending 100000 1500 byte	data packets.	packet auth enabled.	Finished in 1155ms. 1038961 Kb/s
+
+
+
+
+
+
+
+
+
+
+commit a33af261e9ddbcd314ea28190b18b4a438af3532
+Linux web.bt-chat.com 2.6.32-5-686 #1 SMP Mon Mar 26 05:20:33 UTC 2012 i686 GNU/Linux
+processor	: 0
+vendor_id	: GenuineIntel
+cpu family	: 6
+model		: 23
+model name	: Intel(R) Core(TM)2 CPU         E7400  @ 2.80GHz
+stepping	: 10
+cpu MHz		: 2793.605
+cache size	: 3072 KB
+physical id	: 0
+siblings	: 2
+core id		: 0
+cpu cores	: 2
+apicid		: 0
+initial apicid	: 0
+fdiv_bug	: no
+hlt_bug		: no
+f00f_bug	: no
+coma_bug	: no
+fpu		: yes
+fpu_exception	: yes
+cpuid level	: 13
+wp		: yes
+flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni monitor tm2 ssse3 lahf_lm
+bogomips	: 5587.21
+clflush size	: 64
+cache_alignment	: 64
+address sizes	: 36 bits physical, 48 bits virtual
+power management:
+
+processor	: 1
+vendor_id	: GenuineIntel
+cpu family	: 6
+model		: 23
+model name	: Intel(R) Core(TM)2 CPU         E7400  @ 2.80GHz
+stepping	: 10
+cpu MHz		: 2793.605
+cache size	: 3072 KB
+physical id	: 0
+siblings	: 2
+core id		: 1
+cpu cores	: 2
+apicid		: 1
+initial apicid	: 1
+fdiv_bug	: no
+hlt_bug		: no
+f00f_bug	: no
+coma_bug	: no
+fpu		: yes
+fpu_exception	: yes
+cpuid level	: 13
+wp		: yes
+flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni monitor tm2 ssse3 lahf_lm
+bogomips	: 5586.37
+clflush size	: 64
+cache_alignment	: 64
+address sizes	: 36 bits physical, 48 bits virtual
+power management:
+
+These metrics are speed of encryption and decryption similar to the usage pattern
+when decrypting a packet, switching it, and re-encrypting it with another key.
+Test sending 1000 64 byte	hello packets.	packet auth enabled.	Finished in 701ms. 730 Kb/s
+
+Test sending 1000 1500 byte	hello packets.	packet auth enabled.	Finished in 660ms. 18180 Kb/s
+
+Test sending 1000 64 byte	key packets.	packet auth enabled.	Finished in 700ms. 731 Kb/s
+
+Test sending 1000 1500 byte	key packets.	packet auth enabled.	Finished in 707ms. 16972 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth disabled.	Finished in 101ms. 506930 Kb/s
+
+Test sending 100000 1500 byte	data packets.	packet auth disabled.	Finished in 587ms. 2044293 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth enabled.	Finished in 365ms. 140273 Kb/s
+
+This is the switch configuration so this indicates expected switch throughput:
+Test sending 100000 1500 byte	data packets.	packet auth enabled.	Finished in 1156ms. 1038062 Kb/s
+
+
+
+
+
+
+
+
+
+
+
+commit ec8d1aac3e11e98b21e0bea6ad4af2463c99b14c
+Linux web2.bt-chat.com 2.6.26-2-686 #1 SMP Sat Jun 11 14:54:10 UTC 2011 i686 GNU/Linux
+processor	: 0
+vendor_id	: GenuineIntel
+cpu family	: 6
+model		: 23
+model name	: Intel(R) Core(TM)2 Duo CPU     E7400  @ 2.80GHz
+stepping	: 10
+cpu MHz		: 2786.045
+cache size	: 3072 KB
+physical id	: 0
+siblings	: 2
+core id		: 0
+cpu cores	: 2
+apicid		: 0
+initial apicid	: 0
+fdiv_bug	: no
+hlt_bug		: no
+f00f_bug	: no
+coma_bug	: no
+fpu		: yes
+fpu_exception	: yes
+cpuid level	: 13
+wp		: yes
+flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm
+bogomips	: 5576.37
+clflush size	: 64
+power management:
+
+processor	: 1
+vendor_id	: GenuineIntel
+cpu family	: 6
+model		: 23
+model name	: Intel(R) Core(TM)2 Duo CPU     E7400  @ 2.80GHz
+stepping	: 10
+cpu MHz		: 2786.045
+cache size	: 3072 KB
+physical id	: 0
+siblings	: 2
+core id		: 1
+cpu cores	: 2
+apicid		: 1
+initial apicid	: 1
+fdiv_bug	: no
+hlt_bug		: no
+f00f_bug	: no
+coma_bug	: no
+fpu		: yes
+fpu_exception	: yes
+cpuid level	: 13
+wp		: yes
+flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm
+bogomips	: 5572.35
+clflush size	: 64
+power management:
+
+These metrics are speed of encryption and decryption similar to the usage pattern
+when decrypting a packet, switching it, and re-encrypting it with another key.
+Test sending 1000 64 byte	hello packets.	packet auth enabled.	Finished in 698ms. 733 Kb/s
+
+Test sending 1000 1500 byte	hello packets.	packet auth enabled.	Finished in 705ms. 17020 Kb/s
+
+Test sending 1000 64 byte	key packets.	packet auth enabled.	Finished in 659ms. 776 Kb/s
+
+Test sending 1000 1500 byte	key packets.	packet auth enabled.	Finished in 706ms. 16996 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth disabled.	Finished in 72ms. 711111 Kb/s
+
+Test sending 100000 1500 byte	data packets.	packet auth disabled.	Finished in 610ms. 1967213 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth enabled.	Finished in 282ms. 181560 Kb/s
+
+This is the switch configuration so this indicates expected switch throughput:
+Test sending 100000 1500 byte	data packets.	packet auth enabled.	Finished in 1127ms. 1064773 Kb/s
+
+
+
+
+
+
+
+# Rasberry Pi -- Owner unknown (we would like to meet you!)
+
+./cjdroute --bench
+These metrics are speed of encryption and decryption similar to the usage pattern
+when decrypting a packet, switching it, and re-encrypting it with another key.
+Test sending 1000 64 byte	hello packets.	packet auth enabled.	Finished in 97759ms. 5 Kb/s
+
+Test sending 1000 1500 byte	hello packets.	packet auth enabled.	Finished in 96319ms. 124 Kb/s
+
+Test sending 1000 64 byte	key packets.	packet auth enabled.	Finished in 143077ms. 3 Kb/s
+
+Test sending 1000 1500 byte	key packets.	packet auth enabled.	Finished in 148158ms. 80 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth disabled.	Finished in 2172ms. 23572 Kb/s
+
+Test sending 100000 1500 byte	data packets.	packet auth disabled.	Finished in 33251ms. 36089 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth enabled.	Finished in 14356ms. 3566 Kb/s
+
+This is the switch configuration so this indicates expected switch throughput:
+Test sending 100000 1500 byte	data packets.	packet auth enabled.	Finished in 163744ms. 7328 Kb/s
+
+version: bc41a54dc5d2a0ece5864671242184afbd46ba6e
+
+# This version is just post the NACL improvements.
+
+
+
+
+
+
+
+
+[root@Bifrost] ~/src/cjdns# ./cjdroute --bench
+These metrics are speed of encryption and decryption similar to the usage pattern
+when decrypting a packet, switching it, and re-encrypting it with another key.
+Test sending 1000 64 byte       hello packets.  packet auth enabled.    Finished in 20195ms. 25 Kb/s
+
+Test sending 1000 1500 byte     hello packets.  packet auth enabled.    Finished in 20389ms. 588 Kb/s
+
+Test sending 1000 64 byte       key packets.    packet auth enabled.    Finished in 20077ms. 25 Kb/s
+
+Test sending 1000 1500 byte     key packets.    packet auth enabled.    Finished in 20296ms. 591 Kb/s
+
+Test sending 100000 64 byte     data packets.   packet auth disabled.   Finished in 500ms. 102400 Kb/s
+
+Test sending 100000 1500 byte   data packets.   packet auth disabled.   Finished in 8314ms. 144334 Kb/s
+
+Test sending 100000 64 byte     data packets.   packet auth enabled.    Finished in 1502ms. 34087 Kb/s
+
+This is the switch configuration so this indicates expected switch throughput:
+Test sending 100000 1500 byte   data packets.   packet auth enabled.    Finished in 17730ms. 67681 Kb/s
+
+[root@Bifrost] ~/src/cjdns# cat /proc/cpuinfo
+processor       : 0
+cpu             : Cell Broadband Engine, altivec supported
+clock           : 3192.000000MHz
+revision        : 5.1 (pvr 0070 0501)
+
+processor       : 1
+cpu             : Cell Broadband Engine, altivec supported
+clock           : 3192.000000MHz
+revision        : 5.1 (pvr 0070 0501)
+
+timebase        : 79800000
+platform        : PS3
+model           : SonyPS3
+[root@Bifrost] ~/src/cjdns# git log | head -n 1
+commit 829f93e93c1eff81fdde62f00500f7e2c6e05c2f
+[root@Bifrost] ~/src/cjdns# date
+Fri Jun 22 15:48:05 CDT 2012
+
+
+
+
+
+
+[dan@archbang ~]$ cjdroute --bench
+These metrics are speed of encryption and decryption similar to the usage pattern
+when decrypting a packet, switching it, and re-encrypting it with another key.
+Test sending 1000 64 byte	hello packets.	packet auth enabled.	Finished in 614ms. 833 Kb/s
+
+Test sending 1000 1500 byte	hello packets.	packet auth enabled.	Finished in 671ms. 17882 Kb/s
+
+Test sending 1000 64 byte	key packets.	packet auth enabled.	Finished in 962ms. 532 Kb/s
+
+Test sending 1000 1500 byte	key packets.	packet auth enabled.	Finished in 975ms. 12306 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth disabled.	Finished in 296ms. 172972 Kb/s
+
+Test sending 100000 1500 byte	data packets.	packet auth disabled.	Finished in 1040ms. 1153846 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth enabled.	Finished in 626ms. 81789 Kb/s
+
+This is the switch configuration so this indicates expected switch throughput:
+Test sending 100000 1500 byte	data packets.	packet auth enabled.	Finished in 1745ms. 687679 Kb/s
+
+[dan@archbang ~]$ cat /proc/cpuinfo
+processor	: 0
+vendor_id	: GenuineIntel
+cpu family	: 6
+model		: 15
+model name	: Intel(R) Pentium(R) Dual  CPU  T3200  @ 2.00GHz
+stepping	: 13
+microcode	: 0xa3
+cpu MHz		: 1000.000
+cache size	: 1024 KB
+physical id	: 0
+siblings	: 2
+core id		: 0
+cpu cores	: 2
+apicid		: 0
+initial apicid	: 0
+fdiv_bug	: no
+hlt_bug		: no
+f00f_bug	: no
+coma_bug	: no
+fpu		: yes
+fpu_exception	: yes
+cpuid level	: 10
+wp		: yes
+flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm lahf_lm dts
+bogomips	: 3991.79
+clflush size	: 64
+cache_alignment	: 64
+address sizes	: 36 bits physical, 48 bits virtual
+power management:
+
+processor	: 1
+vendor_id	: GenuineIntel
+cpu family	: 6
+model		: 15
+model name	: Intel(R) Pentium(R) Dual  CPU  T3200  @ 2.00GHz
+stepping	: 13
+microcode	: 0xa3
+cpu MHz		: 1000.000
+cache size	: 1024 KB
+physical id	: 0
+siblings	: 2
+core id		: 1
+cpu cores	: 2
+apicid		: 1
+initial apicid	: 1
+fdiv_bug	: no
+hlt_bug		: no
+f00f_bug	: no
+coma_bug	: no
+fpu		: yes
+fpu_exception	: yes
+cpuid level	: 10
+wp		: yes
+flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm lahf_lm dts
+bogomips	: 3991.79
+clflush size	: 64
+cache_alignment	: 64
+address sizes	: 36 bits physical, 48 bits virtual
+power management:
+
+[dan@archbang ~]$ yaourt -Q cjdns-git
+local/cjdns-git 120619-1
+packaged (6-19-2012)
+
+
+
+
+
+# Another Rasberry Pi
+[cjdns@meLonpi] ~/cjdns$ ./cjdroute --bench
+These metrics are speed of encryption and decryption similar to the usage pattern
+when decrypting a packet, switching it, and re-encrypting it with another key.
+Test sending 1000 64 byte       hello packets.  packet auth enabled.    Finished in 111492ms. 4 Kb/s
+
+Test sending 1000 1500 byte     hello packets.  packet auth enabled.    Finished in 112808ms. 106 Kb/s
+
+Test sending 1000 64 byte       key packets.    packet auth enabled.    Finished in 111424ms. 4 Kb/s
+
+Test sending 1000 1500 byte     key packets.    packet auth enabled.    Finished in 113002ms. 106 Kb/s
+
+Test sending 100000 64 byte     data packets.   packet auth disabled.   Finished in 5692ms. 8995 Kb/s
+
+Test sending 100000 1500 byte   data packets.   packet auth disabled.   Finished in 117375ms. 10223 Kb/s
+
+Test sending 100000 64 byte     data packets.   packet auth enabled.    Finished in 23037ms. 2222 Kb/s
+
+This is the switch configuration so this indicates expected switch throughput:
+Test sending 100000 1500 byte   data packets.   packet auth enabled.    Finished in 162951ms. 7364 Kb/s
+
+[cjdns@meLonpi] ~/cjdns$ uname -a
+Linux meLonpi 3.1.9+ #90 Wed Apr 18 18:23:05 BST 2012 armv6l GNU/Linux
+
+[cjdns@meLonpi] ~/cjdns$ cat /proc/cpuinfo
+Processor       : ARMv6-compatible processor rev 7 (v6l)
+BogoMIPS        : 697.95
+Features        : swp half thumb fastmult vfp edsp java tls 
+CPU implementer : 0x41
+CPU architecture: 7
+CPU variant     : 0x0
+CPU part        : 0xb76
+CPU revision    : 7
+
+Hardware        : BCM2708
+Revision        : 0002
+Serial          : 000000008b285506
+
+[cjdns@meLonpi] ~/cjdns$ git log | head -1
+commit a7c6c3a02c96ff5bfc12aa110af5a594c08a605b
+
+
+
+
+
+
+
+
+
+[ich@ich cjdns]$ ./cjdroute --bench
+These metrics are speed of encryption and decryption similar to the usage pattern
+when decrypting a packet, switching it, and re-encrypting it with another key.
+Test sending 1000 64 byte	hello packets.	packet auth enabled.	Finished in 1384ms. 369 Kb/s
+
+Test sending 1000 1500 byte	hello packets.	packet auth enabled.	Finished in 1332ms. 9008 Kb/s
+
+Test sending 1000 64 byte	key packets.	packet auth enabled.	Finished in 1331ms. 384 Kb/s
+
+Test sending 1000 1500 byte	key packets.	packet auth enabled.	Finished in 1382ms. 8682 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth disabled.	Finished in 60ms. 853333 Kb/s
+
+Test sending 100000 1500 byte	data packets.	packet auth disabled.	Finished in 545ms. 2201834 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth enabled.	Finished in 602ms. 85049 Kb/s
+
+This is the switch configuration so this indicates expected switch throughput:
+Test sending 100000 1500 byte	data packets.	packet auth enabled.	Finished in 1297ms. 925212 Kb/s
+
+[ich@ich cjdns]$ cat /proc/cpuinfo 
+processor	: 0
+vendor_id	: AuthenticAMD
+cpu family	: 16
+model		: 10
+model name	: AMD Phenom(tm) II X6 1090T Processor
+stepping	: 0
+microcode	: 0x10000dc
+cpu MHz		: 800.000
+cache size	: 512 KB
+physical id	: 0
+siblings	: 6
+core id		: 0
+cpu cores	: 6
+apicid		: 0
+initial apicid	: 0
+fpu		: yes
+fpu_exception	: yes
+cpuid level	: 6
+wp		: yes
+flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt nodeid_msr cpb hw_pstate npt lbrv svm_lock nrip_save pausefilter
+bogomips	: 6386.36
+TLB size	: 1024 4K pages
+clflush size	: 64
+cache_alignment	: 64
+address sizes	: 48 bits physical, 48 bits virtual
+power management: ts ttp tm stc 100mhzsteps hwpstate cpb
+
+processor	: 1
+vendor_id	: AuthenticAMD
+cpu family	: 16
+model		: 10
+model name	: AMD Phenom(tm) II X6 1090T Processor
+stepping	: 0
+microcode	: 0x10000dc
+cpu MHz		: 800.000
+cache size	: 512 KB
+physical id	: 0
+siblings	: 6
+core id		: 1
+cpu cores	: 6
+apicid		: 1
+initial apicid	: 1
+fpu		: yes
+fpu_exception	: yes
+cpuid level	: 6
+wp		: yes
+flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt nodeid_msr cpb hw_pstate npt lbrv svm_lock nrip_save pausefilter
+bogomips	: 6386.36
+TLB size	: 1024 4K pages
+clflush size	: 64
+cache_alignment	: 64
+address sizes	: 48 bits physical, 48 bits virtual
+power management: ts ttp tm stc 100mhzsteps hwpstate cpb
+
+processor	: 2
+vendor_id	: AuthenticAMD
+cpu family	: 16
+model		: 10
+model name	: AMD Phenom(tm) II X6 1090T Processor
+stepping	: 0
+microcode	: 0x10000dc
+cpu MHz		: 800.000
+cache size	: 512 KB
+physical id	: 0
+siblings	: 6
+core id		: 2
+cpu cores	: 6
+apicid		: 2
+initial apicid	: 2
+fpu		: yes
+fpu_exception	: yes
+cpuid level	: 6
+wp		: yes
+flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt nodeid_msr cpb hw_pstate npt lbrv svm_lock nrip_save pausefilter
+bogomips	: 6386.36
+TLB size	: 1024 4K pages
+clflush size	: 64
+cache_alignment	: 64
+address sizes	: 48 bits physical, 48 bits virtual
+power management: ts ttp tm stc 100mhzsteps hwpstate cpb
+
+processor	: 3
+vendor_id	: AuthenticAMD
+cpu family	: 16
+model		: 10
+model name	: AMD Phenom(tm) II X6 1090T Processor
+stepping	: 0
+microcode	: 0x10000dc
+cpu MHz		: 800.000
+cache size	: 512 KB
+physical id	: 0
+siblings	: 6
+core id		: 3
+cpu cores	: 6
+apicid		: 3
+initial apicid	: 3
+fpu		: yes
+fpu_exception	: yes
+cpuid level	: 6
+wp		: yes
+flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt nodeid_msr cpb hw_pstate npt lbrv svm_lock nrip_save pausefilter
+bogomips	: 6386.36
+TLB size	: 1024 4K pages
+clflush size	: 64
+cache_alignment	: 64
+address sizes	: 48 bits physical, 48 bits virtual
+power management: ts ttp tm stc 100mhzsteps hwpstate cpb
+
+processor	: 4
+vendor_id	: AuthenticAMD
+cpu family	: 16
+model		: 10
+model name	: AMD Phenom(tm) II X6 1090T Processor
+stepping	: 0
+microcode	: 0x10000dc
+cpu MHz		: 800.000
+cache size	: 512 KB
+physical id	: 0
+siblings	: 6
+core id		: 4
+cpu cores	: 6
+apicid		: 4
+initial apicid	: 4
+fpu		: yes
+fpu_exception	: yes
+cpuid level	: 6
+wp		: yes
+flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt nodeid_msr cpb hw_pstate npt lbrv svm_lock nrip_save pausefilter
+bogomips	: 6386.36
+TLB size	: 1024 4K pages
+clflush size	: 64
+cache_alignment	: 64
+address sizes	: 48 bits physical, 48 bits virtual
+power management: ts ttp tm stc 100mhzsteps hwpstate cpb
+
+processor	: 5
+vendor_id	: AuthenticAMD
+cpu family	: 16
+model		: 10
+model name	: AMD Phenom(tm) II X6 1090T Processor
+stepping	: 0
+microcode	: 0x10000dc
+cpu MHz		: 3200.000
+cache size	: 512 KB
+physical id	: 0
+siblings	: 6
+core id		: 5
+cpu cores	: 6
+apicid		: 5
+initial apicid	: 5
+fpu		: yes
+fpu_exception	: yes
+cpuid level	: 6
+wp		: yes
+flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt nodeid_msr cpb hw_pstate npt lbrv svm_lock nrip_save pausefilter
+bogomips	: 6386.36
+TLB size	: 1024 4K pages
+clflush size	: 64
+cache_alignment	: 64
+address sizes	: 48 bits physical, 48 bits virtual
+power management: ts ttp tm stc 100mhzsteps hwpstate cpb
+
+[ich@ich cjdns]$ git log -n 1
+commit c9cc5fe5f54b89f014d832527aef767f24a5b4da
+Author: Caleb James DeLisle <calebdelisle@lavabit.com>
+Date:   Mon Oct 22 01:31:51 2012 -0400
+
+21 Dec 2012:
+
+Hardware:
+
+    Hardware Overview:
+
+      Model Name: Mac mini
+      Model Identifier: Macmini1,1
+      Processor Name: Intel Core Solo
+      Processor Speed: 1,5 GHz
+      Number Of Processors: 1
+      Total Number Of Cores: 1
+      L2 Cache: 2 MB
+      Memory: 2 GB
+      Bus Speed: 667 MHz
+      Boot ROM Version: MM11.0055.B08
+      SMC Version (system): 1.3f4
+
+
+$ uname -a 
+Darwin Gaius.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
+
+$ ./cjdroute --bench
+These metrics are speed of encryption and decryption similar to the usage pattern
+when decrypting a packet, switching it, and re-encrypting it with another key.
+
+
+
+Test sending 1000 64 byte  hello packets.	packet auth enabled.	Finished in 58425ms. 8 Kb/s
+
+Test sending 1000 1500 byte	hello packets.	packet auth enabled.	Finished in 63471ms. 189 Kb/s
+
+Test sending 1000 64 byte	key packets.	packet auth enabled.	Finished in 84541ms. 6 Kb/s
+
+Test sending 1000 1500 byte	key packets.	packet auth enabled.	Finished in 83907ms. 143 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth disabled.	Finished in 343ms. 149271 Kb/s
+
+Test sending 100000 1500 byte	data packets.	packet auth disabled.	Finished in 2993ms. 400935 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth enabled.	Finished in 3973ms. 12886 Kb/s
+
+This is the switch configuration so this indicates expected switch throughput:
+Test sending 100000 1500 byte	data packets.	packet auth enabled.	Finished in 12433ms. 96517 Kb/s
+
+
+$ gcc -v
+Using built-in specs.
+Target: i686-apple-darwin10
+Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.1~3/src/configure --disable-checking --enable-werror --prefix=/Developer/usr/llvm-gcc-4.2 --mandir=/Developer/usr/llvm-gcc-4.2/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.1~3/dst-llvmCore/Developer/usr/local --with-gxx-include-dir=/usr/include/c++/4.2.1 --host=i686-apple-darwin10 --target=i686-apple-darwin10
+Thread model: posix
+gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)
+
+$  git log | head -1
+commit e6fda6a418f5e719fe07cf0c866e546288de6cb1
+
+
+
+
+
+user@debian-mips:~/cjdns$ ./cjdroute --bench
+1380772514 INFO RandomSeed.c:67 Attempting to seed random number generator
+1380772514 INFO RandomSeed.c:81 Trying random seed [RtlGenRandom() (Windows)] Failed
+1380772514 INFO RandomSeed.c:81 Trying random seed [sysctl(KERN_ARND) (BSD)] Failed
+1380772514 INFO RandomSeed.c:75 Trying random seed [/dev/urandom] Success
+1380772514 INFO RandomSeed.c:75 Trying random seed [sysctl(RANDOM_UUID) (Linux)] Success
+1380772514 INFO RandomSeed.c:75 Trying random seed [/proc/sys/kernel/random/uuid (Linux)] Success
+1380772514 INFO RandomSeed.c:89 Seeding random number generator succeeded with [3] sources
+These metrics are speed of encryption and decryption similar to the usage pattern
+when decrypting a packet, switching it, and re-encrypting it with another key.
+Test sending 1000 64 byte	hello packets.	packet auth enabled.	Finished in 79280ms. 6 Kb/s
+
+Test sending 1000 1500 byte	hello packets.	packet auth enabled.	Finished in 82869ms. 144 Kb/s
+
+Test sending 1000 64 byte	key packets.	packet auth enabled.	Finished in 110807ms. 4 Kb/s
+
+Test sending 1000 1500 byte	key packets.	packet auth enabled.	Finished in 138062ms. 86 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth disabled.	Finished in 4345ms. 11783 Kb/s
+
+Test sending 100000 1500 byte	data packets.	packet auth disabled.	Finished in 53083ms. 22606 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth enabled.	Finished in 17659ms. 2899 Kb/s
+
+This is the switch configuration so this indicates expected switch throughput:
+Test sending 100000 1500 byte	data packets.	packet auth enabled.	Finished in 91680ms. 13089 Kb/s
+
+user@debian-mips:~/cjdns$ git log -n 1
+commit 9a3db93cd3ea5b3583ecc3b741518dd0e6ec8764
+Author: Caleb James DeLisle <cjd@hyperboria.ca>
+Date:   Wed Oct 2 22:07:13 2013 -0400
+
+    Sometimes SearchRunner_search() returns null
+user@debian-mips:~/cjdns$ cat /proc/cpuinfo 
+system type		: MIPS Malta
+processor		: 0
+cpu model		: MIPS 24Kc V0.0  FPU V0.0
+BogoMIPS		: 561.15
+wait instruction	: yes
+microsecond timers	: yes
+tlb_entries		: 16
+extra interrupt vector	: yes
+hardware watchpoint	: yes, count: 1, address/irw mask: [0x0ff8]
+ASEs implemented	: mips16
+shadow register sets	: 1
+core			: 0
+VCED exceptions		: not available
+VCEI exceptions		: not available
+
+user@debian-mips:~/cjdns$ 
+
+
+
+
+
+
+
+
+linaro@linaro-ubuntu-desktop:~/cjdns/cjdns-master$ ./cjdroute --bench ; cat /proc/cpuinfo 
+3711 INFO RandomSeed.c:67 Attempting to seed random number generator
+3711 INFO RandomSeed.c:81 Trying random seed [RtlGenRandom() (Windows)] Failed
+3711 INFO RandomSeed.c:81 Trying random seed [sysctl(KERN_ARND) (BSD)] Failed
+3711 INFO RandomSeed.c:75 Trying random seed [/dev/urandom] Success
+3711 INFO RandomSeed.c:75 Trying random seed [sysctl(RANDOM_UUID) (Linux)] Success
+3711 INFO RandomSeed.c:75 Trying random seed [/proc/sys/kernel/random/uuid (Linux)] Success
+3711 INFO RandomSeed.c:89 Seeding random number generator succeeded with [3] sources
+These metrics are speed of encryption and decryption similar to the usage pattern
+when decrypting a packet, switching it, and re-encrypting it with another key.
+Test sending 1000 64 byte	hello packets.	packet auth enabled.	Finished in 1273ms. 402 Kb/s
+
+Test sending 1000 1500 byte	hello packets.	packet auth enabled.	Finished in 1306ms. 9187 Kb/s
+
+Test sending 1000 64 byte	key packets.	packet auth enabled.	Finished in 1843ms. 277 Kb/s
+
+Test sending 1000 1500 byte	key packets.	packet auth enabled.	Finished in 1876ms. 6396 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth disabled.	Finished in 275ms. 186181 Kb/s
+
+Test sending 100000 1500 byte	data packets.	packet auth disabled.	Finished in 2816ms. 426136 Kb/s
+
+Test sending 100000 64 byte	data packets.	packet auth enabled.	Finished in 1349ms. 37954 Kb/s
+
+This is the switch configuration so this indicates expected switch throughput:
+Test sending 100000 1500 byte	data packets.	packet auth enabled.	Finished in 4589ms. 261494 Kb/s
+
+Processor	: ARMv7 Processor rev 10 (v7l)
+processor	: 0
+BogoMIPS	: 1988.28
+
+processor	: 1
+BogoMIPS	: 1988.28
+
+processor	: 2
+BogoMIPS	: 1988.28
+
+processor	: 3
+BogoMIPS	: 1988.28
+
+Features	: swp half thumb fastmult vfp edsp neon vfpv3 
+CPU implementer	: 0x41
+CPU architecture: 7
+CPU variant	: 0x2
+CPU part	: 0xc09
+CPU revision	: 10
+
+Hardware	: Freescale i.MX 6Quad Sabre-Lite Board
+Revision	: 63000
+Serial		: 0000000000000000
+linaro@linaro-ubuntu-desktop:~/cjdns/cjdns-master$ uname -a
+Linux linaro-ubuntu-desktop 3.0.35-troosh #17 SMP PREEMPT Tue May 7 20:29:00 MSK 2013 armv7l armv7l armv7l GNU/Linux
+linaro@linaro-ubuntu-desktop:~/cjdns/cjdns-master$ gcc --version
+gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
+Copyright (C) 2011 Free Software Foundation, Inc.
+This is free software; see the source for copying conditions.  There is NO
+warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+
+linaro@linaro-ubuntu-desktop:~/cjdns/cjdns-master$$ git log | head -1
+commit 9a3db93cd3ea5b3583ecc3b741518dd0e6ec8764
+
+
+
+
+
+
+
+
+
+here you have a new benchmark. It's this cheap ADSL router:
+http://wiki.openwrt.org/toh/comtrend/ar5387un
+
+The cjdns code is as e9bcb0f9f06870d6f4904149e1c15eca09c7ed8a
+(That's mentioned in the meshbox thing I used in openwrt to build it:
+https://github.com/SeattleMeshnet/meshbox/blob/master/cjdns/Makefile )
+
+The results (better than my 1.2GHz ARM Sheevaplug!):
+-------------------
+1412636955 INFO RandomSeed.c:42 Attempting to seed random number generator
+1412636955 INFO RandomSeed.c:50 Trying random seed [/dev/urandom] Success
+1412636955 INFO RandomSeed.c:56 Trying random seed [sysctl(RANDOM_UUID) (Linux)] Failed
+1412636955 INFO RandomSeed.c:50 Trying random seed [/proc/sys/kernel/random/uuid (Linux)] Success
+1412636955 INFO RandomSeed.c:64 Seeding random number generator succeeded with [2] sources
+These metrics are speed of encryption and decryption similar to the usage pattern
+when decrypting a packet, switching it, and re-encrypting it with another key.
+Test sending 1000 64 byte       hello packets
+        Finished in 10645ms. 48 Kb/s
+
+Test sending 1000 1500 byte     hello packets
+        Finished in 11206ms. 1070 Kb/s
+
+Test sending 1000 64 byte       key packets
+        Finished in 10600ms. 48 Kb/s
+
+Test sending 1000 1500 byte     key packets
+        Finished in 11243ms. 1067 Kb/s
+
+Test sending 100000 64 byte     data packets
+        Finished in 9632ms. 5315 Kb/s
+
+This is the switch configuration so this indicates expected switch throughput:
+Test sending 100000 1500 byte   data packets
+        Finished in 70792ms. 16951 Kb/s
+
+                                                             
+/proc/cpuinfo:                                               
+system type             : bcm63xx/96328A-1441N1 (0x6328/0xB0)
+machine                 : Comtrend AR-5387un     
+processor               : 0                      
+cpu model               : Broadcom BMIPS4350 V7.5
+BogoMIPS                : 319.74
+wait instruction        : yes
+microsecond timers      : yes
+tlb_entries             : 32 
+extra interrupt vector  : yes                 
+hardware watchpoint     : no                  
+isa                     : mips1 mips2 mips32r1
+ASEs implemented        :  
+shadow register sets    : 1
+kscratch registers      : 0            
+core                    : 0            
+VCED exceptions         : not available
+VCEI exceptions         : not available
+-------------------
+
+
+
+Raspberry PI 2 Model B
+--------------------------------
+(same results with and without NEON (CFLAGS=-mfpu=neon))
+
+/proc/cpuinfo:  (quadcore, four times this)
+processor       : 0
+model name      : ARMv7 Processor rev 5 (v7l)
+BogoMIPS        : 38.40
+Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
+vfpd32 lpae evtstrm 
+CPU implementer : 0x41
+CPU architecture: 7
+CPU variant     : 0x0
+CPU part        : 0xc07
+CPU revision    : 5
+
+
+Benchmark (gcc 4.6, CFLAGS="-march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=hard"):
+These metrics are speed of encryption and decryption similar to the usage pattern
+when decrypting a packet, switching it, and re-encrypting it with another key.
+Test sending 1000 64 byte       hello packets
+        Finished in 2373ms. 215 Kb/s
+
+Test sending 1000 1500 byte     hello packets
+        Finished in 2398ms. 5003 Kb/s
+
+Test sending 1000 64 byte       key packets
+        Finished in 2329ms. 219 Kb/s
+
+Test sending 1000 1500 byte     key packets
+        Finished in 2400ms. 4999 Kb/s
+
+Test sending 100000 64 byte     data packets
+        Finished in 1904ms. 26890 Kb/s
+
+This is the switch configuration so this indicates expected switch throughput:
+Test sending 100000 1500 byte   data packets
+        Finished in 8532ms. 140646 Kb/s

doc/configure.md

@@ -0,0 +1,267 @@
+Configuring cjdns
+=================
+
+In this document we are going to go over how to configure cjdns and what exactly each setting means. Note that this is a living document and this software is still in the alpha stages so things are subject to change.
+
+Let's start from the top of the file. First off you may notice it's JSON, except this JSON has comments. Technically that's not valid but it's also not uncommon. Cjdns strips out the comments before parsing it so no worries.
+
+Your Keys and Address
+---------------------
+
+The top part of the file specifies where the cjdns executable is, your encryption keys, and your cjdns IPv6 address.
+
+````javascript
+{
+    // The path to the cjdns core executable.
+    "corePath": "/opt/cjdns/cjdns",
+
+    // Private key:
+    // Your confidentiality and data integrity depend on this key, keep it secret!
+    "privateKey": "823e4EXAMPLEEXAMPLEEXAMPLEEXAMPLEEXAMPLEEXAMPLEEXAMPLEEXAMPLEc70",
+
+    // This key corresponds to the public key and ipv6 address:
+    "publicKey": "u2jf87mgqlxfzdnywp60z3tx6tkulvgh2nyc2jk1zc69zzt2s8u0.k",
+    "ipv6": "fcff:a215:1e7b:a4e9:c00d:0813:93b3:7c87",
+````
+
+- `corePath`: This specifies where the core cjdns executable file is. If you downloaded the source to /opt/cjdns, then the default is fine. If you downloaded it somewhere else, like your home directory for example, then this needs to be udpdated accordingly.
+- `privateKey`: Your private key is part of the system that ensures all the data coming and going out of your computer is encrypted. You must protect your private key. Do not give it out to anyone.
+- `publicKey`: The public key is what your computer gives to other computers to encrypt data with. This data can then only be decrypted with your private key, that way no one can access your information as it moves across the network.
+- `ipv6`: This is your IP address on the cjdns network. It is unique to you and is created by securely hashing your public key.
+
+Incoming Connections
+--------------------
+
+The `authorizedPasswords` section is the area where you can specify passwords to allow people to connect to you. Any system that presents a valid password will be allowed access.
+**NOTE:** These passwords should be long and random. There is no reason to make them short, easily remembered words because they are only going to be used by cjdns.
+
+````javascript
+    // Anyone connecting and offering these passwords on connection will be allowed.
+    //
+    // WARNING: Currently there is no key derivation done on the password field,
+    //          DO NOT USE A PASSWORD HERE use something which is truly random and
+    //          cannot be guessed.
+    // Including a username in the beginning of the password string is encouraged
+    // to aid in remembering which users are who.
+    //
+    "authorizedPasswords":
+    [
+        // A unique string which is known to the client and server.
+        {"password": "zxl6zgxpl4stnuybdt0xlg4tn2cdl5h"}
+
+        // More passwords should look like this.
+        // {"password": "10ru8br0mhk25ccpvubv0sqnl7kuc6s"},
+        // {"password": "y68jm490dztxn3d2gvuv09bz55wqmjj"},
+        // {"password": "bnpphnq205v8nf2ksrs1fknfr572xzc"},
+
+        // These are your connection credentials
+        // for people connecting to you with your default password.
+        // adding more passwords for different users is advisable
+        // so that leaks can be isolated.
+        //
+        // "your.external.ip.goes.here:33808":{"password":"zxl6zgxpl4stnuybdt0xlg4tn2cdl5h","publicKey":"u2jf87mgqlxfzdnywp60z3tx6tkulvgh2nyc2jk1zc69zzt2s8u0.k"}
+    ],
+````
+- `password`: This is the password that another system can give to your node and be allowed to connect. You would place it in the `password` section in the next part.
+- `your.external.ip.goes.here:33808` This section is what you would give to a friend so that they could connect with you. We suggest you add a `"name":"so-and-so"` section to it as well (don't forget the comma between sections!) so that it is easy to see who you have allowed access to. If it later turns out that you no longer wish to have this user connect to you then it is a simple matter to find them and delete or comment out the correct line.
+
+Admin Interface
+---------------
+
+The `admin ` section defines the settings for the administrative interface of cjdns. Many of the scripts in `/contrib/` use this to interact with cjdns. You probably wont need to use anything in there unless you are helping to test something out.
+
+````javascript
+    // Settings for administering and extracting information from your router.
+    // This interface provides functions which can be called through a TCP socket.
+    "admin":
+    {
+        // Port to bind the admin RPC server to.
+        "bind": "127.0.0.1:11234",
+
+        // Password for admin RPC server.
+        "password": "j6mukf2khplcgpbzz0kulb8hu0xq2v9"
+    },
+````
+
+- `bind`: This tells cjdns what IP and port the admin interface should bind to. Since you don't want random people connecting to your admin interface, it is probably fine to leave it like this.
+- `password`: This is the password that is needed in order to perform certain functions through the admin interface.
+
+Connection Interface(s)
+-----------------------
+
+This specifies the settings for the connection interfaces to your node. Right now most people use the `UDPInterface` to connect to other cjdns peers over the internet or other traditional networks. You may also use `ETHInterface` to physically connect to another machine. Note that this is not a standard TCP/IP connection like you are used to.
+
+````javascript
+    // Interfaces to connect to the switch core.
+    "interfaces":
+    {
+        // The interface which connects over UDP/IP based VPN tunnel.
+        "UDPInterface":
+        [
+            {
+                // Bind to this port.
+                "bind": "0.0.0.0:33808",
+
+                // Nodes to connect to.
+                "connectTo":
+                {
+                    // Add connection credentials here to join the network
+                    // Ask somebody who is already connected.
+                }
+            }
+        ]
+
+        /*
+        "ETHInterface":
+        [
+            {
+                // Bind to this device (interface name, not MAC etc.)
+                "bind": "eth0",
+
+                // Auto-connect to other cjdns nodes on the same network.
+                // Options:
+                //
+                // 0 -- Disabled.
+                //
+                // 1 -- Accept beacons, this will cause cjdns to accept incoming
+                //      beacon messages and try connecting to the sender.
+                //
+                // 2 -- Accept and send beacons, this will cause cjdns to broadcast
+                //      messages on the local network which contain a randomly
+                //      generated per-session password, other nodes which have this
+                //      set to 1 or 2 will hear the beacon messages and connect
+                //      automatically.
+                //
+                "beacon": 2,
+
+                // Node(s) to connect to manually.
+                "connectTo":
+                {
+                    // Credentials for connecting look similar to UDP credientials
+                    // except they begin with the mac address, for example:
+                    // "01:02:03:04:05:06":{"password":"a","publicKey":"b"}
+                }
+            }
+        ]
+        */
+    },
+````
+
+- `UDPInterface`:
+    - `bind`: This tells cjdns what IP and port to use for listening to connections.
+    - `connectTo`: This is where you put the connection details for peers that you want to connect to. The format for this generally looks like this,
+        "12.34.56.78:12345":
+        {
+            "password": "thisIsAnExampleOfAPassword",
+            "publicKey": "z4s2EXAMPLEPUBLICKEYEXAMPLEPUBLICKEYEXAMPLEKEY4yjp0.k"
+        },
+    It is important to note that while some people may put additional fields in such as `node`, only `password` and `publicKey` are actually read by cjdns.
+- `ETHInterface`:
+    - `bind`: This tells cjdns which device the ETHInterface should bind to. This may be different depending on your setup.
+    - `connectTo`: The connectTo for the ETHInterface functions almost exactly like it does for the the UDPInterface, except instead of an IP address and a port at the beginning, it is a MAC address.
+    - `beacon`: This controlls peer auto-discovery. Set to 0 to disable auto-peering, 1 to use broadcast auto-peering passwords contained in "beacon" messages from other nodes, and 2 to both broadcast and accept beacons.
+    - It is important to note that you must uncomment the ETHInterface if you want to use it
+
+Router
+------
+
+This is where you configure routing settings of your cjdns node.
+
+````javascript
+    // Configuration for the router.
+    "router":
+    {
+        // The interface which is used for connecting to the cjdns network.
+        "interface":
+        {
+            // The type of interface (only TUNInterface is supported for now)
+            "type": "TUNInterface"
+
+            // The name of a persistent TUN device to use.
+            // This for starting cjdroute as its own user.
+            // *MOST USERS DON'T NEED THIS*
+            //"tunDevice": "tun0"
+        },
+````
+
+- `type`: This specifies the type of interface cjdns should use to connect to the network. Only TUNInterface is supported at the moment.
+- `tunDevice`: This specifies which TUN device cjdns should use to connect to the network. Most users do not need this.
+
+IP Tunneling
+------------
+
+IP Tunneling will allow you to connect from the cjdns network to another outside network. This is still a work in-progress; although it does function, it requires a bit of manual configuration on both ends to make it useful.
+````javascript
+        // System for tunneling IPv4 and ICANN IPv6 through cjdns.
+        // This is using the cjdns switch layer as a VPN carrier.
+        "ipTunnel":
+        {
+            // Nodes allowed to connect to us.
+            // When a node with the given public key connects, give them the
+            // ip4 and/or ip6 addresses and prefix lengths listed.
+            "allowedConnections":
+            [
+                // Give the client an address on 192.168.1.0/24, and an address
+                // it thinks has all of IPv6 behind it.
+                // {
+                //     "publicKey": "f64hfl7c4uxt6krmhPutTheRealAddressOfANodeHere7kfm5m0.k",
+                //     "ip4Address": "192.168.1.24",
+                //     "ip4Prefix": 24,
+                //     "ip6Address": "2001:123:ab::10",
+                //     "ip6Prefix": 0
+                // },
+
+                // It's ok to only specify one address.
+                // {
+                //     "publicKey": "ydq8csdk8p8ThisIsJustAnExampleAddresstxuyqdf27hvn2z0.k",
+                //     "ip4Address": "192.168.1.25",
+                //     "ip4Prefix": 24
+                // }
+            ],
+
+            "outgoingConnections":
+            [
+                // Connect to one or more machines and ask them for IP addresses.
+                // "6743gf5tw80ExampleExampleExampleExamplevlyb23zfnuzv0.k",
+                // "pw9tfmr8pcrExampleExampleExampleExample8rhg1pgwpwf80.k",
+                // "g91lxyxhq0kExampleExampleExampleExample6t0mknuhw75l0.k"
+            ]
+        }
+    },
+````
+
+- `allowedConnections`:
+- `outgoingConnections`:
+
+Miscellaneous
+-------------
+
+This section contains the security section for configuring program options and a few other miscellaneous things that don't fit in with a broader category elsewhere.
+````javascript
+    // Tear down inactive CryptoAuth sessions after this number of seconds
+    // to make them more forgiving in the event that they become desynchronized.
+    "resetAfterInactivitySeconds": 100,
+
+    // Save the pid of the running process to this file.
+    // If this file cannot be opened for writing, the router will not start.
+    //"pidFile": "cjdroute.pid",
+
+    // Dropping permissions.
+    "security":
+    [
+        // Set number of open files to zero, in Linux, this will succeed even if
+        // files are already open and will not allow any files to be opened for the
+        // duration of the program's operation.
+        // Most security exploits require the use of files.
+        "nofiles",
+
+        // Change the user id to this user after starting up and getting resources.
+        {"setuser": "nobody"}
+     ],
+
+    // Version of the config file, used internally for migration.
+    "version": 1
+}
+````
+
+

doc/debian-wheezy.md

@@ -0,0 +1,27 @@
+# Installing cjdns on debian wheezy
+
+This is a short guide how to setup a debian wheezy cjdns box.
+
+## Enable backports
+
+	echo "deb http://http.debian.net/debian wheezy-backports main" >> /etc/apt/sources.list
+
+## Install systemd
+
+	aptitude install systemd-sysv
+
+## Install packages
+
+	aptitude install nodejs build-essential git
+
+## Clone, compile, install
+
+	cd /opt
+	git clone https://github.com/cjdelisle/cjdns.git
+	cd cjdns
+	./do
+	ln -s /opt/cjdns/cjdroute /usr/bin
+	./cjdroute --genconf > /etc/cjdroute.conf
+	cp contrib/systemd/cjdns.service /etc/systemd/system/
+	systemctl enable cjdns
+

doc/debugging_memory_leaks.md

@@ -0,0 +1,118 @@
+# Debugging memory leaks
+
+Ok, so cjdns just crashed on you and printed some shit like
+`Fatal error: [Out of memory, limit exceeded]` what do you do.
+
+## Solution 1: cry
+The bdfl will fix it when it happens on his laptop.
+
+## Solution 2: find the cause
+Before crashing, cjdns prints a tree containing every memory allocation, its allocator, the
+parent of that allocator and so on back up to the root allocator.
+
+Memory in cjdns is allocated in a tree structure similar to the directory structure on a filesystem.
+In order to allocate memory, you need an **allocator**, allocators can spawn child allocators
+and allocate memory. When an allocator is *freed*, all of its memory and all of the memory of
+its children is freed in turn.
+
+If you want to see the memory tree while cjdns is running, you can trigger a print of the tree using
+the RPC call `Allocator_snapshot()`, the parameter specifies whether the individual memory
+allocations should be shown or just the allocators, if cjdns has an OOM crash, it shows everything.
+
+Example: `./tools/cexec 'Allocator_snapshot(1)'`
+Note that this will print the tree to stdout because it is far too large to return in a UDP packet
+and sending it in multiple requests would require taking and storing (in memory) a snapshot to
+be retrieved by further requests (patches for this would be appreciated).
+
+The memory tree will look something like the following:
+
+        Core.c:496 [119096] bytes
+          Ducttape.c:982 [1088] bytes
+          | SessionManager.c:242 [864] bytes at [0x5555560579e0]
+          | SessionManager.c:241 [64] bytes at [0x555555fe0690]
+          | Ducttape.c:982 [160] bytes at [0x555555fe0f10]
+          Timeout.c:84 [488] bytes
+          | Allocator.c:657 [104] bytes at [0x555555e429e0]
+          | Timeout.c:85 [224] bytes at [0x555555e8cc50]
+          | Timeout.c:84 [160] bytes at [0x555555e7c460]
+          Janitor.c:671 [360] bytes
+          | Pinger.c:106 [1296] bytes
+          | | RouterModule.c:412 [2976] bytes
+          | | | UDPAddrInterface.c:96 [64] bytes at [0x55555605b710]
+          | | | UDPAddrInterface.c:96 [64] bytes at [0x55555605b670]
+          | | | Dict.c:132 [72] bytes at [0x555556058360]
+          | | | Dict.c:150 [64] bytes at [0x555556058310]
+          | | | Dict.c:132 [72] bytes at [0x5555560582c0]
+          | | | Dict.c:166 [64] bytes at [0x555556058270]
+          | | | Dict.c:132 [72] bytes at [0x555556058220]
+          | | | Dict.c:150 [64] bytes at [0x5555560581d0]
+          | | | RouterModule.c:414 [104] bytes at [0x555556058160]
+          | | | Message.h:58 [80] bytes at [0x555556058100]
+          | | | Message.h:57 [2096] bytes at [0x55555605aca0]
+          | | | RouterModule.c:412 [160] bytes at [0x555556058050]
+          | | Timeout.c:84 [488] bytes
+          | | | Allocator.c:657 [104] bytes at [0x555555ff5040]
+          | | | Timeout.c:85 [224] bytes at [0x555555fb2d00]
+          | | | Timeout.c:84 [160] bytes at [0x555555ff4f90]
+
+In this simplified example, Core.c:496 is the root allocator, the grand-daddy of all memory
+allocations. The RPC call `Core_exit()` actually works by freeing this allocator. Everything
+`Janitor.c:84` is a child of the root allocator and `Pinger.c:106` a child of that.
+`UDPAddrInterface.c:96 [64] bytes at [0x55555605b710]` is an allocation of a block of memory
+which you can see from its size (64 bytes) and its memory address.
+
+In each case, the allocator and the memory block, the filename and line number (eg: `Core.c:496`)
+is a place in a file where one can find the call to the memory operation.
+Usually either `Allocator_child()` or `Allocator_malloc()`.
+
+### Finding memory leaks
+If you encounter an OOM crash, there is probably a leak. The easiest way to find this is to take
+the entire memory tree trace (probably huge) and copy it into a text document. Remove everything
+below `----- end cjdns memory snapshot -----` and everything above
+`----- cjdns memory snapshot -----` then save the file (perhaps using the name `~/cjdns_memdump`).
+
+On the command line, run the following command:
+
+        cat ~/cjdns_memdump | sed -n -e 's/.* \([a-zA-Z0-9_]*\.[ch]\:[0-9]*\) .*$/\1/p' | sort | uniq -c | sort -n
+
+This will show a list of each location (in the code) where memory is allocated and the number of
+currently active allocations (or allocators) which were allocated in that spot.
+
+Here is the bottom of the output from the above command. The top is mostly locations which only
+have one currently active allocation.
+
+            8 RumorMill.c:136
+           57 Message.h:57
+           57 Message.h:58
+           57 Pinger.c:116
+           57 RouterModule.c:414
+           57 RouterModule.c:580
+           66 Dict.c:199
+          114 Pinger.c:106
+          114 RouterModule.c:412
+          114 UDPAddrInterface.c:96
+          118 NodeStore.c:1461
+          121 EncodingScheme.c:377
+          121 EncodingScheme.c:383
+          172 Dict.c:95
+          180 Dict.c:150
+          204 SessionManager.c:183
+          206 CryptoAuth.c:1207
+          236 NodeStore.c:1460
+          249 String.c:31
+          249 String.c:39
+          293 Dict.c:166
+          408 SessionManager.c:172
+          539 Dict.c:132
+          725 NodeStore.c:113
+         2392 Timeout.c:85
+         2470 Allocator.c:657
+         4784 Timeout.c:84
+         7428 SessionManager.c:241
+         7428 SessionManager.c:242
+        14856 Ducttape.c:982
+
+All the way at the bottom is an anomaly, a single location in the source code which contains
+twice as many allocations as the next greatest number. Investigating that I found a dumb mistake
+which [some idiot](https://github.com/cjdelisle/cjdns/commit/507223dac10690f562b91d8ec84ce2f7a41df5ad)
+made while working on the source.

doc/djc_layer_model.md

@@ -0,0 +1,113 @@
+# DJC Layer Model
+
+Note: This is not implemented yet.
+
+## LayerA
+Communication between peers, this layer is only of interest to the two peers which are
+directly communicating. No information in this layer is directly passed on to the next
+peer in the path. This layer is expected to provide packet length information to all
+higher layers. Although this layer traditionally contains UDP or Ethernet headers, any
+means of framing and point-to-point transport is acceptable.
+
+Examples of headers which fall in this layer are:
+
+UDPInterface:
+
+    [ IP ][ UDP ][ CryptoAuth ]
+
+ETHInterface:
+
+    [ ETH Header ][ CryptoAuth ]
+
+Direct over phy (future):
+
+    [ SyncMagic ][ Length ][ CryptoAuth ]
+
+
+## LayerB
+Switch Layer, this layer is seen by all switches along a direct path as well as the routers
+at the ends of the path but when a router forwards the packet on, headers at this layer are
+replaced with new ones just as the Ethernet header is replaced by each IP router.
+
+This layer contains:
+
+    [ SwitchHeader ]
+
+
+## LayerC
+Inter-Router Layer, this layer is only of interest to the routers which will forward the packet.
+No data in this layer is directly forwarded on to the final endpoints or downstream routers
+and no data at this layer or below it can be accessed by the switches due to a CryptoAuth header
+which begins this layer. Since the width of a CryptoSessionHeader depends on the state of the
+CryptoAuth session represented, a router should only forward packets to another router after
+the CryptoAuth session with that router has entered into the ESTABLISHED state in order to prevent
+fluctuating MTU.
+
+    [ CryptoSessionHeader ]
+
+### LayerC Control Packet
+In order for switches to send error and other control messages, a branch of *LayerC* exists which
+does not contain encrypted data, in place of the CryptoSessionHeader are the four bytes `0xffffffff`
+followed by a Control packet (see Control.h for details). The four bytes `0xffffffff` in a
+CryptoSessionHeader have a meaning, they indicate intent to begin a CryptoAuth session without
+knowing the key of the other end, it is however illegal to begin a session at *LayerC* without
+knowing the peer's key so this value is repurposed to indicate presence of a Control packet.
+
+
+## LayerD
+Routing Layer, this layer is of interest both to the routers which will forward the packet
+and to the final endpoints. The endpoints can use data placed in this layer to communicate with
+the intermediary routers and routers can use it to communicate back to the endpoints.
+
+This layer contains:
+
+    [ RouteHeader ]
+
+NOTE: In versions previous to v9, RouteHeader is replaced with an IPv6 header.
+
+
+## LayerE
+Data layer, this layer is only of interest to the sender and the recipient. It it protected by
+a CryptoAuth layer which prevents intermediate routers from accessing the data therein.
+
+This layer contains:
+
+    [ CryptoSessionHeader ][ DataHeader ][ TCP/UDP/other ][ user's data ]
+
+If the sender is using a direct path (through the switch fabric) to the recipient,
+the CryptoSessionHeader is omitted and in it's place are the four bytes `0xfffffffe` in
+big endian form. In this case, the identity of the sender is to be determined by examining
+the CryptoSessionHeader at *LayerC*.
+
+Note: In versions previous to v9, the CryptoSessionHeader was replaced with a CryptoAuth
+header and the DataHeader was omitted. In the event of a direct path send, as described above,
+the CryptoAuth header was omitted with no replacement and the recipient was expected to detect
+the state by comparing the source field in the *LayerD* IPv6 header with the identity of the
+sending router as determined from the CryptoSessionHeader at *LayerC*.
+
+
+## CryptoSessionHeader
+
+As there is no CryptoSessionHeader.h, the nature of the CryptoSessionHeader is explained here.
+There are two types of CryptoSessionHeader, one is a setup packet header which is 124 bytes long,
+the other is the run packet header, which is 24 bytes long. The type of the individual packet is
+determined by the first four bytes.
+
+If the first 4 bytes as a big endian integer are greater than or equal to 4 and
+not equal to `0xffffffff`, the message is a run message and the first 4 bytes are
+a handle. Otherwise it is a start message and the first 4 bytes are the
+CryptoAuth session state.
+
+
+
+
+    [ IP ]                    20
+    [ UDP ]                    8
+    [ CryptoAuth ]            20
+    [ SwitchHeader ]          12
+    [ CryptoSessionHeader ]   24
+    [ RouteHeader ]           20
+    [ CryptoSessionHeader ]   24/124
+    [ DataHeader ]             4
+    [ TCP/UDP/other ]
+    [ user's data ]

doc/man/cjdroute.conf.5

@@ -0,0 +1,295 @@
+.\" Manpage for cjdroute.conf
+.\"
+
+.TH cjdroute.conf 5 "2014-03-16" "" "Cjdns Reference"
+
+.SH "NAME"
+cjdroute.conf \- Cjdns configuration file
+
+.SH "DESCRIPTION"
+The
+.I cjdroute\&.conf
+file configures the cjdns routing engine,
+.BR cjdns (8),
+generally through
+.BR cjdroute (1)\&.
+.PP
+The configuration is written in a variation of the JSON format that also
+accepts traditional C-like comments such as single line comments (//) and
+multiline comments (/* and */)\&. Additionally, unused JSON values found in
+.I cjdroute\&.conf
+are ignored by cjdns and can be used as a form of JSON-compliant comments.
+
+.SH "CONFIGURATION"
+\fB"privateKey":\fR "\&.\&.\&."
+.RS 4
+Your node's private key\&. It should be kept secret because your
+confidentiality and data integrity depend on it.
+.RE
+.PP
+
+\fB"publicKey":\fR "\&.\&.\&."
+.RS 4
+Your node's public key\&. Based on your private key It is fine for anyone
+to know this\&.
+.RE
+.PP
+
+\fB"ipv6":\fR "\&.\&.\&."
+.RS 4
+Your node's IPv6 address when it is on the network\&. It is generated
+by using the first 16 bytes of a double SHA-512 of your public key\&. All
+cjdns IPv6 addresses must begin with "fc" or else they are invalid\&.
+.RE
+.PP
+
+\fB"authorizedPasswords":\fR [\&.\&.\&.]
+.RS 4
+An array of passwords that may be used to connect (peer) to your node\&.
+.PP
+\fI"password":\fR "..."
+.RS 4
+A password which can be used to peer with your node\&.
+.RE
+.PP
+\fI"user":\fR "..."
+.RS 4
+An optional human-readable string that identifies what password a peer is using
+on the admin interface\&. If omitted, the password will be identified by its
+position within the array (starting from 0)
+.RE
+.PP
+Example:
+.br
+"authorizedPasswords":
+.br
+[
+    { "password": "AnExamplePassword", "user": "Bob" },
+    { "password": "YetAnotherExample", "user": "Alice" },
+    { "password": "j3fus4r3gkhv80xdz1yqc0qvn1p91hr", "user": "Eve" }
+.br
+]
+.RE
+.PP
+
+\fB"admin":\fR {\&.\&.\&.}
+.RS 4
+An object which defines where to bind to the admin RPC server as well as the
+password for the admin RPC server\&. The two required strings are "bind", which
+should be in the format "IP:PORT", and "password", which should preferably be a
+long random string of characters.
+.RE
+.PP
+
+\fB"interfaces":\fR {\&.\&.\&.}
+.RS 4
+An object that defines which interfaces cjdns will bind to and what peers to
+connect to\&. There are two different interfaces, UDPInterface and
+ETHInterface, both of which are arrays\&. Within each array there are a variety
+of different options
+.PP
+\fI"bind":\fR "\&.\&.\&."
+.RS 4
+Defines what the interface should bind to\&. In UDPInterface, the bind is
+an IP:PORT string, such as "0\&.0\&.0\&.0:12345", while in ETHInterface the bind
+is a network interface, such as "eth0"\&.
+.RE
+.PP
+\fI"beacon":\fR Integer
+.RS 4
+This option is only found in ETHInterface and defines whether auto-connecting
+beacons should be sent or listened to\&. This is useful for a zeroconf local
+network\&.
+.PP
+.RS 4
+0 \-\- Disabled\&.
+.br
+1 \-\- Accept incoming beacons and try connecting to the sender\&.
+.br
+2 \-\- Accept incoming beacons and broadcast beacons to the local network\&.
+.RE
+.RE
+.PP
+\fI"connectTo":\fR {\&.\&.\&.}
+.RS 4
+Defines which nodes cjdns should connect to with the specified interface\&.
+Multiple nodes may be placed in a single "connectTo" as long as each are
+seperated by commas\&. If a node happens to be offline or become offline during
+runtime, cjdns will attempt to reconnect at regular intervals\&. The one
+difference in this option between UDPInterface and ETHInterface is that
+UDPInterface connects to an "IP:PORT" while ETHInterface connects to a MAC
+address\&.
+.PP
+UDPInterface Example:
+.br
+"connectTo":
+.br
+{
+.RS 4
+"1\&.2\&.3\&.4:54321":
+.br
+{
+    "password": "password From Your Peer's authorizedPasswords",
+    "publicKey": "Your Peer's publicKey\&.k"
+.br
+},
+.br
+"5\&.6\&.7\&.8:46321":
+.br
+{
+    "password": "Correct Horse Battery Staple",
+    "publicKey": "Other Peer's publicKey\&.k"
+.br
+}
+.RE
+}
+.RE
+.RE
+.PP
+
+\fB"router":\fR {\&.\&.\&.}
+.RS 4
+An object that holds configuration information on the router
+.PP
+\fI"interface":\fR {\&.\&.\&.}
+.RS 4
+Defines the type of interface used for connecting to the cjdns network\&.
+It requires a "type" string, and optionally a "tunDevice" string\&. The "type"
+string defines the type of interface used, however only "TUNInterface" is
+supported at the moment\&. The "tunDevice" string defines the name of a
+persistent TUN device to use, which is helpful for starting cjdroute as its own
+user instead of root\&.
+.RE
+.PP
+\fI"ipTunnel":\fR {\&.\&.\&.}
+.RS 4
+A system for tunneling ICANN IPv4 and ICANN IPv6 through cjdns\&. This is using
+the cjdns switch layer as a VPN carrier\&.
+.PP
+\fBNOTE:\fR Simply editing your configuration file is not sufficient to
+setting up an ipTunnel gateway\&. Please read through tunnel/README.md in the
+cjdns git tree for more information
+.PP
+\fI"allowedConnections":\fR [\&.\&.\&.]
+.RS 4
+Nodes allowed to connect to us, specified by their public key, and what IP
+address(es) to give them\&. It is fine to only specify one address\&.
+.PP
+Example:
+.PP
+"allowedConnections":
+.br
+[
+.br
+    {
+        "publicKey": "f64hfl7c4uxt6krmhPutTheRealAddressOfANodeHere7kfm5m0.k",
+        "ip4Address": "192.168.1.24",
+        "ip4Prefix": 24,
+        "ip6Address": "2001:123:ab::10",
+        "ip6Prefix": 0
+.br
+    },
+.br
+    {
+        "publicKey": "ydq8csdk8p8ThisIsJustAnExampleAddresstxuyqdf27hvn2z0.k",
+        "ip4Address": "192.168.1.25",
+        "ip4Prefix": 24
+.br
+    }
+.br
+]
+.RE
+.PP
+\fI"outgoingConnections":\fR [\&.\&.\&.]
+.RS 4
+An array of nodes to connect and ask for IP addresses.
+.PP
+Example:
+.PP
+"outgoingConnections":
+.br
+[
+    "6743gf5tw80ExampleExampleExampleExamplevlyb23zfnuzv0.k",
+    "pw9tfmr8pcrExampleExampleExampleExample8rhg1pgwpwf80.k",
+    "g91lxyxhq0kExampleExampleExampleExample6t0mknuhw75l0.k"
+.br
+]
+
+.RE
+.RE
+.RE
+.PP
+
+\fB"resetAfterInactivitySeconds":\fR Integer
+.RS 4
+The number of seconds to wait before tearing down an inactive CryptoAuth
+session\&.
+.RE
+.PP
+
+\fB"security":\fR [\&.\&.\&.]
+.RS 4
+An array that defines what user to change to after startup and whether to
+exempt the Angel process from this user change\&.
+.PP
+\fI"setuser":\fR "username"
+.RS 4
+User to switch to after startup, for security purposes\&. Default value is
+"nobody"\&.
+.PP
+.RE
+\fI"exemptAngel":\fR Integer
+.RS 4
+Whether or not to exempt the Angel process from the user change\&. The Angel is
+a small isolated piece of code which exists outside of the core's strict
+sandbox but does not handle network traffic\&. This option must be enabled for
+ipTunnel to automatically set IP addresses for the TUN device\&.
+.PP
+0 \-\- False
+.br
+1 \-\- True
+.RE
+.RE
+.PP
+
+\fB"logging":\fR {\&.\&.\&.}
+.RS 4
+Add or uncomment "logTo":"stdout" to have cjdns log to stdout rather than
+making logs available via the admin socket
+.RE
+.PP
+
+\fB"noBackground":\fR Integer
+.RS 4
+If set to a non-zero value, cjdns will not fork to the background\&.
+Recommended for use in conjunction with "logTo":"stdout"\&.
+.RE
+.PP
+\fB"dns":\fR {\&.\&.\&.}
+.RS 4
+This section is used to configure the dns capabilities being added to cjdns\&.
+Unfortunetly, there is no documentation for this DNS section at this time\&.
+.PP
+\fI"keys":\fR [\&.\&.\&.]
+.RS 4
+.RE
+.PP
+\fI"servers":\fR [\&.\&.\&.]
+.RS 4
+.RE
+.PP
+\fI"MinSignatures":\fR Integer
+.RS 4
+.RE
+.RE
+
+
+.SH "FILES"
+.BI /etc/cjdroute.conf
+.RS 4
+A common location for the configuration file\&.
+.RE
+
+.SH "SEE ALSO"
+.BR cjdroute (1),
+.BR cjdns (8)

doc/nat-gateway.md

@@ -0,0 +1,146 @@
+# CJDNS NAT Gateway
+
+*Guide courtesy of [hyperboria.name](http://hyperboria.name/gateway) with minor
+edits.*
+
+Configure a host to act as a NAT gateway to provide access to Hyperboria for
+devices on your LAN (Windows PC, tablet, smart phone).
+
+This is a guide to setting up Ubuntu 13.04 to act as an IPv6 router and NAT
+gateway for CJDNS.  Those who prefer other distros should find it trivial to
+adapt these instructions as required. If you do not have a linux server on your
+LAN already, consider purchasing a BeagleBone Black (for only $45 dollars!).
+You can find instructions [here](http://hyperboria.name/bbb/) on how to set it
+up for CJDNS.
+
+**WARNING**: The built-in security and encryption of CJDNS will **NOT**
+carry over past the gateway. Use of a NAT gateway for CJDNS should **ONLY**
+be done on a secure and trusted LAN. Any device on the LAN could theoretically
+intercept local CJDNS traffic before it reaches the gateway, and all devices
+will appear to other CJDNS nodes to *BE* the gateway node. This is intended
+to be a temporary solution until more universal compatibility is available for
+CJDNS.
+
+You will need:
+
+* One device running Ubuntu 13.04 and connected to your LAN
+
+*OR*
+
+* One device running the linux of your choice with kernel 3.7 or later and
+  connected to your LAN
+* Sufficient knowledge to adapt this guide to your prefered linux
+
+## Update and Configure iptables
+
+You will find it much easier to do this as root rather then using sudo, so run
+`sudo -i` first.
+
+You will need iptables 1.4.17 or better to properly configure IPv6 NAT with
+masqurade.  Unfortunately, the latest Ubuntu as of the writing of this guide
+(13.04) only has 1.4.12, so you will need to download and install these
+packages (in order) before continuing:
+
+    wget http://ftp.us.debian.org/debian/pool/main/libn/libnfnetlink/libnfnetlink0_1.0.1-2_armhf.deb<br>
+    dpkg -i libnfnetlink0_1.0.1-2_armhf.deb
+
+    wget http://mirrors.kernel.org/debian/pool/main/i/iptables/libxtables10_1.4.18-1_armhf.deb<br>
+    dpkg -i libxtables10_1.4.18-1_armhf.deb
+
+    wget http://mirrors.kernel.org/debian/pool/main/i/iptables/iptables_1.4.18-1_armhf.deb<br>
+    dpkg -i iptables_1.4.18-1_armhf.deb
+
+Obviously this will not be necessary if you already have iptables 1.4.17 or
+later installed. You can confirm your version by running the following command:
+
+        iptables --version
+
+Also note that you will need linux kernel 3.7 or later to have support for IPv6
+NAT at all.
+
+Next you need to enable forwarding for IPv6:
+
+    echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
+
+Make it permenant by editing `/etc/sysctl.conf` to include the following line:
+
+    net.ipv6.conf.all.forwarding=1
+
+You will most likely find it in there already, but commented out. Simply remove
+the "#".
+
+Now enter the ip6tables rules:
+
+    ip6tables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
+    ip6tables -A FORWARD -i tun0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
+    ip6tables -A FORWARD -i eth1 -o eth0 -j ACCEPT
+
+Save the rules:
+
+    ip6tables-save > /etc/network/ip6tables.rules
+
+Create the file `/etc/network/if-pre-up.d/ip6tables` containing the following:
+
+    #!/bin/sh
+    ip6tables-restore < /etc/network/ip6tables.rules
+    exit 0
+
+And make it executable:
+
+    chmod +x /etc/network/if-pre-up.d/ip6tables
+
+Now iptables is configured as an IP v6 NAT gateway, and the settings will be
+preserved through reboots.
+
+## Install and Configure radvd
+
+Install radvd so that your gateway advertises itself on the network:
+
+    apt-get install radvd
+
+Create (or edit if already present) the file `/etc/radvd.conf` with the
+following contents:
+
+    interface eth0
+    {
+        AdvSendAdvert on;
+        prefix fdfc::1/64
+        {
+            AdvRouterAddr on;
+        };
+    };
+
+Note that this assumes you will be using the eth0 interface. If your LAN
+interface is different, you need to replace eth0 with the correct one.
+
+Start/restart radvd:
+
+    /etc/init.d/radvd restart
+
+Now IPv6 capable computers and devices should configure themselves to use your
+gateway automatically as soon as they are connected to the network.
+
+To ensure proper routing, however, the interface needs the right IP assigned to
+it. Edit the file `/etc/network/interfaces` to include the following:
+
+    iface eth0 inet6 static
+    pre-up modprobe ipv6
+    address fdfc:0000:0000:0000:0000:0000:0000:0001
+    netmask 64
+
+Once again, this assumes your LAN interface is eth0. Adjust as required.
+At this point, it is recommended that you reboot so you can confirm everything
+is still working:
+
+    reboot
+
+Don't forget to start CJDNS after it's done booting if you haven't set it up to
+start automatically.  Alternatively, if you do not want to reboot at this time,
+you can run the following command to assign the IP address to the interface
+manually:
+
+    ip addr add fdfc::1/64 dev eth0
+
+You may need to disconnect and reconnect some devices to get them to
+autoconfigure, but in most cases you should only need to wait a minute or two
+for them to work. Other then that, you should be done!

doc/network-services.md

@@ -0,0 +1,95 @@
+# Self-check your network services
+
+Once your node is running, you are now a newly minted IPv6 host. Your operating
+system may automatically reconfigure network services to use this new address.
+Take control of the services your host is offering as described below.
+
+## 1: Obtain IP address.
+
+Use `ifconfig -a` to find the IPv6 address of your TUN device. (Assigned by
+cjdroute.)
+
+## 2: Scan for open services.
+
+Run `nmap` to discover which services are accessible from this address.
+For example, to scan the address fcf7:75f0:82e3:327c:7112:b9ab:d1f9:bbbe:
+
+    nmap -6 -n -r -v -p1-65535 -sT fcf7:75f0:82e3:327c:7112:b9ab:d1f9:bbbe
+
+This should result in an output like the following.
+
+    Starting Nmap 5.61TEST2 ( http://nmap.org ) at 2011-12-29 20:40 EST
+    Initiating Connect Scan at 20:40
+    Scanning fcf7:75f0:82e3:327c:7112:b9ab:d1f9:bbbe [65535 ports]
+    Completed Connect Scan at 20:40, 4.38s elapsed (65535 total ports)
+    Nmap scan report for fcf7:75f0:82e3:327c:7112:b9ab:d1f9:bbbe
+    Host is up (0.00073s latency).
+    All 65535 scanned ports on fcf7:75f0:82e3:327c:7112:b9ab:d1f9:bbbe are closed
+
+    Read data files from: /usr/local/bin/../share/nmap
+    Nmap done: 1 IP address (1 host up) scanned in 4.60 seconds
+        Raw packets sent: 0 (0B) | Rcvd: 0 (0B)
+
+## 3: If you see anything open, fix it.
+
+Examples for SSH and Samba are below.
+
+### SSH
+
+Edit `/etc/ssh/sshd_config`:
+
+    ListenAddress 192.168.1.1
+
+^ Replace `192.168.1.1` in the example above
+  with your STATIC IP (or map DHCP via MAC).
+
+### Samba
+
+Edit `/etc/samba/smb.conf`:
+
+    [global]
+    interfaces = eth0
+    bind interfaces only = Yes
+
+^ This will cause Samba to not bind to `tun0`
+  (or whichever TUN device you are using).
+
+### Apache
+
+You will have to find the `Listen` directive in your Apache configuration,
+which is located in different files depending on your distribution and platform.
+Many distributions make Apache listen to all interfaces, IPv4 as well as IPv6:
+
+    Listen 80
+
+You can change this to:
+
+    Listen 192.168.1.1:80
+
+For example, to force Apache onto IPv4 addresses only for all of its hosts.
+If you wish to mix and match virtual hosts, exposing some via IPv6 and others
+only via IPv4, you can configure each virtual host separately:
+
+    <VirtualHost [2001:db8::a00:20ff:fea7:ccea]:80>
+        # configuration goes here
+    </VirtualHost>
+
+Versus a virtual host in IPv4:
+
+    <VirtualHost 192.168.1.1:80>
+        # configuration goes here
+    </VirtualHost>
+
+If you keep listening on all IP versions, make sure your default `DocumentRoot`
+points to something useful and not something sensitive, since Apache will fall
+back to that `DocumentRoot` if none of your virtual hosts matches an incoming
+request.
+
+
+### Lighttpd
+
+Comment out the following line in `/etc/lighttpd/lighttpd.conf`:
+
+    include_shell "/usr/share/lighttpd/use-ipv6.pl"
+
+Thats it for now! Got More? Tell us on IRC.

doc/non-root-user.md

@@ -0,0 +1,59 @@
+Run cjdns as a non-root user
+============================
+
+There are two ways to run cjdns as a non-root user. You might need this if you
+want to run cjdns on OpenVZ or start the network as a normal user.
+
+Method 1: Setup the tun interface ahead of time (required for OpenVZ)
+---------------------------------------------------------------------
+
+If you are using an OpenVZ based VPS then you will need to use this as OpenVZ
+does not permit persistent tunnels.
+
+Create a cjdns user:
+
+    sudo useradd cjdns
+
+Create a new TUN device and give the cjdns user authority to access it:
+
+    sudo /sbin/ip tuntap add mode tun user cjdns dev cjdroute0
+
+
+### 4b-1: Setup the interface manually
+
+Run those commands to prepare your TUN device:
+
+    sudo /sbin/ip addr add <your ipv6 address>/8 dev cjdroute0
+    sudo /sbin/ip link set mtu 1312 dev cjdroute0
+    sudo /sbin/ip link set cjdroute0 up
+
+These commands should be executed as root now every time the system restarts.
+You might also want to place these commands in /etc/rc.local if your system
+supports it.
+
+#### Old versions of iproute2
+
+If you see an error when running /sbin/ip, your version of iproute2 might be
+old.
+
+    sudo /sbin/ip tuntap add mode tun user cjdns
+    Object "tuntap" is unknown, try "ip help".
+
+The fix: for now grab a copy of a newer `ip` binary and copy it to your home
+directory. Replacing the system binaries is not likely a good idea.
+
+### 4b-2: Fire it up!
+
+    sudo -u cjdns ./cjdroute < cjdroute.conf
+
+To delete a tunnel, use this command:
+
+    sudo /sbin/ip tuntap del mode tun <name of tunnel>
+
+Method 2: Give the capabilities to create the tun device to the cjdroute executable
+-----------------------------------------------------------------------------------
+
+Run this command as root after building (and every time you rebuild cjdroute):
+
+    setcap "cap_net_admin+eip cap_net_raw+eip" cjdroute
+

doc/open-indiana.md

@@ -0,0 +1,18 @@
+# Installing cjdns on OpenIndiana
+
+**currently broken by recent changes**
+
+In order to install cjdns on an OpenIndiana system, do the following:
+
+    sudo pkg set-publisher -p http://pkg.openindiana.org/sfe
+    sudo pkg install runtime/gcc@4.6.2,5.11-0.151.1:20111222T011404Z
+    sudo pkg install gnu-make
+    sudo pkg install header-math
+    sudo pkg install git
+    sudo pkg install tuntap
+    git clone git://github.com/cjdelisle/cjdns.git
+    cd cjdns
+    ./do
+
+Once it has completed successfully, simply type ./cjdroute and follow the
+normal instructions

doc/projectGoals.md

@@ -0,0 +1,75 @@
+# Project goals
+
+## With built-in security and auto-configuration, everybody can own part of the network
+
+The Internet gives everyone incredible power of expression that was once
+reserved for those wealthy enough to own a radio station or newspaper. Still,
+the Internet's aging protocols have inherent limitations which make them
+unfavorable toward a network owned by the people.
+
+Recent revelations over governments reading our emails have triggered public
+outcry but few stop to imagine the implications of an unsecured
+mesh network, in such a network *everybody* could read your email.
+
+Competition in Internet Access markets worldwide has withered, dominated by a
+few businesses who charge outrageous rates and have not materially increased
+Internet speed since crushing the dial-up providers. Most agree that more market
+diversity is necessary, but if the handful of ISPs we have now cannot be trusted
+to handle our data, there is no reason to expect that the next generation of
+Internet Service Providers would either.
+
+The problem of trust extends beyond private correspondence. The very
+fabric of the Internet can be torn apart by a malicious ISP or even an honest
+mistake. On April 8th, 2010, an employee at China Telecom misconfigured a
+router - causing widespread Internet outages lasting up to fifteen minutes.
+
+As world governments continue pushing to filter websites, there is an ever
+increasing risk of back-and-forth retaliatory filtration eventually leaving
+entire nations isolated and breeding the hate and intolerance which the Internet
+promised to end.
+
+Cjdns was designed with the understanding that for the Internet to continue
+existing without borders, authority over its processes must be decentralized.
+This isn't, and can't be, just a dream - the future of the open Internet is at
+stake.
+
+
+## Security
+
+When you receive a packet of information from the Internet, it seems logical to
+assume that it was meant for you - that it came from the computer which it says
+it came from and that nobody else has read or modified it on the way. While many
+popular software applications are designed around these assumptions, the
+existing Internet does not guarantee any of them and a number of network
+security exploits come from the cases where these assumptions break down.
+
+Cjdns guarantees confidentiality, authenticity and integrity of data by using
+modern cryptography in a non-intrusive way. Information transmitted over a cjdns
+network can't be altered or read en-route. While you can create multiple
+identities, it's practically impossible to impersonate other nodes on the
+network and since a node's IPv6 address is the fingerprint of its key,
+man-in-the-middle attacks are not possible.
+
+
+## Simplicity
+
+Traditional networks require manual configuration of IP addresses. For one to
+get these addresses one must join an Internet Registry and file a lengthy
+application. Cjdns nodes generate their own addresses along with their keys.
+When two nodes find each other, they connect. When many nodes find one another,
+they form a network. General network architecture is of course needed to avoid
+bottlenecks but once the nodes are put in the right places, they will discover
+their roles in the network.
+
+
+## Scalability
+
+Cjdns is built around the bold and unproven assumption that a non-hierarchical
+network can scale. Cjdns uses a [distributed hash table][] to spread the load
+of routing among a number of nodes, rather than requiring every node know the
+exact location of every other node. At the bottom layer, packets are tagged
+with the exact route they should take, think of it like driving directions.
+At the upper layer the nodes maintain and test routes to other nodes who have
+numerically similar IPv6 addresses to their own. Forwarding is achieved by
+sending a packet to physically nearby nodes who have destinations numerically
+close to the target address.

doc/projectGoals_ru.md

@@ -0,0 +1,65 @@
+# Project Goals
+## Зачем?
+
+Для того, чтобы дать обычным людям больше возможностей при обмене информацией.
+
+Cjdns позволяет решить множество проблем текущих сетей. При его использовании вы полностью обладаете своей инфраструктурой обмена информацией.
+
+Кроме того, данный протокол позволяет решить проблему оптимального перераспределения трафика, не делая практически ничего.
+
+Вот простой пример. Сколько у вас дома есть открытых Wi-Fi сетей?
+
+Вероятно, не меньше двух. А теперь представьте, что они работают в Mesh режиме, динамически перенаправляя нагрузку и распределяя трафик.
+
+Централизация власти проявляется в закрытии таких сайтов, как Wikileaks, и любых других — неугодных власти.
+
+В цивилизованном, демократическом обществе каждый должен иметь свободу слова, а цензурироваться могут лишь очевидно-плохие вещи: детская порнография, мошенничество, спам. И конечно, решения о цензуре должно принимать общество, а не правительство.
+
+
+## Как мы близки к финальной версии?
+
+В данный момент работает тестовая сеть, в которой имеется от 500 до 1000 узлов.
+
+Cjdns была протестирована на x86, amd64, ARMv5, ARMv7, MIPS, PowerPC32 и PowerPC64. Тестирование на различных Linux системах продолжается. 
+
+Программное обеспечение работает стабильно, но мы не знаем, как поведут себя в реальном мире наши алгоритмы и протоколы. Пожалуйста, следите за обновлениями cjdns. С помощью тестирования мы сможем определить оптимальный набор алгоритмов и протоколов для использования в реальном мире.
+
+
+## Ты можешь помочь!
+
+Нам нужны добровольцы для тестирования по автоматической сборке cjdns на Apple OS X системе, если вы можете пожертвовать нам деньги для этого дела — напишите нам на почту.
+
+Или же вы можете помочь нам, предоставив 24/7 shell доступ к компьютеру с системой OS X для проведения тестирования.
+
+Всё это можно обсудить в нашем IRC канале.
+
+
+## Анонимность
+
+В отличии от TOR, I2P, и Freenet’a, cjdns планировалась не как анонимная есть. Она не использует случайную маршрутизацию, динамические маршруты и другие технологии для обеспечения анонимности.
+
+Наоборот, cjdns использует самый оптимальный маршрут. Мы пошли на такой шаг, для обеспечения максимальной производительности.
+
+С другой стороны, некий уровень анонимности всё же присутствует. Для того, чтобы определить ваше физическое положение на основе вашего cjdns адреса, потребуется сделать трассировку по IPv4 адресам от конечной ноды до вас, запросив информацию по проходящему трафику от операторов всех транзитных нод.
+
+
+## Безопасность
+
+Когда вы получаете информационный пакет из интернета, это означает, что он предназначен для вас, но никто не знает, модифицировался ли пакет по пути или же нет. Множество программ, которые взаимодействуют с интернетом, не проверяют неизменность пакета, а такие программно-аппаратные средства, как DPI, могут вносить значительные изменения в пакеты.
+
+Cjdns гарантирует, что пакет по пути был не кем не модифицирован, что подтверждается криптографическими средствами, которые используются в этом протоколе.
+
+Cjdns защищает информацию которая поступает к вам, от использования заведомо ложного маршрута, что позволяет полностью избежать атаки man-in-the-middle.
+
+
+## Простота
+
+Представьте себе такую компьютерную сеть, в которой всё, что нужно сделать инженеру — это подключить компьютер сетевым кабелем, а компьютер сам узнает, как найти других и сам сконфигурируется.
+
+Это и есть основная цель cjdns. Конечно же, сетевые специалисты всё еще будут нужны для решения сложных технических вопросов, но большую часть решения проблем сможет взять на себя cjdns.
+
+
+## Масштабируемость
+
+С основе Cjdns лежат принципы одноранговой сети, таким образом, cjdns может масштабироваться бесконечно — нет большой нагрузки на какой-то определенный узел.
+Cjdns использует распределенную хэш таблицу (DHT) для обмена маршрутами, это позволяет не иметь карту всей сети каждому узлу (не раздувать таблицу маршрутов).

doc/security_specification.md

@@ -0,0 +1,54 @@
+#Security Specification
+
+This document is here to help define security flaws in a way that can be agreed upon.
+
+##Definitions
+
+* Reveal: To reveal a piece of content is to send over the wire that content or something from which
+that content can be mathematically derived (not withstanding theoretical attacks
+eg: Quantum Computers unless explicitly said otherwise)
+
+* Matching Keypair: In relation to an IPv6 address, a public and private key for which the first
+16 bytes of the double-SHA-512 (the SHA-512 of the SHA-512) of the public key matches the IPv6
+address.
+
+* Permanent Private Key: The key which is in the configuration file which defines the node's
+identity.
+
+##Limitation of Scope
+
+This document applies to the current version (latest master branch) of cjdns compiled and running
+on a Linux system using a version of GCC with no known security issues and running on an
+x86 or amd64 processor. Older versions and git branches may be non-compliant with this
+specification.
+
+##Integrity and Confidentiality
+
+1. It must not be possible to reveal the permanent private key or any temporary session private keys
+to anyone.
+
+2. It must not be possible to reveal any temporary symmetrical session keys to anyone other than the
+identity (permanent public key) with which the session has been established.
+
+3. It must not be possible to reveal the content of any packet with an fc00::/8 destination address
+which enters cjdns through the TUN device, except revealing it to the holder(s) of the Matching
+Keypair for that address.
+
+4. It must not be possible to receive any packet with an fc00::/8 source address unless the sender
+is in possession of the Matching Keypair for that address and the content (not including fields in
+the IPv6 header other than source and destination addresses) has not been altered en-route.
+
+5. It must not be possible to receive a packet which is part of an ESTABLISHED session of that
+packet was already received before.
+
+6. If the permanent private key is compromised, any traffic which was sent during a previous
+ESTABLISHED session which has since ended will not be compromised as a result.
+
+NOTE: Traffic may also be sent when a session is in HANDSHAKE state and for traffic sent while the
+session is in HANDSHAKE state, 5 and 6 may be violated.
+
+7. In the event of a cryptographic break of Curve25519 ECDH (for example using the Shor attack with
+a Quantum Computer) any cryptographic session which was initiated using a password will remain
+as strong as a session which had been initiated using that password as a symmetrical key.
+
+

doc/switchfun.txt

@@ -0,0 +1,294 @@
+## Walking all peers manually on a node using the common 3x5x8 switch scheme.
+## We're exclusively using the 8 form because it's easier to stick to one form
+## The node is 0015 to us, therefor all paths end in 5.
+## The first entry in the 8 form is 0400
+
+user@toshitba:~/wrk/cjdns$ ./contrib/nodejs/tools/splice.js 0000.0000.0000.0400 0000.0000.0000.0015
+0000.0000.0000.4005
+
+## After splicing that with the path to our peer, we clearly see that everything
+## will have a 5 added to the end.
+
+user@toshitba:~/wrk/cjdns$ ./contrib/nodejs/tools/cexec.js 'SwitchPinger_ping("0000.0000.0000.4005", 3000, 1)'
+{
+  "data": "",
+  "key": "xp2f7m98uw24664ngwl47k8uyx59sblgp8qsbpk24sh10ppu9fz0.k",
+  "ms": "382",
+  "path": "0000.0000.0000.4005",
+  "result": "pong",
+  "txid": "824920922",
+  "version": "8"
+}
+
+## 0400 is analogus to 0013 (the first peer)
+
+user@toshitba:~/wrk/cjdns$ ./contrib/nodejs/tools/cexec.js 'SwitchPinger_ping("0000.0000.0000.0135", 3000, 1)'
+{
+  "data": "",
+  "key": "xp2f7m98uw24664ngwl47k8uyx59sblgp8qsbpk24sh10ppu9fz0.k",
+  "ms": "407",
+  "path": "0000.0000.0000.0135",
+  "result": "pong",
+  "txid": "1322201729",
+  "version": "8"
+}
+
+## Since the lowest 2 bits are reserved for specifying the encoding form (they're both 0)
+## numbers count 400, 404, 408, 40c, 410, 414, 418, 41c, 420 ...
+
+user@toshitba:~/wrk/cjdns$ ./contrib/nodejs/tools/cexec.js 'SwitchPinger_ping("0000.0000.0000.4045", 3000, 1)'
+{
+  "data": "",
+  "key": "2v6dt6f841hzhq2wsqwt263w2dswkt6fz82vcyxqptk88mtp8y50.k",
+  "ms": "897",
+  "path": "0000.0000.0000.4045",
+  "result": "pong",
+  "txid": "3621711461",
+  "version": "8"
+}
+
+## This is us, wow, we have slot 3, what luck!
+## the shortest version of this route is 0017
+user@toshitba:~/wrk/cjdns$ ./contrib/nodejs/tools/cexec.js 'SwitchPinger_ping("0000.0000.0000.4085", 3000, 1)'
+{
+  "data": "",
+  "key": "b8xn6kv9279k7mjdmg08ut6yc4n3d2lp3s3juq39qz83z9bzxgz0.k",
+  "ms": "638",
+  "path": "0000.0000.0000.4085",
+  "result": "pong",
+  "txid": "1345867629",
+  "version": "8"
+}
+
+## Oops! If you use a number which is not in the sequence you get a
+## switch error (or perhaps it will be interpreted and end up at another node)
+user@toshitba:~/wrk/cjdns$ ./contrib/nodejs/tools/cexec.js 'SwitchPinger_ping("0000.0000.0000.40d5", 3000, 1)'
+{
+  "data": "",
+  "ms": "539",
+  "path": "0000.0000.0000.40d5",
+  "result": "err_switch",
+  "txid": "3599763113",
+  "version": "0"
+}
+
+user@toshitba:~/wrk/cjdns$ ./contrib/nodejs/tools/cexec.js 'SwitchPinger_ping("0000.0000.0000.40c5", 3000, 1)'
+{
+  "data": "",
+  "key": "lpcvt3u85q837u402dlu3rfg107x92j5xlzd77tftsjy88zx0yf0.k",
+  "ms": "408",
+  "path": "0000.0000.0000.40c5",
+  "result": "pong",
+  "txid": "259944377",
+  "version": "7"
+}
+user@toshitba:~/wrk/cjdns$ ./contrib/nodejs/tools/cexec.js 'SwitchPinger_ping("0000.0000.0000.4105", 3000, 1)'
+{
+  "data": "",
+  "key": "wb0hdx8vu6khpfj32qzhvykjk7gq8bc691czhx3yp7zn04bh5gy0.k",
+  "ms": "363",
+  "path": "0000.0000.0000.4105",
+  "result": "pong",
+  "txid": "1099356221",
+  "version": "8"
+}
+user@toshitba:~/wrk/cjdns$ ./contrib/nodejs/tools/cexec.js 'SwitchPinger_ping("0000.0000.0000.4145", 3000, 1)'
+{
+  "data": "",
+  "key": "6q09l149vz0bqtx51jy557juj39wxmupmfd52h9w5xsdnsns1qj0.k",
+  "ms": "223",
+  "path": "0000.0000.0000.4145",
+  "result": "pong",
+  "txid": "542004376",
+  "version": "7"
+}
+user@toshitba:~/wrk/cjdns$ ./contrib/nodejs/tools/cexec.js 'SwitchPinger_ping("0000.0000.0000.4185", 3000, 1)'
+{
+  "data": "",
+  "key": "1cgrz7hmc4wzg7pu284u5b77y2mdzt261tr0rj0qf7j2vsqf5150.k",
+  "ms": "312",
+  "path": "0000.0000.0000.4185",
+  "result": "pong",
+  "txid": "87763052",
+  "version": "7"
+}
+user@toshitba:~/wrk/cjdns$ ./contrib/nodejs/tools/cexec.js 'SwitchPinger_ping("0000.0000.0000.41c5", 3000, 1)'
+{
+  "data": "",
+  "key": "w7xvbpmgwuwkv8x9wrpfmydtfxv6ydfmpktgc6tt8v8d3c9bn580.k",
+  "ms": "394",
+  "path": "0000.0000.0000.41c5",
+  "result": "pong",
+  "txid": "1682459805",
+  "version": "8"
+}
+user@toshitba:~/wrk/cjdns$ ./contrib/nodejs/tools/cexec.js 'SwitchPinger_ping("0000.0000.0000.4205", 3000, 1)'
+{
+  "data": "",
+  "key": "11sfkq2clbv4dgzgx8hm47p4ld9pwy82y7jluvjh91cyl1n7bwf0.k",
+  "ms": "329",
+  "path": "0000.0000.0000.4205",
+  "result": "pong",
+  "txid": "3712296271",
+  "version": "7"
+}
+user@toshitba:~/wrk/cjdns$ ./contrib/nodejs/tools/cexec.js 'SwitchPinger_ping("0000.0000.0000.4245", 3000, 1)'
+{
+  "data": "",
+  "key": "c94sls20x5shql6r4z4nvqlrs9pcppgj2h41m1bntzk60j5wrs40.k",
+  "ms": "362",
+  "path": "0000.0000.0000.4245",
+  "result": "pong",
+  "txid": "1883792007",
+  "version": "7"
+}
+user@toshitba:~/wrk/cjdns$ ./contrib/nodejs/tools/cexec.js 'SwitchPinger_ping("0000.0000.0000.4285", 3000, 1)'
+{
+  "data": "",
+  "key": "08pdl5mbcpx2b0uh6wj6wktq5v47kv9gpy40rnqr52t1ugctr430.k",
+  "ms": "252",
+  "path": "0000.0000.0000.4285",
+  "result": "pong",
+  "txid": "711411764",
+  "version": "7"
+}
+user@toshitba:~/wrk/cjdns$ ./contrib/nodejs/tools/cexec.js 'SwitchPinger_ping("0000.0000.0000.42c5", 3000, 1)'
+{
+  "data": "",
+  "key": "r5tmqf72mjzht1grqm34l1ldrx9tdubyzw33ucng6bfqp1y0mux0.k",
+  "ms": "452",
+  "path": "0000.0000.0000.42c5",
+  "result": "pong",
+  "txid": "2970256056",
+  "version": "7"
+}
+
+
+## This seems to be a node which is supposed to be connected but is not responding.
+user@toshitba:~/wrk/cjdns$ ./contrib/nodejs/tools/cexec.js 'SwitchPinger_ping("0000.0000.0000.4305", 3000, 1)'
+{
+  "ms": "3003",
+  "path": "0000.0000.0000.4305",
+  "result": "timeout",
+  "txid": "1014318430",
+  "version": "7"
+}
+## Try again for good measure
+user@toshitba:~/wrk/cjdns$ ./contrib/nodejs/tools/cexec.js 'SwitchPinger_ping("0000.0000.0000.4305", 3000, 1)'
+{
+  "ms": "3002",
+  "path": "0000.0000.0000.4305",
+  "result": "timeout",
+  "txid": "2282909610",
+  "version": "7"
+}
+
+
+user@toshitba:~/wrk/cjdns$ ./contrib/nodejs/tools/cexec.js 'SwitchPinger_ping("0000.0000.0000.42c5", 3000, 1)'
+{
+  "data": "",
+  "key": "r5tmqf72mjzht1grqm34l1ldrx9tdubyzw33ucng6bfqp1y0mux0.k",
+  "ms": "181",
+  "path": "0000.0000.0000.42c5",
+  "result": "pong",
+  "txid": "2432582962",
+  "version": "7"
+}
+user@toshitba:~/wrk/cjdns$ ./contrib/nodejs/tools/cexec.js 'SwitchPinger_ping("0000.0000.0000.4345", 3000, 1)'
+{
+  "data": "",
+  "key": "fj9q4s6fg8mjdjfks8lc8bp7ly05qm11z54crlb7tz1pl01fg3r0.k",
+  "ms": "329",
+  "path": "0000.0000.0000.4345",
+  "result": "pong",
+  "txid": "1698617630",
+  "version": "7"
+}
+
+
+## We have either reached the top of the list or there is an empty slot left by a node which
+## disconnected, we can't know for sure so lets ping a few more nodes in order to check.
+user@toshitba:~/wrk/cjdns$ ./contrib/nodejs/tools/cexec.js 'SwitchPinger_ping("0000.0000.0000.4385", 3000, 1)'
+{
+  "data": "",
+  "ms": "158",
+  "path": "0000.0000.0000.4385",
+  "result": "err_switch",
+  "txid": "880013604",
+  "version": "0"
+}
+user@toshitba:~/wrk/cjdns$ ./contrib/nodejs/tools/cexec.js 'SwitchPinger_ping("0000.0000.0000.43c5", 3000, 1)'
+{
+  "data": "",
+  "ms": "444",
+  "path": "0000.0000.0000.43c5",
+  "result": "err_switch",
+  "txid": "1175469204",
+  "version": "0"
+}
+user@toshitba:~/wrk/cjdns$ ./contrib/nodejs/tools/cexec.js 'SwitchPinger_ping("0000.0000.0000.4405", 3000, 1)'
+{
+  "data": "",
+  "ms": "347",
+  "path": "0000.0000.0000.4405",
+  "result": "err_switch",
+  "txid": "3258844093",
+  "version": "0"
+}
+user@toshitba:~/wrk/cjdns$ ./contrib/nodejs/tools/cexec.js 'SwitchPinger_ping("0000.0000.0000.4445", 3000, 1)'
+{
+  "data": "",
+  "ms": "321",
+  "path": "0000.0000.0000.4445",
+  "result": "err_switch",
+  "txid": "869243597",
+  "version": "0"
+}
+user@toshitba:~/wrk/cjdns$ 
+
+
+
+
+
+
+
+## Recall from above that we're 0408 aka 0017 (because we can be represented using the small encoding)
+## ping selves
+user@toshitba:~/wrk/cjdns$ ./contrib/nodejs/tools/cexec.js 'SwitchPinger_ping("0000.0000.0000.0175", 3000, 1)'{
+  "data": "",
+  "key": "b8xn6kv9279k7mjdmg08ut6yc4n3d2lp3s3juq39qz83z9bzxgz0.k",
+  "ms": "619",
+  "path": "0000.0000.0000.0175",
+  "result": "pong",
+  "txid": "1099734707",
+  "version": "8"
+}
+## just to verify that it's working, we'll create a loop packet
+## us->them->us->them and it works.
+user@toshitba:~/wrk/cjdns$ ./contrib/nodejs/tools/cexec.js 'SwitchPinger_ping("0000.0000.0000.1575", 3000, 1)'
+{
+  "data": "",
+  "key": "nx6k81p1nxw1b5ry8ub5u63hu0tlskp1t2fytcbrbf1709xh11g0.k",
+  "ms": "1251",
+  "path": "0000.0000.0000.1575",
+  "result": "pong",
+  "txid": "3109463617",
+  "version": "8"
+}
+## We can make it loop more but the latency gets very big!
+user@toshitba:~/wrk/cjdns$ ./contrib/nodejs/tools/cexec.js 'SwitchPinger_ping("0000.0001.7575.7575", 3000, 1)'
+{
+  "data": "",
+  "key": "b8xn6kv9279k7mjdmg08ut6yc4n3d2lp3s3juq39qz83z9bzxgz0.k",
+  "ms": "1900",
+  "path": "0000.0001.7575.7575",
+  "result": "pong",
+  "txid": "2807636566",
+  "version": "8"
+}
+
+## This only works because we and our peer are both using 3x5x8 encoding, if they were using
+## something different, it would still be possible but more complex to craft paths.
+## nodes describe their encoding schemes to one another so even the most complex encoding
+## schemes are supported by cjdns which has to craft paths through the network much like
+## we did here.

doc/tunnel.md

@@ -0,0 +1,181 @@
+# IpTunnel - Tunneling IPv4 and IPv6 through a cjdns network
+
+IpTunnel is designed to make it easy to access The Old Internet through cjdns.
+The way you get to the internet is via "gate" nodes which hand you an address
+the same way as a traditional VPN service would. TOR users might think of it as
+"exit nodes" for cjdns, the main difference is with cjdns you need to ask permission
+from the gate operator before (ab)using their gateway.
+
+
+## Updating your cjdroute.conf
+
+First compare your cjdroute.conf file to a newly generated one, if your cjdroute.conf
+file is old, there are two changes which you will need to include. In the `router` section
+you will need to add a subsection called `IpTunnel`.
+
+        // System for tunneling IPv4 and ICANN IPv6 through cjdns.
+        // This is using the cjdns switch layer as a VPN carrier.
+        "ipTunnel":
+        {
+            lots
+            of stuff here
+            see the real version
+            by running ./cjdroute --genconf
+        },
+
+You may also have to modity the `setuser` section in the `security` block, there is
+a new field called `exemptAngel` which needs to be set in order for cjdns to have
+permission to set the IPv6 and IPv4 addresses on the TUN device.
+
+        // Change the user id to this user after starting up and getting resources.
+        {
+            "setuser": "nobody"
+
+            // Exempt the Angel process from setting userId, the Angel is a small
+            // isolated piece of code which exists outside of the core's strict
+            // sandbox but does not handle network traffic.
+            // This must be enabled for IpTunnel to automatically set IP addresses
+            // for the TUN device.
+            "exemptAngel": 1
+        }
+
+
+## Connecting to a gateway
+
+To connect to an IPv6 gate, you must first ask the operator of the gate to add your
+key to his gate, once he has added it, add their *key* to the `outgoingConnections`
+section of the `IpTunnel` block in your cjdroute.conf like this:
+
+    "outgoingConnections":
+    [
+        // John's gate
+        "d5d0wu0usrkuThisIsJustAnExampleThisIsFake63uqlnk2kb0.k"
+    ]
+
+Then restart cjdns and after a few moments you should see it add IP addresses to your TUN device by running
+`ifconfig` for example:
+
+    tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
+              inet addr:192.168.10.4  P-t-P:192.168.10.4  Mask:255.255.255.255
+              inet6 addr: fc88:dfd0:89d4:abfe:de2:a17a:6ed5:6fb1/8 Scope:Global
+              inet6 addr: 2a02:2498:e000:20::144:4/0 Scope:Global                 <--- new address
+              UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1312  Metric:1
+              RX packets:22950 errors:0 dropped:0 overruns:0 frame:0
+              TX packets:22891 errors:0 dropped:0 overruns:0 carrier:0
+              collisions:0 txqueuelen:500
+              RX bytes:22689370 (22.6 MB)  TX bytes:2460363 (2.4 MB)
+
+Then you can try pinging a computer out on the internet like `ipv6.google.com` and see if
+it works.
+
+
+
+## Running a gateway
+
+Running your own gateway is not automated, so you will want to implement some scripts to
+set the addresses for you. Lets imagine your ISP has given you the IPv6 prefix
+`1111:1111:1111:1111::/64` and your ISP's router is `1111:1111:1111:1111::1`. Your ethernet
+card is probably set to `1111:1111:1111:1111::2` so you'll begin allocating above that.
+First you will have to reserve one address (eg: `1111:1111:1111:1111::3`) for your `tun0`
+device's address, then each client can have an address, so the first client will be issued
+`1111:1111:1111:1111::4`, the second `1111:1111:1111:1111::5` and so on.
+
+First edit your cjdroute.conf and add the clients who will be connecting to your gate.
+It's always a good idea to add some identification with the connect block so you know who
+it is for later.
+
+            "allowedConnections":
+            [
+                // Bill Smith's connection
+                {
+                    "publicKey": "f64hfl7c4uxt6krmhPutTheRealAddressOfANodeHere7kfm5m0.k",
+                    "ip6Address": "1111:1111:1111:1111::4",
+                    "ip6Prefix": 0
+                }
+            ]
+
+Note the `ip6Prefix` field: it specifies the netmask that the client should use.
+We have set it to 0, so the client will think the entire IPv6 addfress space is
+accessible over the tunnel (which it is, since we're building a
+cjdns-to-clearnet gateway). This avoids us having to set up an IPv6 default
+gateway manually on the client node. If you want to advertise a smaller network
+to your clients (like just the `1111:1111:1111:1111::/64` network), set this to
+the appropriate value (in this case, 64).
+
+When you start cjdroute, the IP address for the TUN device will *not* be set automatically,
+so you must set that next with the following command:
+
+    ip -6 addr add dev tun0 1111:1111:1111:1111::3
+
+Now that your tun device has an address, your client should be able to connect to and
+ping `1111:1111:1111:1111::3`, but it definitely won't be able to reach the rest of the
+world until you add a static route on the gateway to your ISP's router's address: `1111:1111:1111:1111::1`.
+This will make it route over the ethernet device and add a static route to allow the rest of
+your /64 to route down the TUN device. Once you're finished, you'll want to set a default
+route via your ISP's router's address so outgoing IPv6 packets are forwarded correctly.
+
+    ip -6 route add dev eth0 1111:1111:1111:1111::1
+    ip -6 route add dev tun0 1111:1111:1111:1111::0/64
+    ip -6 route add default via 1111:1111:1111:1111::1
+
+Finally you will need to enable IPv6 forwarding, to do this, run:
+
+    echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
+
+and to make it permanent, edit your `/etc/sysctl.conf` file and *uncomment* the line which says:
+
+    #net.ipv6.conf.all.forwarding=1
+
+
+
+Connect the client to the gateway using cjdns and wait a few moments until you've obtained the ipv6
+address associated with the tunnel. Now, test the connection by attempting to ping the ipv6 address
+associated with the gateway on the tunnel, and if this succeeds you can try to ping an external ipv6
+address like `ipv6.google.com` too if you're expecting internet traffic to be routed through.
+
+Now if all went well your job is done, but if the connection isn't working yet you should continue on to
+the next section and try to figure out why.
+
+
+## It doesn't work
+
+First, check to make sure you don't have any iptables rules against forwarding or ones that might be
+blocking your connection in any way. You should also make sure a processes called 'radvd' isn't running
+(at least to rule out as a cause until you have things working) since it seems to be capable of causing
+some routing issues.
+
+Now ensure the client is still connected to the gateway through cjdns, and that it still has an ipv6
+address associated with the tunnel, then try pinging the gateway or an internet ipv6 address again with
+the client. On the gateway, run `tcpdump -n -i tun0` to see if any packets get as far as the tun device, and
+if nothing scrolls with the ipv6 associated with your client's on the tunnel, you should check your routes
+to make sure they're correct by running `ip -6 route`. The output should include four lines that look similar
+to the ones below (take special note of which device is associated with each line).
+
+1111:1111:1111:1111:1111:1111:1111:1 dev eth0 metric 1024
+1111:1111:1111:1111:1111:1111:1111:3 dev tun0 proto kernel metric 256
+1111:1111:1111:1111:1111:1111:1111:0/64 dev tun0 metric 1024
+default via 1111:1111:1111:1111:1111:1111:1111:1 dev eth0 metric 1024
+
+If your routes are correct and things still aren't working, continue to let the ping process run on the client
+and run `tcpdump -n -i eth0 icmp6` on the gateway to check the traffic flowing through its ethernet device.
+Look for any connections to or from the ipv6 address associated with your client on the tunnel, and if you see
+any with strange messages about "neighbor solicitation" or "neighbor advertisement", the problem is that your
+ISP's equipment is dropping replies instead of routing return traffic despite the addresses in use being
+allocated to you. This problem exists because of something called NDP (Neighbor Discovery Protocol), in which a
+request for 'neighbours' is made, and traffic isn't allowed to be sent back unless the ISP receives a response.
+Thankfully, there is a workaround available that involves running a daemon called `npd6`, which provides a
+response that satisfies NDP. Install npd6 through your distro's package management system if it's available,
+(recent debian based distrobutions may be able to install the package located here:
+http://code.google.com/p/npd6/downloads/list) otherwise you'll have to download and build it yourself by doing
+the following:
+
+    wget http://npd6.googlecode.com/files/npd6-1.0.0.tar.gz
+    tar -xf ./npd-1.0.0.tar.gz
+    cd npd6-1.0.0/
+    make && sudo make install
+
+Once this is built, copy `npd6-1.0.0/etc/npd6.conf.sample` to `/etc/ndp6.conf`, and change the prefix to
+`1111:1111:1111:1111:0000:0000:0000:0002/64` (2 because you're announcing `1111:1111:1111:1111::2` and higher,
+but not `1111:1111:1111:1111::1` which belongs to your ISP's router). Note that in this particular instance,
+you can't ignore 0s when writing out your ipv6 or npd6 will complain when you attempt to run it. If npd6 fails
+to start, try running `npd6 -l npd6.log` to write a log in the local directory.

doc/windows.md

@@ -0,0 +1,51 @@
+# Building for Windows
+
+* If you're trying to build **on** windows, forget it, you wouldn't build software for an iPhone
+**on** an iPhone...
+
+## Build Prerequisites
+
+Install mingw32
+
+For Ubuntu 14.04:
+
+    sudo apt-get install mingw-w64
+    
+For older Ubuntu:
+
+    sudo apt-get install gcc-mingw32
+
+
+## Build Process
+
+Cross-compile cjdns with the following command:
+
+    SYSTEM=win32 CROSS_COMPILE=i686-w64-mingw32- ./cross-do
+
+## Run-time Dependencies
+
+On your Windows machine, you need the TAP driver installed to allow cjdns to create its virtual network interface. You can get it from the OpenVPN project at their [main download page](https://openvpn.net/index.php/open-source/downloads.html), under "Tap-windows", or use [this direct link to version 9.9.2_3](http://swupdate.openvpn.org/community/releases/tap-windows-9.9.2_3.exe).
+    
+Check name of your new virtual connection it must contain only english letters or numbers
+## Installation
+
+Once the TAP driver is installed, copy the `cjdroute.exe` file over to your windows machine.
+
+Generate a configuration file with:
+
+    cjdroute --genconf > cjdroute.conf
+    
+You probably want to uncomment the `"logTo":"stdout"` line so that you can see any error messages in your terminal.
+
+Then, execute cjdns from an elevated command prompt:
+
+    cjdroute --nobg < cjdroute.conf
+    
+The `--nobg` option is required; otherwise cjdns just quits.
+
+The first time you start it, a Windows firewall dialog will probably pop up. *Make sure to allow cjdns to accept connections from the Internet.*
+
+## Next Steps
+
+Congratulations! You are now running cjdns on Windows! Go find some peers!
+