summaryrefslogtreecommitdiff
path: root/bitmask_android/openvpn/PORTS
diff options
context:
space:
mode:
authorParménides GV <parmegv@sdf.org>2014-04-08 12:04:17 +0200
committerParménides GV <parmegv@sdf.org>2014-04-08 12:04:17 +0200
commit3c3421afd8f74a3aa8d1011de07a8c18f9549210 (patch)
tree49d52344661c23d7268b8ea69466a1cfef04bf8b /bitmask_android/openvpn/PORTS
parent5fc5d37330d3535a0f421632694d1e7918fc22d7 (diff)
Rename app->bitmask_android
This way, gradle commands generate apks correctly named.
Diffstat (limited to 'bitmask_android/openvpn/PORTS')
-rw-r--r--bitmask_android/openvpn/PORTS94
1 files changed, 94 insertions, 0 deletions
diff --git a/bitmask_android/openvpn/PORTS b/bitmask_android/openvpn/PORTS
new file mode 100644
index 00000000..735493c7
--- /dev/null
+++ b/bitmask_android/openvpn/PORTS
@@ -0,0 +1,94 @@
+OpenVPN
+Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@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 :)