1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
|
This document describes the process for compiling n2n in several different
scenarios.
There are some configuration options available during the build process,
which are documented in the [Build time Configuration](BuildConfig.md) page.
Also of use are the steps used for the automated Continuous Integration
process, which can be found in the [Github actions config file](../.github/workflows/tests.yml)
# Git submodules
If you are compiling with the UPnP libraries, it is possible that your
operating system or your build system do not include binaries for the
required libraries.
Using these libraries can cause issues with some build systems, so be
aware that not all combinations are supportable.
To make this scenario simpler, the required source code has been added
to this repository as git `submodules` which require one extra step to
complete their checkout.
So the very first time after cloning the n2n git repo, you should run
this command in the n2n directory to fetch the submodules:
```bash
git submodule update --init --recursive
```
# Build on macOS
In order to use n2n on macOS, you first need to install support for TUN/TAP interfaces:
```bash
brew tap homebrew/cask
brew cask install tuntap
```
If you are on a modern version of macOS (i.e. Catalina), the commands above will ask you to enable the TUN/TAP kernel extension in System Preferences → Security & Privacy → General.
For more information refer to vendor documentation or the [Apple Technical Note](https://developer.apple.com/library/content/technotes/tn2459/_index.html).
Note that on the newest MacOS versions and on Apple Silicon, there may be
increasing security restrictions in the OS that make installing the TUN/TAP
kernel extension difficult. Alternative software implementations to avoid
these difficulties are being discussed for future n2n versions.
# Build on Windows
The following document some possible windows compile recipes. Of them, the
MinGW build process is more tested as it is more friendly to open source
development.
## Visual Studio
### Requirements
In order to build with Vidual Studio on Windows the following tools should be installed:
- Visual Studio. For a minimal install, the command line only build tools can be
downloaded and installed from https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-2017.
- CMake (From https://cmake.org/download/)
NOTE: You should always use the official cmake stable release as otherwise
you may have issues finding libraries (e.g: the installed OpenSSL library).
If you still have problems, you can try invoking it with `C:\Program Files\CMake\bin\cmake`.
- (optional) The OpenSSL library. This optional library can be enabled as
per the steps in the [Build time Configuration](BuildConfig.md)
Pre-built OpenSSL binaries can be downloaded from
https://slproweb.com/products/Win32OpenSSL.html.
The full version is required, i.e. not the "Light" version. The Win32
version of it is usually required for a standard build.
### CLI steps
In order to build from the command line, open a terminal window change to
the directory where the git checkout of this repository is and run the
following commands:
Building using `cmake` works as follows:
```batch
cmake -E make_directory build
cd build
rem Append any options to the next line
cmake ..
cmake --build . --config Release
```
The compiled `.exe` files should now be available in the `build\Release` directory.
## MinGW
These steps were tested on a fresh install of Windows 10 Pro with all patches
applied as of 2021-09-29.
- Install Chocolatey (Following instructions on https://chocolatey.org/install)
- from an admin cmd prompt
- `choco install git mingw make`
- All the remaining commands must be run from inside a bash shell ("C:\Program Files\Git\usr\bin\bash.exe")
- `git clone $THIS_REPO`
- `cd n2n`
- `./scripts/hack_fakeautoconf.sh`
- `make`
- `make test`
Due to limitations in the Windows environment, the normal autotools steps have
been emulated by the `hack_fakeautoconf` - This currently results in the
version number reported by the compiled software being inaccurate.
Note: MinGW builds have had a history of incompatibility reports with other OS
builds (for example [#617](https://github.com/ntop/n2n/issues/617) and [#642](https://github.com/ntop/n2n/issues/642))
However, if the tests pass, you should have a high confidence that your build
will be compatible.
## Run on Windows
In order to run n2n on Windows, you will need the following:
- The TAP drivers should be installed into the system. They can be installed from
http://build.openvpn.net/downloads/releases, search for "tap-windows".
- If OpenSSL has been linked dynamically, the corresponding `.dll` file should be available
onto the target computer.
The `edge.exe` program reads the `edge.conf` file located into the current directory if no option is provided.
The `supernode.exe` program reads the `supernode.conf` file located into the current directory if no option is provided.
Example [edge.conf](../packages/etc/n2n/edge.conf.sample)
and [supernode.conf](../packages/etc/n2n/supernode.conf.sample) are available.
See `edge.exe --help` and `supernode.exe --help` for a full list of supported options.
# Cross compiling on Linux
## Using the Makefiles and Autoconf
The Makefiles are all setup to allow cross compiling of this code. You
will need to have the cross compiler, binutils and any additional libraries
desired installed for the target architecture. Then you can run the `./configure`
with the appropriate CC and AR environment and the right `--host` option.
If compiling on Debian or Ubuntu, this can be as simple as the following example:
```
HOST_TRIPLET=arm-linux-gnueabi
sudo apt-get install binutils-$HOST_TRIPLET gcc-$HOST_TRIPLET
./autogen.sh
export CC=$HOST_TRIPLET-gcc
export AR=$HOST_TRIPLET-ar
./configure --host $HOST_TRIPLET
make
```
A good starting point to determine the host triplet for your destination platform
can be found by copying the `./config.guess` script to it and running it on the
destination.
This is not a good way to produce binaries for embedded environments (like OpenWRT)
as they will often use a different libc environment.
# N2N Packages
There are also some example package build recipes included with the source.
- [Debian](../packages/debian/README)
- [RPM](../packages/rpm)
- [OpenWRT](../packages/openwrt/README.md)
|
