Browse Source

sync 'upstream/dev' into dev

pull/224/head
Logan007 5 years ago
parent
commit
a9e48bb353
  1. 2
      Makefile.in
  2. 67
      README.md
  3. 29
      android/BUILD.txt
  4. 33
      android/README.md
  5. 4
      autogen.sh
  6. 4
      doc/IPv6.md
  7. 11
      doc/MTU.md
  8. 5
      doc/NEW_FEATURES.txt
  9. 35
      doc/Routing.md
  10. 22
      doc/Windows.md
  11. 12
      doc/macOS.md
  12. 19
      doc/n2n_on_MacOS.txt
  13. 4
      doc/new-features.md
  14. 4
      doc/rpm-packaging.md
  15. 2
      edge.c
  16. 4
      sn.c
  17. 2
      tuntap_osx.c

2
Makefile.in

@ -7,7 +7,7 @@ GIT_COMMITS=@GIT_COMMITS@
CC?=gcc CC?=gcc
DEBUG?=-g3 DEBUG?=-g3
#OPTIMIZATION?=-O2 OPTIMIZATION?=-O3
WARN?=-Wall WARN?=-Wall
#Ultrasparc64 users experiencing SIGBUS should try the following gcc options #Ultrasparc64 users experiencing SIGBUS should try the following gcc options

67
README.md

