Rename project in all documentation, installed directories, cli tools…

… and user visible strings

.github/workflows/openwrt.yml

@@ -35,26 +35,26 @@ jobs:
           echo "OPENWRT_REF=$(git rev-parse --short HEAD)" >> $GITHUB_ENV
           git rev-parse --short HEAD
 
-      - name: Checkout n2n
+      - name: Checkout
         uses: actions/checkout@v2
         with:
-          path: n2n
+          path: src
           fetch-depth: 0
 
       - name: Fix Checkout
         run: |
           git fetch --force --tags
-        working-directory: n2n
+        working-directory: src
 
-      - name: Set n2n ref
+      - name: Set ref
         run: |
           echo "N2N_REF=$(./scripts/version.sh)" >> $GITHUB_ENV
           ./scripts/version.sh
-        working-directory: n2n
+        working-directory: src
 
-      - name: Copy n2n package definition into openwrt
+      - name: Copy src package definition into openwrt
         run: |
-          cp -r n2n/packages/openwrt openwrt/package/n2n
+          cp -r src/packages/openwrt openwrt/package/n3n
         working-directory: ./
 
       - name: Cache openwrt source downloads
@@ -68,10 +68,10 @@ jobs:
           echo "CONFIG_TARGET_x86=y" >.config
           echo "CONFIG_TARGET_x86_64=y" >>.config
 
-      - name: Add n2n package to openwrt config
+      - name: Add package to openwrt config
         run: |
-          echo "CONFIG_PACKAGE_n2n-edge=m" >>.config
-          echo "CONFIG_PACKAGE_n2n-supernode=m" >>.config
+          echo "CONFIG_PACKAGE_n3n-edge=m" >>.config
+          echo "CONFIG_PACKAGE_n3n-supernode=m" >>.config
 
       - name: Build a full config from our stub file
         run: |
@@ -85,19 +85,19 @@ jobs:
         run: |
           make -j `nproc` tools/install toolchain/install
 
-      - name: Build n2n dependancies
+      - name: Build dependancies
         run: |
           make -j `nproc` package/libs/libpcap/compile
 
-      - name: Build n2n openwrt packages
+      - name: Build openwrt packages
         env:
           N2N_PKG_VERSION: ${{ env.N2N_REF }}
         run: |
           echo "Build for $N2N_PKG_VERSION"
           export N2N_PKG_VERSION
-          make package/n2n/clean V=s
-          make package/n2n/prepare USE_SOURCE_DIR=$GITHUB_WORKSPACE/n2n V=s
-          make package/n2n/compile V=s
+          make package/n3n/clean V=s
+          make package/n3n/prepare USE_SOURCE_DIR=$GITHUB_WORKSPACE/n3n V=s
+          make package/n3n/compile V=s
 
 # FIXME: add a way to run the test suite!
 #      - name: Run embedded tests

.github/workflows/tests.yml

@@ -509,33 +509,33 @@ jobs:
           mv openwrt-sdk-* openwrt
         working-directory: ./
 
-      - name: Checkout n2n
+      - name: Checkout
         uses: actions/checkout@v3
         with:
-          path: n2n
+          path: src
           fetch-depth: 0
 
       - name: Fix Checkout
         run: |
           git fetch --force --tags
-        working-directory: n2n
+        working-directory: src
 
-      - name: Copy n2n package definition into openwrt
+      - name: Copy package definition into openwrt
         run: |
-          cp -r n2n/packages/openwrt openwrt/package/n2n
+          cp -r src/packages/openwrt openwrt/package/n3n
         working-directory: ./
 
       - name: Configure OpenWrt
         run: |
           make defconfig
 
-      - name: Build n2n openwrt packages
+      - name: Build openwrt packages
         run: |
-          export N2N_PKG_VERSION=$(../n2n/scripts/version.sh)
+          export N2N_PKG_VERSION=$(../n3n/scripts/version.sh)
           echo "Build for $N2N_PKG_VERSION"
-          make package/n2n/clean V=s
-          make package/n2n/prepare USE_SOURCE_DIR=$GITHUB_WORKSPACE/n2n V=s
-          make package/n2n/compile V=s
+          make package/n3n/clean V=s
+          make package/n3n/prepare USE_SOURCE_DIR=$GITHUB_WORKSPACE/n3n V=s
+          make package/n3n/compile V=s
 
 # FIXME: add a way to run the test suite!
 #      - name: Run embedded tests

