This is the start of the BETA21 branch.

It includes the --topology feature, and
TAP-Win32 driver changes to allow
non-admin access.



git-svn-id: http://svn.openvpn.net/projects/openvpn/branches/BETA21/openvpn@580 e7ae566f-a301-0410-adde-c780ea21d3b5

1 files changed, 94 insertions, 0 deletions

diff --git a/PORTS b/PORTS
new file mode 100644
index 0000000..f0967a7
--- /dev/null
+++ b/PORTS
@@ -0,0 +1,94 @@
+OpenVPN
+Copyright (C) 2002-2005 OpenVPN Solutions LLC <info@openvpn.net>
+
+  OpenVPN has been written to try to avoid features
+  that are not standardized well across different
+  OSes, so porting OpenVPN itself will probably be
+  straightforward if a tun or tap driver already exists.
+
+  Where special OS features are used, they are usually
+  bracketed with #ifdef HAVE_SOME_FUNCTION.
+
+PLATFORM STATUS:
+
+  * Linux 2.2+ (supported)
+  * Solaris (supported)
+  * OpenBSD 3.0 (supported but pthreads are broken)
+  * Max OS X Darwin
+  * FreeBSD
+  * NetBSD
+  * Windows
+  * 64 bit platforms -- I have heard reports that
+    OpenVPN runs on Alpha Linux and FreeBSD.
+  * ARM -- I have heard of at least one case
+    where OpenVPN was successfully built and
+    run on the ARM architecture.
+
+PORTING NOTES:
+
+  * Make sure that OpenSSL will build on your
+    platform.
+  * Make sure that a tun or tap virtual device
+    driver exists for your platform.  See
+    http://vtun.sourceforge.net/tun/ for examples
+    of tun and tap drivers that have been written
+    for Linux, Solaris, and FreeBSD.
+  * Make sure you have autoconf 2.50+ and
+    automake 1.6+.
+  * Edit configure.ac, adding platform specific
+    config code, and a TARGET_YOUROS define.
+  * Add platform-specific includes to syshead.h.
+  * Add an #ifdef TARGET_YOUROS to the do_ifconfig()
+    function in tun.c to generate a correct "ifconfig"
+    command for your platform.  Note that OpenVPN
+    determines the ifconfig path at ./configure time.
+  * Add an ifconfig_order() variant for your OS so
+    openvpn knows whether to call ifconfig before
+    or after tun/tap dev open.
+  * Add an #ifdef TARGET_YOUROS block in tun.c and define
+    the open_tun, close_tun, read_tun, and write_tun
+    functions.  If your tun/tap virtual device is
+    sufficiently generic, you may be able to use the
+    default case.
+  * Add appropriate code to route.c to handle
+    the route command on your platform.  This
+    is necessary for the --route option to
+    work correctly.
+  * After you successfully build OpenVPN, run
+    the loopback tests as described in INSTALL.
+  * For the next test, confirm that the UDP socket
+    functionality is working independently of the
+    tun device, by doing something like:
+      ./openvpn --remote localhost --verb 9 --ping 1 --dev null
+  * Now try with --remote [a real host]
+  * Now try with a real tun/tap device, you will
+    need to figure out the appropriate ifconfig
+    command to use once openvpn has opened the tun/tap
+    device.
+  * Once you have simple tests working on the tun device,
+    try more complex tests such as using TLS mode.
+  * Stress test the link by doing ping -f across it.
+  * Make sure that packet fragmenting is happening
+    correctly by doing a ping -s 2000 or higher.
+  * Ensure that OpenVPN on your platform will talk
+    to OpenVPN on other platforms such as Linux.
+    Some tun/tap driver implementations will prepend
+    unnecessary stuff onto the datagram that must be
+    disabled with an explicit ioctl call if cross-platform
+    compatibility is to be preserved.  You can see some
+    examples of this in tun.c.
+  * If your system supports pthreads, try building
+    with ./configure --enable-pthread and do a stress
+    test in TLS mode.
+  * Try the ultimate stress test which is --gremlin
+    --reneg-sec 10 in TLS mode (preferably with pthreads
+    enabled), then do a flood ping across the tunnel
+    (ping -f remote-endpoint) in both directions and let
+    it run overnight.  --gremlin will induce massive
+    corruption and packet loss, but you win if you
+    wake up the next morning and both peers are still
+    running and occasionally even succeeding in their
+    attempted once-per-10-seconds TLS handshake. 
+  * When it's working, submit your patch to
+    <openvpn-devel@lists.sourceforge.net>
+    and rejoice :)