@ -1,21 +1,19 @@
# N2N # N2N
N2n is a light VPN software which make it easy to create virtual networks bypassing intermediate firewalls. N2N is a light VPN software which make it easy to create virtual networks bypassing intermediate firewalls.
In order to start using N2N, two elements are required: In order to start using N2N, two elements are required:
- A *supernode*: it allows edge nodes to announce and discover other nodes. It must have a port publicly accessible on internet. - A _supernode_: it allows edge nodes to announce and discover other nodes. It must have a port publicly accessible on internet.
- _edge_ nodes: the nodes which will be part of the virtual networks
- *Edge* nodes: the nodes which will be part of the virtual networks A virtual network shared between multiple edge nodes in n2n is called a _community_. A single supernode can relay multiple communities and a single PC can be part of multiple communities at the same time. An encryption key can be used by the edge nodes to encrypt the packets within their community.
A virtual network shared between multiple edge nodes in n2n is called a *community*. A single supernode can relay multiple communities and a single PC can be part of multiple communities at the same time. An encryption key can be used by the edge nodes to encrypt the packets within their community. N2N tries to establish a direct P2P connection between the edge nodes when possible. When this is not possible (usually due to special NAT devices), the supernode is also used to relay the packets.
N2n tries to enstablish a direct P2P connection between the edge nodes when possible. When this is not possible (usually due to special NAT devices), the supernode is also used to relay the packets. ## Quick Setup
Quick Setup Some Linux distributions already provide n2n as a package so a simple `sudo apt install n2n` will do the work. Alternatively, up to date packages for most distributions are available on [ntop repositories](http://packages.ntop.org/).
-----------
Some linux distributions already provide n2n as a package so a simple `sudo apt-get install n2n` will do the work. Alternatively, up to date packages for most distributions are available on [ntop repositories](http://packages.ntop.org/).
On host1 run: On host1 run:
@ -31,12 +29,11 @@ $ sudo edge -c mynetwork -k mysecretpass -a 192.168.100.2 -f -l supernode.ntop.o
Now the two hosts can ping each other. Now the two hosts can ping each other.
**IMPORTANT** It is strongly adviced to choose a custom community name (-c) and a secret encryption key (-k) in order to prevent other users to connect to your PC. For privacy and to reduce the above server load, it is also suggested to set up a custom supernode as exmplained below. **IMPORTANT** It is strongly advised to choose a custom community name (`-c`) and a secret encryption key (`-k`) in order to prevent other users to connect to your PC. For privacy and to reduce the above server load, it is also suggested to set up a custom supernode as explained below.
Setting up a custom Supernode ## Setting up a custom Supernode
-----------------------------
You can create your own infrastructure by setting up a supernode on a public server (e.g. a VPS). You just need to open a single port (1234 in the example below) on your firewall (usually iptables). You can create your own infrastructure by setting up a supernode on a public server (e.g. a VPS). You just need to open a single port (1234 in the example below) on your firewall (usually `iptables`).
1. Install the n2n package 1. Install the n2n package
2. Edit `/etc/n2n/supernode.conf` and add the following: 2. Edit `/etc/n2n/supernode.conf` and add the following:
@ -48,8 +45,7 @@ You can create your own infrastructure by setting up a supernode on a public ser
Now the supernode service should be up and running on port 1234. On your edge nodes you can now specify `-l your_supernode_ip:1234` to use it. All the edge nodes must use the same supernode. Now the supernode service should be up and running on port 1234. On your edge nodes you can now specify `-l your_supernode_ip:1234` to use it. All the edge nodes must use the same supernode.
Routing the traffic ## Routing the traffic
-------------------
On linux, n2n provides a standard TAP interface, so routing works gracefully via the standard system utilities as follows. On linux, n2n provides a standard TAP interface, so routing works gracefully via the standard system utilities as follows.
@ -77,12 +73,11 @@ $ sudo ip route del default
$ sudo ip route add default via 192.168.100.1 $ sudo ip route add default via 192.168.100.1
``` ```
This process can be greatly simplified by using the [n2n_gateway.sh](https://github.com/ntop/n2n/blob/dev/doc/n2n_gateway.sh) script. This process can be greatly simplified by using the [n2n_gateway.sh](doc/n2n_gateway.sh) script.
See [Routing.md](https://github.com/ntop/n2n/blob/dev/doc/Routing.md) for other use cases and in depth explanation. See [Routing.md](doc/Routing.md) for other use cases and in depth explanation.
Manual Compilation ## Manual Compilation
------------------
On linux, compilation from source is straight forward: On linux, compilation from source is straight forward:
@ -96,11 +91,9 @@ make install
``` ```
For Windows, check out [Windows.md](doc/Windows.md) for compilation and run instuctions. For Windows, check out [Windows.md](doc/Windows.md) for compilation and run instuctions.
For MacOS, check out [macOS.md](doc/macOS.md).
For MacOS, check out [n2n_on_MacOS.txt](https://github.com/ntop/n2n/blob/dev/doc/n2n_on_MacOS.txt). ## Running edge as a service
Running edge as a service
-------------------------
edge can also be run as a service instead of cli: edge can also be run as a service instead of cli:
@ -111,16 +104,14 @@ edge can also be run as a service instead of cli:
You can run multiple edge service instances by creating `/etc/n2n/edge-instance1.conf` and You can run multiple edge service instances by creating `/etc/n2n/edge-instance1.conf` and
starting it with `sudo systemctl start edge@instance1`. starting it with `sudo systemctl start edge@instance1`.
IPv6 Support ## IPv6 Support
------------
N2n can tunnel IPv6 traffic into the virtual network but does not support N2N can tunnel IPv6 traffic into the virtual network but does not support
IPv6 for edge-to-supernode communication yet. IPv6 for edge-to-supernode communication yet.
Check out [IPv6.md](https://github.com/ntop/n2n/blob/dev/doc/IPv6.md) for more information. Check out [IPv6.md](https://github.com/ntop/n2n/blob/dev/doc/IPv6.md) for more information.
Security considerations ## Security considerations
-----------------------
n2n edge nodes use twofish encryption by default for compatibility reasons with existing versions. n2n edge nodes use twofish encryption by default for compatibility reasons with existing versions.
@ -135,26 +126,26 @@ so it is recommended to enable it on all the edge nodes by specifying the `-A` o
A benchmark of the encryption methods is available when compiled from source with `tools/n2n-benchmark`. A benchmark of the encryption methods is available when compiled from source with `tools/n2n-benchmark`.
Contribution ## Contribution
------------
You can contribute to n2n in variuos ways: You can contribute to n2n in various ways:
- Update an [open issue](https://github.com/ntop/n2n/issues) or create a new one with detailed information - Update an [open issue](https://github.com/ntop/n2n/issues) or create a new one with detailed information
- Propose new features - Propose new features
- Improve the documentation - Improve the documentation
- Provide pull requests with enhancenents - Provide pull requests with enhancements
For details about the internals of n2n check out [Hacking guide](https://github.com/ntop/n2n/blob/dev/doc/HACKING). For details about the internals of n2n check out [Hacking guide](https://github.com/ntop/n2n/blob/dev/doc/HACKING).
Related Projects ## Related Projects
----------------
Here is a list of third-party projects connected to this repository. Here is a list of third-party projects connected to this repository.
- N2n for android: [hin2n](https://github.com/switch-iot/hin2n) - N2N for Android: [hin2n](https://github.com/switch-iot/hin2n)
- N2n v1 and v2 version from meyerd: [meyerd n2n](https://github.com/meyerd/n2n) - N2N v1 and v2 version from meyerd: [meyerd n2n](https://github.com/meyerd/n2n)
- Docker images: [DockerHub](https://hub.docker.com/r/supermock/supernode/) - [DockerStore](https://store.docker.com/community/images/supermock/supernode/) - Docker images: [Docker Hub](https://hub.docker.com/r/supermock/supernode/)
- Go bindings, management daemons and CLIs for n2n edges and supernodes, Docker, Kubernetes & Helm Charts: [pojntfx/gon2n](https://pojntfx.github.io/gon2n/)
---
-----------------
(C) 2007-2019 - ntop.org and contributors (C) 2007-2019 - ntop.org and contributors

29
android/BUILD.txt

@ -1,29 +0,0 @@
- Install jdk.
- Generate app keystore by commond keytool -genkey -alias Hin2n -keystore Hin2n.jks. And remember these two passwords:
keytool -genkey -dname "CN=Unknown,O=Unknown,C=Unknown" -keystore Hin2n.jks -keysize 1024 -alias Hin2nalias -validity 14000 -keypass yourpassword -storepass yourpassword
- Move Hin2n.jks to android/Hin2n/app directory. We will use this file to sign the application
- In the file app/build.gradle replace "yourpassword" with the password used to generate the keystore.
- Download android tools from https://developer.android.com/, and unzip it.
- Install android development environment.
echo y | ./tools/bin/sdkmanager tools
echo y | ./tools/bin/sdkmanager platform-tools
echo y | ./tools/bin/sdkmanager ndk-bundle
echo y | ./tools/bin/sdkmanager "cmake;3.6.4111459"
echo y | ./tools/bin/sdkmanager "lldb;3.1"
- Set environment variables.
export ANDROID_HOME=YOUE_ANDROID_DEV_HOME
export ANDROID_NDK_HOME=$ANDROID_HOME/ndk-bundle
export HIN2N_KSTOREPWD=YOUR_APP_KEYSTORE_PASSWORD
export HIN2N_KEYPWD=YOUR_APP_KEY_PASSWORD
- Compile the app.
cd android/Hin2n
./gradlew assemble
- You will get the app in android/Hin2n/app/build/outputs/apk/ directory.

33
android/README.md

@ -0,0 +1,33 @@
# Building n2n on Android
- Install jdk.
- Generate app keystore by the command `keytool -genkey -alias Hin2n -keystore Hin2n.jks`. And remember these two passwords:
```bash
keytool -genkey -dname "CN=Unknown,O=Unknown,C=Unknown" -keystore Hin2n.jks -keysize 1024 -alias Hin2nalias -validity 14000 -keypass yourpassword -storepass yourpassword
```
- Move `Hin2n.jks` to `android/Hin2n/app` directory. We will use this file to sign the application.
- In the file `app/build.gradle` replace `yourpassword` with the password used to generate the keystore.
- Download Android tools from https://developer.android.com/, and unzip it.
- Install Android development environment.
```bash
echo y | ./tools/bin/sdkmanager tools
echo y | ./tools/bin/sdkmanager platform-tools
echo y | ./tools/bin/sdkmanager ndk-bundle
echo y | ./tools/bin/sdkmanager "cmake;3.6.4111459"
echo y | ./tools/bin/sdkmanager "lldb;3.1"
```
- Set environment variables.
```bash
export ANDROID_HOME=YOUE_ANDROID_DEV_HOME
export ANDROID_NDK_HOME=\$ANDROID_HOME/ndk-bundle
export HIN2N_KSTOREPWD=YOUR_APP_KEYSTORE_PASSWORD
export HIN2N_KEYPWD=YOUR_APP_KEY_PASSWORD
```
- Compile the app.
```bash
cd android/Hin2n
./gradlew assemble
```
- You will get the app in `android/Hin2n/app/build/outputs/apk/` directory.

4
autogen.sh

@ -2,8 +2,8 @@
# NOTE: update version in CMakeLists.txt after changing these # NOTE: update version in CMakeLists.txt after changing these
N2N_MAJOR="2" N2N_MAJOR="2"
N2N_MINOR="5" N2N_MINOR="7"
N2N_PATCH="1" N2N_PATCH="0"
N2N_VERSION_SHORT="$N2N_MAJOR.$N2N_MINOR.$N2N_PATCH" N2N_VERSION_SHORT="$N2N_MAJOR.$N2N_MINOR.$N2N_PATCH"

4
doc/IPv6.md

@ -1,3 +1,5 @@
# IPv6
n2n supports the carriage of IPv6 packets within the n2n tunnel. N2n does not n2n supports the carriage of IPv6 packets within the n2n tunnel. N2n does not
yet use IPv6 for transport between edges and supernodes. yet use IPv6 for transport between edges and supernodes.
@ -5,7 +7,7 @@ To make IPv6 carriage work you need to manually add IPv6 addresses to the TAP
interfaces at each end. There is currently no way to specify an IPv6 address on interfaces at each end. There is currently no way to specify an IPv6 address on
the edge command line. the edge command line.
eg. under linux: Eg. under linux:
on hostA: on hostA:
`[hostA] $ /sbin/ip -6 addr add fc00:abcd:1234::7/48 dev n2n0` `[hostA] $ /sbin/ip -6 addr add fc00:abcd:1234::7/48 dev n2n0`

11
doc/MTU.md

@ -1,5 +1,4 @@
MTU # MTU
---
The MTU of the VPN interface is set to a lower value (rather than the standard The MTU of the VPN interface is set to a lower value (rather than the standard
1500 B value) to avoid excessive fragmentation on the datagram sent on internet. 1500 B value) to avoid excessive fragmentation on the datagram sent on internet.
@ -27,8 +26,7 @@ MTU of the path between two hosts. Knowing the PMTU is also useful for a sender
avoid fragmentation at the IP level. Trying to find the biggest MTU is useful since it allows to avoid fragmentation at the IP level. Trying to find the biggest MTU is useful since it allows to
maximize bandwidth. maximize bandwidth.
PMTU Discovery Failures ## PMTU Discovery Failures
-----------------------
Most operating systems try to periodically discover the PMTU by using a PMTU discovery algorithm. Most operating systems try to periodically discover the PMTU by using a PMTU discovery algorithm.
This involves setting the DF (don't fragment) flag on the IP packets. When a large IP packet exceeds This involves setting the DF (don't fragment) flag on the IP packets. When a large IP packet exceeds
@ -40,18 +38,15 @@ The main problem when this situation occurs is that the actual PMTU is unknown,
solution is not applicable. The user must manually specify a lower MTU for the VPN interface solution is not applicable. The user must manually specify a lower MTU for the VPN interface
in order to solve the issue. in order to solve the issue.
n2n and MTU ## n2n and MTU
-----------
n2n should work by default in different environments. For this reason, the following solution n2n should work by default in different environments. For this reason, the following solution
has been provided: has been provided:
- PMTU discovery is disabled when possible (via the IP_MTU_DISCOVER socket option). This avoid - PMTU discovery is disabled when possible (via the IP_MTU_DISCOVER socket option). This avoid
silently dropping a oversize packet due to the DF flag, however it possibly increments fragmentation on the path. silently dropping a oversize packet due to the DF flag, however it possibly increments fragmentation on the path.
- As examplained above, a lower MTU is set on the VPN interface, thus removing excessive fragmentation on - As examplained above, a lower MTU is set on the VPN interface, thus removing excessive fragmentation on
the sender. the sender.
- 1400 B is used instead of 1500 B as the reference value for the internet interface MTU. - 1400 B is used instead of 1500 B as the reference value for the internet interface MTU.
This essentially avoids fragmentation when the PMTU is >= 1400 B. This essentially avoids fragmentation when the PMTU is >= 1400 B.

5
doc/NEW_FEATURES.txt

@ -1,5 +0,0 @@
Between 2.0.x and 2.1.x
* Better ming Windows build support.
* Added -E flag to allow multicast ethernet traffic.

35
doc/Routing.md

@ -1,5 +1,7 @@
# IPv4 Routing (Linux) # IPv4 Routing (Linux)
## Assumptions ## Assumptions
- There are two Local Area Networks, namely 10.11.12.0/24 (maybe at - There are two Local Area Networks, namely 10.11.12.0/24 (maybe at
**h**ome) and 192.168.1.0/24 (maybe in **o**ffice). **h**ome) and 192.168.1.0/24 (maybe in **o**ffice).
- These networks are connected to the internet via routers 10.11.12.1 - These networks are connected to the internet via routers 10.11.12.1
@ -13,8 +15,8 @@ devices shall be called _n2n0_, and their n2n IP addresses are
- The _iptables_ are flushed. - The _iptables_ are flushed.
## Prerequisites ## Prerequisites
- Both, **h**ickory and **o**scar have ip forwarding enabled: `echo 1 >
/proc/sys/net/ipv4/ip_forward` or `sysctl -w net.ipv4.ip_forward=1`. To - Both, **h**ickory and **o**scar have ip forwarding enabled: `echo 1 > /proc/sys/net/ipv4/ip_forward` or `sysctl -w net.ipv4.ip_forward=1`. To
make this setting persistent over reboot, a file containing the line make this setting persistent over reboot, a file containing the line
`net.ipv4.ip_forward=1` could be added in /etc/sysctl.d/ – your distro `net.ipv4.ip_forward=1` could be added in /etc/sysctl.d/ – your distro
may vary. may vary.
@ -27,11 +29,9 @@ any further configuration.
- To make **h**ickory send all packets with office destination via - To make **h**ickory send all packets with office destination via
**o**scar, **h**ickory needs to be made aware of where to route this **o**scar, **h**ickory needs to be made aware of where to route this
packets to. On **h**ickory: `ip route add 192.168.1.0/24 via 10.99.99.60 packets to. On **h**ickory: `ip route add 192.168.1.0/24 via 10.99.99.60 dev n2n0 src 10.11.12.5`.
dev n2n0 src 10.11.12.5`.
- **o**scar needs to know where to send packets to, too. So, on - **o**scar needs to know where to send packets to, too. So, on
**o**scar: `ip route add 10.11.12.5 via 10.99.99.50 dev n2n0 src **o**scar: `ip route add 10.11.12.5 via 10.99.99.50 dev n2n0 src 192.168.1.6`.
192.168.1.6`.
**o**scar and **h**ickory should now be able to exchange packets by **o**scar and **h**ickory should now be able to exchange packets by
using just their regular (non-n2n) IP addresses 10.11.12.5 and 192.168.1.6. using just their regular (non-n2n) IP addresses 10.11.12.5 and 192.168.1.6.
@ -41,23 +41,21 @@ sent to **h**ickory, one more step is required:
- Packets from any office computer to **h**ickory need to be directed to - Packets from any office computer to **h**ickory need to be directed to
**o**scar that – thanks to enabled IP forwarding and the routing rule – **o**scar that – thanks to enabled IP forwarding and the routing rule –
already knows how to handle this kind of packets. already knows how to handle this kind of packets.
* To handle it in a one-stop-shop, the office router 192.168.1.1 can - To handle it in a one-stop-shop, the office router 192.168.1.1 can
be configured to direct those packets to **o**scar. Luckily, even most be configured to direct those packets to **o**scar. Luckily, even most
modern small-office-and-home routers allow to add static routing rules modern small-office-and-home routers allow to add static routing rules
via a web interface. A rule like "All packets for host 10.11.12.5 (or via a web interface. A rule like "All packets for host 10.11.12.5 (or
network 10.11.12.0/24) need to be sent to another router, namely network 10.11.12.0/24) need to be sent to another router, namely
192.168.1.5" will do. This is the **recommended** solution. 192.168.1.5" will do. This is the **recommended** solution.
* However, a **less recommended** but working option would be to add - However, a **less recommended** but working option would be to add
static routes to each single of those computers in the office network static routes to each single of those computers in the office network
that shall be able to connect to or be accessed by **h**ickory. On that shall be able to connect to or be accessed by **h**ickory. On
those, e.g. **o**livia with IP address 192.168.1.123: `ip route add those, e.g. **o**livia with IP address 192.168.1.123: `ip route add 10.11.12.5 via 192.168.1.5 dev eth0 src 192.168.1.123`.
10.11.12.5 via 192.168.1.5 dev eth0 src 192.168.1.123`. - Alternatively, in case the office router does not allow to have
* Alternatively, in case the office router does not allow to have
added own static routing rules, **o**scar needs to perform NAT for all added own static routing rules, **o**scar needs to perform NAT for all
connections initiated from **h**ickory: connections initiated from **h**ickory:
`iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE` `iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE`
`iptables -A FORWARD -i eth0 -o n2n0 -m state --state `iptables -A FORWARD -i eth0 -o n2n0 -m state --state RELATED,ESTABLISHED -j ACCEPT`
RELATED,ESTABLISHED -j ACCEPT`
`iptables -A FORWARD -i n2n0 -o eth0 -j ACCEPT` `iptables -A FORWARD -i n2n0 -o eth0 -j ACCEPT`
There is a major drawback with this solution which thus is the **least There is a major drawback with this solution which thus is the **least
recommended**: Connections between **h**ickory and the office network recommended**: Connections between **h**ickory and the office network
@ -80,6 +78,7 @@ By the way, in case _iptables_ are messed up, they can be flushed by:
## Reach n2n Node in Office from Whole Home Network ## Reach n2n Node in Office from Whole Home Network
This is easy: This is easy:
- Just exchange home and office IP addresses and the computer names in - Just exchange home and office IP addresses and the computer names in
the instructions given above. the instructions given above.
@ -87,10 +86,10 @@ the instructions given above.
This is not too complicated either. Basically, follow the given example This is not too complicated either. Basically, follow the given example
above and apply the following changes: above and apply the following changes:
- The instructions used above need to be expanded from **h**ickory's IP - The instructions used above need to be expanded from **h**ickory's IP
10.11.12.5 to its full network 10.11.12.0/24 in the route commands on 10.11.12.5 to its full network 10.11.12.0/24 in the route commands on
**o**scar:, especially: `ip route add 10.11.12.0/24 via 10.99.99.50 dev **o**scar:, especially: `ip route add 10.11.12.0/24 via 10.99.99.50 dev n2n0 src 192.168.1.6`.
n2n0 src 192.168.1.6`.
- In case of adding a static route to the office network router - In case of adding a static route to the office network router
192.168.1.1, the home network 10.11.12.0/24 must be specified instead of 192.168.1.1, the home network 10.11.12.0/24 must be specified instead of
**h**ickory's more specific IP address 11.11.12.5. Same for the less **h**ickory's more specific IP address 11.11.12.5. Same for the less
@ -118,8 +117,7 @@ usually denies forwarding to packets not originating from its own
network. It could be in addition to the eventually installed static network. It could be in addition to the eventually installed static
routes for 10.11.12.0/24 in the router 192.168.1.1 or on other office routes for 10.11.12.0/24 in the router 192.168.1.1 or on other office
computers – it will not interfere. However, **o**scar definitely needs computers – it will not interfere. However, **o**scar definitely needs
the route given above: `ip route add 10.11.12.5 via 10.99.99.50 dev n2n0 the route given above: `ip route add 10.11.12.5 via 10.99.99.50 dev n2n0 src 192.168.1.6`.
src 192.168.1.6`.
- To have **h**ickory's complete internet traffic going through the n2n - To have **h**ickory's complete internet traffic going through the n2n
tunnel, its default route needs to be changed: tunnel, its default route needs to be changed:
`ip route del default` `ip route del default`
@ -131,8 +129,7 @@ route. If not, i.e. it was only covered by default route before, it
needs to be added: `ip route add 10.11.12.0/24 dev eth0 src 10.11.12.5`. needs to be added: `ip route add 10.11.12.0/24 dev eth0 src 10.11.12.5`.
- Unfortunately (unless the supernode is on **h**ickory's local - Unfortunately (unless the supernode is on **h**ickory's local
network), n2n supernode becomes unreachable for **h**ickory. To fix it: network), n2n supernode becomes unreachable for **h**ickory. To fix it:
`ip route add <supernode IP address> via 10.11.12.1 dev eth0 src `ip route add <supernode IP address> via 10.11.12.1 dev eth0 src 10.11.12.5`
10.11.12.5`
The supernode's IP address needs to be known to have this work. However, The supernode's IP address needs to be known to have this work. However,
if the supernode's IP needs to be resolved from some domain name (FQDN), if the supernode's IP needs to be resolved from some domain name (FQDN),

22
doc/Windows.md

@ -1,19 +1,22 @@
# Requirements # Build on Windows
## Requirements
In order to build on Windows the following tools should be installed: In order to build on Windows the following tools should be installed:
- Visual Studio. For a minimal install, the command line only build tools can be - 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 downloaded and installed from https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-2017
- Cmake - Cmake
- (optional) The OpenSSL library. Prebuild binaries can be downloaded from https://slproweb.com/products/Win32OpenSSL.html . - (optional) The OpenSSL library. Prebuild binaries can be downloaded from https://slproweb.com/products/Win32OpenSSL.html .
The full version is required (not the "Light" version). The Win32 version of it is usually required for a standard build. The full version is required (not the "Light" version). The Win32 version of it is usually required for a standard build.
NOTE: in order to skip OpenSSL compilation, edit CMakeLists.txt and replace NOTE: in order to skip OpenSSL compilation, edit CMakeLists.txt and replace
```plaintext
OPTION(N2N_OPTION_AES "USE AES" ON) OPTION(N2N_OPTION_AES "USE AES" ON)
with with
OPTION(N2N_OPTION_AES "USE AES" OFF) OPTION(N2N_OPTION_AES "USE AES" OFF)
```
NOTE: to static link OpenSSL, add the `-DOPENSSL_USE_STATIC_LIBS=true` option to the cmake command NOTE: to static link OpenSSL, add the `-DOPENSSL_USE_STATIC_LIBS=true` option to the cmake command
@ -21,15 +24,14 @@ In order to run n2n:
- The TAP drivers should be installed into the system. They can be installed from - The TAP drivers should be installed into the system. They can be installed from
http://build.openvpn.net/downloads/releases (search for "tap-windows") http://build.openvpn.net/downloads/releases (search for "tap-windows")
- If OpenSSL has been linked dynamically, the corresponding .dll file should be available - If OpenSSL has been linked dynamically, the corresponding .dll file should be available
into the target computer into the target computer
# Build (CLI) ## Build (CLI)
In order to build from the command line, open a terminal window and run the following commands: In order to build from the command line, open a terminal window and run the following commands:
``` ```batch
md build md build
cd build cd build
cmake .. cmake ..
@ -39,17 +41,17 @@ MSBuild supernode.vcxproj /t:Build /p:Configuration=Release
``` ```
NOTE: if cmake has problems finding the installed OpenSSL library, try to download the official cmake and invoke it with: NOTE: if cmake has problems finding the installed OpenSSL library, try to download the official cmake and invoke it with:
"C:\Program Files\CMake\bin\cmake" `C:\Program Files\CMake\bin\cmake`
The compiled exe files should now be available under the Release directory. The compiled exe files should now be available under the Release directory.
# Run ## Run
The `edge.exe` program reads the `edge.conf` file located into the current directory if no option is provided. The `edge.exe` program reads the `edge.conf` file located into the current directory if no option is provided.
Here is an example `edge.conf` file: Here is an example `edge.conf` file:
``` ```plaintext
-c=mycommunity -c=mycommunity
-k=mysecretkey -k=mysecretkey
@ -64,7 +66,7 @@ The `supernode.exe` program reads the `supernode.conf` file located into the cur
Here is an example `supernode.conf` file: Here is an example `supernode.conf` file:
``` ```plaintext
-l=5678 -l=5678
``` ```

12
doc/macOS.md

@ -0,0 +1,12 @@
# n2n 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).

19
doc/n2n_on_MacOS.txt

@ -1,19 +0,0 @@
Using n2n on MacOS
------------------
In order to use n2n on MacOS you need to first install support for the tap interface.
if you are a brew (https://brew.sh) user you can do it in a couple of steps
- brew tap homebrew/cask
- brew cask install tuntap
Note that in the latest OS versions (for instance MacOS High Sierra), you may need to
need to enable their 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

4
doc/new-features.md

@ -0,0 +1,4 @@
# New Features between 2.0.x and 2.1.x
- Better ming Windows build support.
- Added `-E` flag to allow multicast ethernet traffic.

4
doc/Centos.md → doc/rpm-packaging.md

@ -1,6 +1,6 @@
# Packaging # RPM Packaging
``` ```bash
./autogen.sh ./autogen.sh
./configure ./configure
make make

2
edge.c

@ -598,6 +598,7 @@ static void daemonize() {
static int keep_on_running; static int keep_on_running;
#ifdef __linux__
#ifdef WIN32 #ifdef WIN32
BOOL WINAPI term_handler(DWORD sig) BOOL WINAPI term_handler(DWORD sig)
#else #else
@ -619,6 +620,7 @@ static void term_handler(int sig)
return(TRUE); return(TRUE);
#endif #endif
} }
#endif
/* *************************************************** */ /* *************************************************** */

4
sn.c

@ -913,6 +913,7 @@ static int loadFromFile(const char *path, n2n_sn_t *sss) {
/* *************************************************** */ /* *************************************************** */
#ifdef __linux__
static void dump_registrations(int signo) { static void dump_registrations(int signo) {
struct sn_community *comm, *ctmp; struct sn_community *comm, *ctmp;
struct peer_info *list, *tmp; struct peer_info *list, *tmp;
@ -941,11 +942,13 @@ static void dump_registrations(int signo) {
traceEvent(TRACE_NORMAL, "===================================="); traceEvent(TRACE_NORMAL, "====================================");
} }
#endif
/* *************************************************** */ /* *************************************************** */
static int keep_running; static int keep_running;
#ifdef __linux__
#ifdef WIN32 #ifdef WIN32
BOOL WINAPI term_handler(DWORD sig) BOOL WINAPI term_handler(DWORD sig)
#else #else
@ -967,6 +970,7 @@ static void term_handler(int sig)
return(TRUE); return(TRUE);
#endif #endif
} }
#endif
/* *************************************************** */ /* *************************************************** */

2
tuntap_osx.c

@ -47,7 +47,7 @@ int tuntap_open(tuntap_dev *device /* ignored */,
if(device->fd < 0) { if(device->fd < 0) {
traceEvent(TRACE_ERROR, "Unable to open any tap devices /dev/tap0 through /dev/tap254. Is this user properly authorized to access those descriptors?"); traceEvent(TRACE_ERROR, "Unable to open any tap devices /dev/tap0 through /dev/tap254. Is this user properly authorized to access those descriptors?");
traceEvent(TRACE_ERROR, "Please read https://github.com/ntop/n2n/blob/dev/doc/n2n_on_MacOS.txt"); traceEvent(TRACE_ERROR, "Please read https://github.com/ntop/n2n/blob/dev/doc/macOS.md");
return(-1); return(-1);
} else { } else {
char buf[256]; char buf[256];

Loading…
Cancel
Save