Blame

772daa Samuli Seppänen 2025-03-18 13:04:35 1
# Using development versions of OpenVPN 
2
3
## Getting OpenVPN snapshots
4
5
We offer several different kinds of development builds and snapshots:
6
7
* [http://build.openvpn.net/downloads/snapshots/ Windows installers built from every commit]
8
* FreeBSD *openvpn-devel* port. Also usable as a standalone source snapshot on other platforms.
9
10
Note that these snapshots are either *entirely untested* or tested only very briefly. So there are no guarantees that they work correctly. That said, most of the time they probably work just fine.
11
12
## Fetching sources using git
13
14
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](/CodeRepositories).
15
16
## Source for OpenVPN for Android
17
18
Source code for OpenVPN for Android is available [on GitHub](https://github.com/schwabe/ics-openvpn).
19
20
## Source for OpenVPN Connect (android/IOS)
21
22
The latest source code snapshot for OpenVPN 3 is available [http://staging.openvpn.net/openvpn3/ here].
23
24
## Building
25
26
If you're using source snapshots / ports you can extract them like this:
27
28
```
29
gzip -dc openvpn-<something>.tar.gz | tar xvf -
30
cd openvpn-<something>/
31
```
32
33
With Git you can skip this step. Next prepare for building (not required for stable releases):
34
35
36
```
37
autoreconf -vi
38
```
39
40
Next configure (see *./configure --help* for available build-time options):
41
42
```
43
./configure
44
```
45
46
Finally compile:
47
48
```
49
make [-j <num CPU cores + 1>]
50
```
51
52
Once you've ran *make*, you can install OpenVPN using
53
54
```
55
make install
56
```
57
58
### Building on MacOS X with homebrew
59
60
Homebrew does not install the openssl libraries in the standard paths. If you get errors like `Undefined symbols for architecture x86_64: "_SSL_CTX_get0_certificate" ...`, you need to pass `CPPFLAGS`/`LDFLAGS` (the correct values are shown by `brew info openssl`).
61
62
```
63
make [-j <num CPU cores + 1>] CPPFLAGS=-I/usr/local/opt/openssl/include LDFLAGS=-L/usr/local/opt/openssl/lib
64
```
65
66
# TAP-driver debugging
67
68
Please take a look [here](/Pages/ManagingWindowsTAPDrivers).
69
70
# OpenVPN Debugging
71
72
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:
73
74
```
75
$ gdb /usr/sbin/openvpn
76
[gdb info message...blablabla...]
77
(gdb) run --config <your config file> [--other-arguments-you-might-pass]
78
[wait for the crash]
79
(gdb) bt
80
[full backtrace should appear]
81
```
82
83
# Enable core dump
84
85
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.
86
87
```
88
$ ulimit -c unlimited
89
```
90
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.
91
92
```
93
$ gdb openvpn {core file}
94
[gdb info message...blablabla...]
95
(gdb) bt
96
[full backtrace should appear]
97
```
98
99
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.
100
101
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.
102
103
# Reporting bugs
104
105
OpenVPN issues are tracked in GitHub now: See https://github.com/OpenVPN/openvpn/issues
106
107
Old issues can be found here in Trac: https://community.openvpn.net/openvpn/report
108
109
If you're not sure if your problem is really a bug, you can ask about it on [OpenVPN support channels](/GettingHelp).
110
111
If you've genuinely found a bug, have a look if the same issue has been reported before, and if it has been fixed already. If you've found a new, unfixed bug, make sure you know [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html how to report bugs efficiently]; good bug reports help resolve the problem quickly. In each bug report you should document a few things:
112
113
* Operating system (e.g. OpenBSD 4.3)
114
* The complete output of *openvpn --version*, or...
115
* ...the full filename of the Windows installer you used
116
* Relevant parts of OpenVPN client and/or server logs (when available) at *verb 5* verbosity (see the [man page](https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/))
117
* If you built OpenVPN youself: the *./configure* command line you used
118
119
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:
120
121
* [http://book.git-scm.com/5_finding_issues_-_git_bisect.html Finding Issues - Git Bisect]
122
* [http://progit.org/book/ch6-5.html Debugging with Git]
123
124
Bisecting is an advanced technique and you're not expected to do it before filing bug reports.