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

This reverts commit 55c7f45.

Author: Lars Gierth

doc/CjdnsModules.odg

@@ -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/CjdnsModules.png

@@ -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/Seccomp.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.
+