release/src/router/openvpn/PORTS

   1 OpenVPN
   2 Copyright (C) 2002-2009 OpenVPN Technologies, Inc. <sales@openvpn.net>
   3
   4   OpenVPN has been written to try to avoid features
   5   that are not standardized well across different
   6   OSes, so porting OpenVPN itself will probably be
   7   straightforward if a tun or tap driver already exists.
   8
   9   Where special OS features are used, they are usually
  10   bracketed with #ifdef HAVE_SOME_FUNCTION.
  11
  12 PLATFORM STATUS:
  13
  14   * Linux 2.2+ (supported)
  15   * Solaris (supported)
  16   * OpenBSD 3.0 (supported but pthreads are broken)
  17   * Max OS X Darwin
  18   * FreeBSD
  19   * NetBSD
  20   * Windows
  21   * 64 bit platforms -- I have heard reports that
  22     OpenVPN runs on Alpha Linux and FreeBSD.
  23   * ARM -- I have heard of at least one case
  24     where OpenVPN was successfully built and
  25     run on the ARM architecture.
  26
  27 PORTING NOTES:
  28
  29   * Make sure that OpenSSL will build on your
  30     platform.
  31   * Make sure that a tun or tap virtual device
  32     driver exists for your platform.  See
  33     http://vtun.sourceforge.net/tun/ for examples
  34     of tun and tap drivers that have been written
  35     for Linux, Solaris, and FreeBSD.
  36   * Make sure you have autoconf 2.50+ and
  37     automake 1.6+.
  38   * Edit configure.ac, adding platform specific
  39     config code, and a TARGET_YOUROS define.
  40   * Add platform-specific includes to syshead.h.
  41   * Add an #ifdef TARGET_YOUROS to the do_ifconfig()
  42     function in tun.c to generate a correct "ifconfig"
  43     command for your platform.  Note that OpenVPN
  44     determines the ifconfig path at ./configure time.
  45   * Add an ifconfig_order() variant for your OS so
  46     openvpn knows whether to call ifconfig before
  47     or after tun/tap dev open.
  48   * Add an #ifdef TARGET_YOUROS block in tun.c and define
  49     the open_tun, close_tun, read_tun, and write_tun
  50     functions.  If your tun/tap virtual device is
  51     sufficiently generic, you may be able to use the
  52     default case.
  53   * Add appropriate code to route.c to handle
  54     the route command on your platform.  This
  55     is necessary for the --route option to
  56     work correctly.
  57   * After you successfully build OpenVPN, run
  58     the loopback tests as described in INSTALL.
  59   * For the next test, confirm that the UDP socket
  60     functionality is working independently of the
  61     tun device, by doing something like:
  62       ./openvpn --remote localhost --verb 9 --ping 1 --dev null
  63   * Now try with --remote [a real host]
  64   * Now try with a real tun/tap device, you will
  65     need to figure out the appropriate ifconfig
  66     command to use once openvpn has opened the tun/tap
  67     device.
  68   * Once you have simple tests working on the tun device,
  69     try more complex tests such as using TLS mode.
  70   * Stress test the link by doing ping -f across it.
  71   * Make sure that packet fragmenting is happening
  72     correctly by doing a ping -s 2000 or higher.
  73   * Ensure that OpenVPN on your platform will talk
  74     to OpenVPN on other platforms such as Linux.
  75     Some tun/tap driver implementations will prepend
  76     unnecessary stuff onto the datagram that must be
  77     disabled with an explicit ioctl call if cross-platform
  78     compatibility is to be preserved.  You can see some
  79     examples of this in tun.c.
  80   * If your system supports pthreads, try building
  81     with ./configure --enable-pthread and do a stress
  82     test in TLS mode.
  83   * Try the ultimate stress test which is --gremlin
  84     --reneg-sec 10 in TLS mode (preferably with pthreads
  85     enabled), then do a flood ping across the tunnel
  86     (ping -f remote-endpoint) in both directions and let
  87     it run overnight.  --gremlin will induce massive
  88     corruption and packet loss, but you win if you
  89     wake up the next morning and both peers are still
  90     running and occasionally even succeeding in their
  91     attempted once-per-10-seconds TLS handshake.
  92   * When it's working, submit your patch to
  93     <openvpn-devel@lists.sourceforge.net>
  94     and rejoice :)