.gitignore

@@ -15,11 +15,11 @@ example_edge_embed_quick_edge_init
 example_edge_embed
 example_sn_embed
 supernode
-tools/n2n-benchmark
-tools/n2n-decode
-tools/n2n-keygen
-tools/n2n-portfwd
-tools/n2n-route
+tools/n3n-benchmark
+tools/n3n-decode
+tools/n3n-keygen
+tools/n3n-portfwd
+tools/n3n-route
 build
 .idea
 .vscode

Makefile

@@ -60,7 +60,7 @@ MAN1DIR=$(MANDIR)/man1
 MAN7DIR=$(MANDIR)/man7
 MAN8DIR=$(MANDIR)/man8
 
-N2N_LIB=libn2n.a
+N2N_LIB=libn3n.a
 N2N_OBJS=\
 	src/aes.o \
 	src/auth.o \
@@ -137,13 +137,13 @@ LINT_CCODE=\
 	tools/tests-transform.c \
 	tools/tests-wire.c \
 
-LDLIBS+=-ln2n
+LDLIBS+=-ln3n
 LDLIBS+=$(LDLIBS_EXTRA)
 
 APPS=edge$(EXE)
 APPS+=supernode$(EXE)
 
-DOCS=edge.8.gz supernode.1.gz n2n.7.gz
+DOCS=edge.8.gz supernode.1.gz n3n.7.gz
 
 # This is the list of Debian/Ubuntu packages that are needed during the build.
 # Mostly of use in automated build systems.
@@ -222,7 +222,7 @@ test.integration: $(APPS)
 lint: lint.python lint.ccode lint.shell lint.yaml
 
 lint.python:
-	flake8 scripts/n2n-ctl scripts/n2n-httpd
+	flake8 scripts/n3n-ctl scripts/n3n-httpd
 
 lint.ccode:
 	scripts/indent.sh $(LINT_CCODE)
