wiki:TesterDocumentation

Using development versions of OpenVPN

Getting OpenVPN snapshots

We offer several different kinds of development builds and snapshots:

  • Windows installers. Typically released every 1-2 weeks. Available here.
  • Binary packages for various Linux distribution. Hosted in our apt/yum repos. Typically released every 1-2 weeks.
  • FreeBSD openvpn-devel port (Backup). Also usable as a standalone source snapshot on other platforms.

Note that all of these snapshots are either entirely untested or tested only very briefly. So no guarantees of their proper operation is given. That said, most of the time they probably work just fine.

Fetching sources using git

Second option is to fetch sources using Git. This method is preferred, as it allows you to easily keep using the latest code. For instructions take a look here.

Building

If you're using source snapshots / ports you can extract them like this:

gzip -dc openvpn-<something>.tar.gz | tar xvf -
cd openvpn-<something>/

With Git you can skip this step. Next prepare for building (not required for stable releases):

autoreconf -vi

Next configure (see ./configure --help for available build-time options):

./configure

Finally compile:

make [-j <num CPU cores + 1>]

Once you've ran make, you can install OpenVPN using

make install

TAP-driver debugging

Please take a look here.

OpenVPN Debugging

If OpenVPN crashes, you can help developers figure out the problem by giving them a backtrace of the crash. If you're running released (stable) version of OpenVPN, you should install the openvpn debug and gdb packages and then run openvpn via gdb. On "testing" turn on debugging before compilation. In either case you can get a backtrace of the crash like this:

$ gdb /usr/sbin/openvpn
[gdb info message...blablabla...]
(gdb) run --config <your config file> [--other-arguments-you-might-pass]
[wait for the crash]
(gdb) bt
[full backtrace should appear]

Enable core dump

In some cases, it's not possible to trigger the bug when running via gdb directly. In this case, you can enable core dumps. On most distributions and *nix OSes today, you need to enable this from your shell before starting OpenVPN.

$ ulimit -c unlimited

Then run OpenVPN with the normal arguments. When OpenVPN crashes, it will now most likely create a core file which can be used for debugging the state of OpenVPN when it crashed.

$ gdb openvpn {core file}
[gdb info message...blablabla...]
(gdb) bt
[full backtrace should appear]

Please save the core files for a little while before deleting them. It might be that the developers would ask for a copy of the core file in some situations, to investigate more carefully the state OpenVPN was in when it crashed. But be also aware of that these core files can (will most likely) contain sensitive data, like encryption keys and certificates. So share with care.

Beware that if you start OpenVPN via init scripts, it will most likely not dump core files, unless you change the ulimit inside the init script.

Reporting bugs

First, you should know how to report bugs efficiently. In each bug report you should document a few things:

  • Operating system (e.g. OpenBSD 4.3)
  • Your ./configure command-line
  • The complete output of openvpn --version

Whenever possible, also provide logs with appropriate log level (5 or greater) from both the client and server; see --verb in OpenVPN man-page for details. Only include the log sections that are relevant to the bug, e.g. with something like this:

$ tail -n 0 -f <openvpn-log-file>

Note that if you're testing out a new feature or trying to reproduce a bug, we'd like to have both success and failure reports.

If the bug you've found is a regression and you want to see it fixed as soon as possible, you can help by doing a Git bisect. This technique is described here:

If you manage to find the commit that caused the regression, fixing it is much easier for the developers.

Last modified 17 months ago Last modified on 11/15/12 08:06:43

Attachments (1)

Download all attachments as: .zip