@@ -280,22 +280,22 @@ distclean:
 	rm -f tests/*.out src/*.gcno src/*.gcda src/*.indent src/*.unc-backup*
 	rm -rf autom4te.cache/
 	rm -f config.mak config.log config.status configure include/config.h include/config.h.in
-	rm -f edge.8.gz n2n.7.gz supernode.1.gz
-	rm -f edge supernode libn2n.a
+	rm -f edge.8.gz n3n.7.gz supernode.1.gz
+	rm -f edge supernode libn3n.a
 	rm -f packages/debian/config.log packages/debian/config.status
 	rm -rf packages/debian/autom4te.cache/
 	rm -f packages/rpm/config.log packages/rpm/config.status
 	rm -f $(addprefix src/,$(APPS))
 
 .PHONY: install
-install: edge$(EXE) supernode$(EXE) edge.8.gz supernode.1.gz n2n.7.gz
+install: edge$(EXE) supernode$(EXE) edge.8.gz supernode.1.gz n3n.7.gz
 	echo "MANDIR=$(MANDIR)"
 	$(MKDIR) $(SBINDIR) $(MAN1DIR) $(MAN7DIR) $(MAN8DIR)
 	$(INSTALL_PROG) supernode$(EXE) $(SBINDIR)/
 	$(INSTALL_PROG) edge$(EXE) $(SBINDIR)/
 	$(INSTALL_DOC) edge.8.gz $(MAN8DIR)/
 	$(INSTALL_DOC) supernode.1.gz $(MAN1DIR)/
-	$(INSTALL_DOC) n2n.7.gz $(MAN7DIR)/
+	$(INSTALL_DOC) n3n.7.gz $(MAN7DIR)/
 	$(MAKE) -C tools install SBINDIR=$(abspath $(SBINDIR))
 
 # Docker builder section

doc/Advanced.md

@@ -9,11 +9,11 @@ Read about [Configuration Files](ConfigurationFiles.md) as they might come in ha
 
 edge can also be run as a service instead of cli:
 
-1. Edit `/etc/n2n/edge.conf` with your custom options. See `/etc/n2n/edge.conf.sample`.
+1. Edit `/etc/n3n/edge.conf` with your custom options. See `/etc/n3n/edge.conf.sample`.
 2. Start the service: `sudo systemctl start edge`
 3. Optionally enable edge start on boot: `sudo systemctl enable edge`
 
-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/n3n/edge-instance1.conf` and
 starting it with `sudo systemctl start edge@instance1`.
 
 
@@ -33,9 +33,9 @@ The [TAP Configuration Guide](TapConfiguration.md) contains hints on various set
 
 ## Bridging and Routing the Traffic
 
-Reaching a remote network or tunneling all the internet traffic via n2n are two common tasks which require a proper routing setup. n2n supports routing needs by temporarily modifying the routing table (`tools/n2n-route`). Details can be found in the [Routing document](Routing.md).
+Reaching a remote network or tunneling all the internet traffic via n3n are two common tasks which require a proper routing setup. n3n supports routing needs by temporarily modifying the routing table (`tools/n3n-route`). Details can be found in the [Routing document](Routing.md).
 
-Also, n2n supports [Bridging](Bridging.md) of LANs, e.g. to connect otherwise un-connected LANs by an encrypted n2n tunnel on level 2.
+Also, n3n supports [Bridging](Bridging.md) of LANs, e.g. to connect otherwise un-connected LANs by an encrypted n3n tunnel on level 2.
 
 
 ## Traffic Restrictions

doc/Authentication.md

@@ -1,10 +1,10 @@
 # Edge Authentication
 
-From a discussion on how to prevent MAC address spoofing, the need of edge authentication became evident. In fact, the REGISTER_SUPER type messages already have shown a so far unused `auth` field which gets used for the first time starting in the course of n2n version 2.9 development.
+From a discussion on how to prevent MAC address spoofing, the need of edge authentication became evident. In fact, the REGISTER_SUPER type messages already have shown a so far unused `auth` field which gets used for the first time starting in the course of n3n version 2.9 development.
 
 ## Implementation
 
-n2n implements two different authentication schemes the user can chose from.
+n3n implements two different authentication schemes the user can chose from.
 
 ### Identity Based Scheme
 
@@ -20,14 +20,14 @@ In case of edges unexpectedly shutting down with no opportunity for a clean exit
 
 ### User / Password Based Authentication
 
-A more advanced scheme relies on username and especially password. Public key cryptography, namely Curve25519, ensures safety. Basically, the password along with the mixed in user name, serve as private key. The corresponding public key is generated by the `tools/n2n-keygen` utility. The such generated public key gets depoisted at the supernode.
+A more advanced scheme relies on username and especially password. Public key cryptography, namely Curve25519, ensures safety. Basically, the password along with the mixed in user name, serve as private key. The corresponding public key is generated by the `tools/n3n-keygen` utility. The such generated public key gets depoisted at the supernode.
 
 #### Supernode Preparation
 
-To generate a public key for the user `logan` and her very secret password `007`, the `tools/n2n-keygen` utility would be called with username and password as command line parameter:
+To generate a public key for the user `logan` and her very secret password `007`, the `tools/n3n-keygen` utility would be called with username and password as command line parameter:
 
 ```bash
-[user@machine n2n]$ tools/n2n-keygen logan 007
+[user@machine n3n]$ tools/n3n-keygen logan 007
 * logan nHWum+r42k1qDXdIeH-WFKeylK5UyLStRzxofRNAgpG
 ```
 
@@ -69,37 +69,37 @@ With a view to the detailed explanations below, your supernode(s) should have a
 The edge takes the username with the already present, identifying command line parameter `-I <username>`. The password goes into `-J <password>`. Continuing the given example, the edge is invoked by
 
 ```
-[user@host n2n]$ sudo ./edge -l <supernode:port> -c netleo -I logan -J 007 <your additional parameters>
+[user@host n3n]$ sudo ./edge -l <supernode:port> -c netleo -I logan -J 007 <your additional parameters>
 ```
 
 Note that header encryption already is enabled automatically as this authentication scheme heavily relies on it. Also, currently only the stream ciphers work with this authentication scheme reliably in terms of security. So, `-A4` for ChaCha20 or `-A5` for SPECK along with a key `-k <key>` are required as additional parameters.
 
-The edges need to know the public key of the supernode. By default, the edges assume the default federation name, or more specific, the corresponding public key. In case the supernode is given a custom federation name which is highly recommended, the supernode's public key is provided to the edges via command line parameter `-P <public key>`. It can be generated from the federation name by using the `tools/n2n-keygen` utility as well:
+The edges need to know the public key of the supernode. By default, the edges assume the default federation name, or more specific, the corresponding public key. In case the supernode is given a custom federation name which is highly recommended, the supernode's public key is provided to the edges via command line parameter `-P <public key>`. It can be generated from the federation name by using the `tools/n3n-keygen` utility as well:
 
 ```bash
-[user@host n2n]$ tools/n2n-keygen -F secretFed
+[user@host n3n]$ tools/n3n-keygen -F secretFed
 -P opIyaWhWjKLJSNOHNpKnGmelhHWRqkmY5pAx7lbDHp4
 ```
 
 Considering all this, our example expands to
 
 ```
-[user@host n2n]$ sudo ./edge -l <supernode:port> -c netleo -I logan -J 007 -A5 -k mySecretKey -P opIyaWhWjKLJSNOHNpKnGmelhHWRqkmY5pAx7lbDHp4
+[user@host n3n]$ sudo ./edge -l <supernode:port> -c netleo -I logan -J 007 -A5 -k mySecretKey -P opIyaWhWjKLJSNOHNpKnGmelhHWRqkmY5pAx7lbDHp4
 ```
 
-You might want to consider the use of [`.conf` files](https://github.com/ntop/n2n/blob/dev/doc/ConfigurationFiles.md) to accomodate all the command line parameters more easily. Alternatively, the `N2N_PASSWORD` environment variable can be used to set the password without having it show up as part of the command line.
+You might want to consider the use of [`.conf` files](ConfigurationFiles.md) to accomodate all the command line parameters more easily. Alternatively, the `N2N_PASSWORD` environment variable can be used to set the password without having it show up as part of the command line.
 
 
 #### How Does It Work?
 
-In order to make this authentication scheme work, the existing header encryption scheme is split into using two keys: a _static_ and a _dynamic_ one. The static key remains unchanged and is the [classic header encryption key](https://github.com/ntop/n2n/blob/dev/doc/Crypto.md#header) derived from the community name. It only is applied to the very basic registration traffic between edge and supernode (REGISTER_SUPER, REGISTER_SUPER_ACK, REGISTER_SUPER_NAK). The dynamic key is derived (among others) from the federation name – keep it secret! – and applied to all the other packets, especially the data packets (PACKET) and peer-to-peer building packets (REGISTER), but also the ping and peer information (QUERY_PEER, PEER_INFO). An edge not provided with a valid dynamic key is not able to participate in the further communication.
+In order to make this authentication scheme work, the existing header encryption scheme is split into using two keys: a _static_ and a _dynamic_ one. The static key remains unchanged and is the [classic header encryption key](Crypto.md#header) derived from the community name. It only is applied to the very basic registration traffic between edge and supernode (REGISTER_SUPER, REGISTER_SUPER_ACK, REGISTER_SUPER_NAK). The dynamic key is derived (among others) from the federation name – keep it secret! – and applied to all the other packets, especially the data packets (PACKET) and peer-to-peer building packets (REGISTER), but also the ping and peer information (QUERY_PEER, PEER_INFO). An edge not provided with a valid dynamic key is not able to participate in the further communication.
 
 In regular header encryption mode, static key and dynamic key are equal. With activated user-password scheme, the supernode generates and transmits a dynamic key with the REGISTER_SUPER for further use. This happens in a secure way based on public key cryptography. A non-authenticated edge, i.e. without corresponding entry at the supernode or valid credentials, will not receive a valid dynmic key for communication beyond registration.
 
 In user-password scheme, the packets encrypted with the static key (REGISTER_SUPER, REGISTER_SUPER_ACK, useless for REGISTER_SUPER_NAK) are "signed" with an encrypted outer hash using the shared secret which is only known to the federated supernodes and that specific edge.
 
 #### Possible Extensions
 
-Tools for automizing [`.conf` file](https://github.com/ntop/n2n/blob/dev/doc/ConfigurationFiles.md) generation for deployment ot delivery to freshly registered and approved users could greatly enhance this ecosystem; a user would not have to mess around with command line parameters but just copy a `.conf` file into a specified directory.
+Tools for automizing [`.conf` file](ConfigurationFiles.md) generation for deployment ot delivery to freshly registered and approved users could greatly enhance this ecosystem; a user would not have to mess around with command line parameters but just copy a `.conf` file into a specified directory.
 
 Let us know if you are interested in implementing or furthering these ideas.

doc/Bridging.md

@@ -2,7 +2,7 @@
 
 ## General Remarks
 
-`edge`s can be part of network bridges. As such, n2n can connect otherwise un-connected LANs.
+`edge`s can be part of network bridges. As such, n3n can connect otherwise un-connected LANs.
 
 ## How To Use with `brctl`
 
@@ -24,4 +24,4 @@
 ## Compile Time Option
 
 The `-r`option at edge does not differentiate between the use cases _routing_ and _bridging_. In case the MAC-learning and MAC-replacing bridging code
-interfers with some special routing scenario, removal of the `#define HAVE_BRIDGING_SUPPORT` from `/include/n2n.h` file disables it at compile time.
+interfers with some special routing scenario, removal of the `#define HAVE_BRIDGING_SUPPORT` from `/include/n3n.h` file disables it at compile time.

doc/BuildConfig.md

@@ -22,7 +22,7 @@ the (re-)configuration and before building (again) using `make`.
 ZSTD Compression Support
 
 In addition to the built-in LZO1x for payload compression (`-z1` at the edge's
-commandline), n2n optionally supports [ZSTD](https://github.com/facebook/zstd).
+commandline), n3n optionally supports [ZSTD](https://github.com/facebook/zstd).
 As of 2020, it is considered cutting edge and [praised](https://en.wikipedia.org/wiki/Zstandard)
 for reaching the currently technologically possible Pareto frontier in terms
 of CPU power versus compression ratio.
@@ -71,7 +71,7 @@ running daemon
 
 ### `--enable-pcap`
 
-If the pcap library is available then the `n2n-decode` tool can be compiled.
+If the pcap library is available then the `n3n-decode` tool can be compiled.
 
 ### `--enable-natpmp`
 
@@ -86,7 +86,7 @@ this is `apt-get install libnatpmp-dev`
 Enables the other kind of UPnP port mapping protocol.
 
 Turning on either of these two UPnP libraries will enable UPnP support within
-the n2n-portfwd tool.
+the n3n-portfwd tool.
 
 This option depends on the library being installed - on Debian and Ubuntu,
 this is `apt-get install libminiupnpc-dev`
@@ -98,7 +98,7 @@ packets to a certain multicast address. Also, edges listen to this address to ev
 fetch such packets.
 
 If these packets disturb network's peace or even get forwarded by (other) edges through the
-n2n network, this behavior can be disabled
+n3n network, this behavior can be disabled
 
 #### Makefile
 
@@ -125,7 +125,7 @@ The easiest way to boosting speed is by allowing the compiler to apply optimizat
 
 `./configure CFLAGS="-O3"`
 
-The `tools/n2n-benchmark` tool reports speed-ups of 200% or more! There is no known risk in terms of instable code or so.
+The `tools/n3n-benchmark` tool reports speed-ups of 200% or more! There is no known risk in terms of instable code or so.
 
 ## Hardware Features
 
@@ -134,7 +134,7 @@ such as NEON, SSE and AVX. It needs to be decided at compile-time. Hence if comp
 platform with known features (maybe the local one), it should be specified to the compiler – for
 example through the `-march=sandybridge` (you name it) or just `-march=native` for local use.
 
-So far, the following portions of n2n's code benefit from hardware features:
+So far, the following portions of n3n's code benefit from hardware features:
 
 ```
 AES:               AES-NI
@@ -147,7 +147,7 @@ The compilations flags could easily be combined:
 
 `./configure CFLAGS="-O3 -march=native"`.
 
-There are reports of compile errors showing `n2n_seed': random_numbers.c:(.text+0x214): undefined reference to _rdseed64_step'` even though the CPU should support it, see #696. In this case, best solution found so far is to disable `RDSEED` support by adding `-U__RDSEED__` to the `CFLAGS`.
+There are reports of compile errors showing `n3n_seed': random_numbers.c:(.text+0x214): undefined reference to _rdseed64_step'` even though the CPU should support it, see #696. In this case, best solution found so far is to disable `RDSEED` support by adding `-U__RDSEED__` to the `CFLAGS`.
 
 ## SPECK – ARM NEON Hardware Acceleration