nyuuzyou/wikis huggingface dataset:
Firmwareinstallation/edgerouter4

== Installation ==
Bei der Installation des EdgeRouter 4 kann man sich nach den OpenWrt-Anleitungen richten:
- https://openwrt.org/toh/ubiquiti/edgerouter_4
- https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=dd651e54cc5eadba480a56a7d2c18471e560f491
Entweder OpenWrt installieren und später die Freifunk-Firmware per sysupgrade (ohne Konfigurationsübernahme, also mit -n) flashen.
Alternativ können statt der OpenWrt initramfs-kernel bzw. sysupgrade Images auch die entsprechenden Freifunk-Images verwendet werden.
==== Anleitung ====
Eine Schritt-für-Schritt-Anleitung (für Windows, übertragbar auf Linux) befindet sich unter: http://blog.tobo.biz/?p=854
==== Zusammenfassung ====
# *-initramfs-kernel.bin und *-sysupgrade.tar auf einen vfat/fat32 formatierten USB-Stick kopieren und mit dem Edgerouter 4 verbinden
# Mit Serieller Konsole verbinden (115200 baud, 8N1)
# Strom verbinden, den Bootloader durch drücken beliebiger Tasten in Konsolenmodus bringen
# usb start
# fatload usb 0:1 0x20000000 openwrt-octeon-ubnt_edgerouter-4-initramfs-kernel.bin
# bootoctlinux 0 numcores=4 endbootargs mem=0
# Nachdem das Image erfolgreich gebootet ist, Konsole aktivieren [Enter]
# mkdir /tmp/sda
# mount /dev/sda1 /tmp/sda
# sysupgrade -n /tmp/sda/sysupgrade-image.tar (Wichtig: -n nicht vergessen!)
==== Zusammenfassung Freifunk Firmware ====
# *-initramfs-kernel.bin auf einen vfat/fat32 formatierten USB-Stick kopieren und mit dem Edgerouter 4 verbinden
# Mit Serieller Konsole verbinden (115200 baud, 8N1)
# Strom verbinden, den Bootloader durch drücken beliebiger Tasten in Konsolenmodus bringen
# usb start
# fatload usb 0:1 0x20000000 *-initramfs-kernel.bin
# bootoctlinux 0 numcores=4 endbootargs mem=0
# Nachdem das Image erfolgreich gebootet ist einen Computer mit eth2 Verbinden und via SCP die *-sysupgrade.tar in das /tmp Verzeichnis laden.
# Danach via Console oder SSH das sysupgrade mit -n durchführen!
# sysupgrade -n /tmp/*-sysupgrade.tar (Wichtig: -n nicht vergessen!)
Firmwareinstallation/edgerouterx

=== Installationsbeschreibung ===
Hier: https://docs.freifunk-franken.de/firmware/hardware/ubiquiti-edgerouter-x/
=== PoE einschalten auf EdgeRouter X SFP ===
PoE kann in der /etc/config/system eingeschaltet werden. Beachte das dies nicht updatesicher ist!
Als Workaround kann die Änderung per fff_userconfig automatisch geschrieben werden: https://git.freifunk-franken.de/freifunk-franken/firmware/issues/129#issuecomment-3156
Firmwareunterschiede

Freifunk Franken unterscheidet seit dem Release 20191224 (vom 24.12.2019) im wesentlichen zwischen zwei Firmware-Varianten, </br>
der älteren "node" Variante und der neueren "layer3" Variante.
Man könnte diese beiden unterschiedlichen Firmwarevarianten auch Konzepte nennen.
== node ==
Die node Variante basiert auf dem Hood-Konzept, dass je 1-2 Gateways auf Servern im Internet einzelne Bereiche, Hoods, versorgen. </br>
Ein weiteres zentrales Element ist der keyXchange-v2, ein Datenbankserver, welcher den Nodes den Weg zu ihren korrekten Gateways zeigt.
Der node Betreiber muss hierfür lediglich die korrekte Firmware auf einem kompatiblen Gerät installieren und Koordinaten über eine Karte setzen, eine Kontakt-Mailadresse hinterlassen. Es stehen einige weitere Felder und Optionen bereit.
Die node Variante ist für jedermann geeignet, der es schon einmal bis in die Weboberfläche des eigenen Routers geschafft hat, oder dies gerne lernen möchte.
Die node Variante schafft je nach Gerät ca. 15-50 Mbit/s Durchsatz.
Alle Infos sowie Links zur node Variante findest du hier: [Link]
== layer3 ==
Die layer3 Variante richtet sich an Nutzer, welche mehr aus ihren Geräten herausholen wollen und mehr Kontrolle über ihr eigenes Netz haben wollen. Denn der Nutzer baut sich dabei sein eigenes Netz, sucht sich Peering-Partner und wird Teil des Babel-Backbones von Freifunk Franken.
Babel ist hierbei das Routingprotokoll, als VPN nutzen wir u.a. Wireguard.
Die layer3 Variante findet oft auch Anwendung bei größeren Installationen mit Stock-FW APs dahinter und optional inklusive Richtfunk.
Dazu gehört Protokollierung in unserem Wiki, Kontakt zu der Community, und ein gewisses Hintergrundwissen im Netzwerkbereich, bzw die Bereitschaft sich dieses anzueignen.
Man kann das Konzept der layer3 Variante auch mit OpenWRT oder auf x64 / arm nachbauen, egal ob auf einem Raspi4 oder in einer VM.
Alle Infos sowie Links zur layer3 Variante findest du hier: [Link]
== Betreiber-Zitate ==
Auf unserer Mailingliste gab es im Juni 2020 einige unterschiedliche Erklärungsversuche, welche die beiden Varianten unterscheiden sollten.
Hier geht es zu den Zitaten im [Archiv]
Kategorie:Technik
Kategorie:Einstiegsinformationen
Kategorie:Firmware
Kategorie:node
Kategorie:layer3
FreiFunk fürs Auto

= AutoFunk =
== Erklärung ==
Erste Versuche ein System zu schaffen mit welchem jeder FreiFunker auch mit seinem Auto "FreiFunk" verbreiten kann. Das Projekt ist noch sehr am Anfang und eigentlich nur durch zu viel Zeit und dumme Gedanken entstanden :)
== Aufbau ==
Version 1.0.0
* LTE Router (Vodafone GigaCube (Huawei B528) mit 50GB LTE - kostet ohne Vodafone Vertrag rund 35€/ Monat)
* TP-Link WR841N (wird bald getauscht gegen WR1043ND)
* Ubiquiti Loco M2
Alle drei sind via LAN Verbunden, die GigaCube untersützt Gigabit Lan. Der Maximal erreichbare Down-, und Upload Speed mit der GigaCube ist 150Mbit/s im Download und 50Mbit/s im Upload. Im Praxis Test kriege ich meist eine Ping von 16-50Ms; Download Geschwindigkeiten von 8-90Mbit/s und Upload geschwindigkeiten von ca 2-45Mbit/s.
Beide Geräte wurden mit Lochbändern auf eine Holzplatte geschraubt damit es möglichst Kompakt ist und somit auch jederzeit schnell aus dem Auto entfernt werden kann.
Version 1.0.1
* LTE Router (Huawei B315s-22; mit 50GB Vodafone LTE)
* TP-Link WR1043ND (FreiFunk WLAN; Meshing)
* Ubiquiti Loco M2 (FreiFunk WLAN; Meshing
== Funktionen ==
* FreiFunk WLAN aufspannen
* Privates WIFI im Auto auf 2,4 & 5 Ghz
* LAN Anschlüsse im Auto (Gigabit - wenn man einen Switch hinzufügt)
== Testgebiet ==
Momentan Teste ich diesen Aufbau in der Umgebung Nürnberg Land, genau genommen Nürnberg Südstadt und Verteile somit ein wenig WLAN, nützlich ist das z.b. auch bei kleineren Stadtteilfesten, somit kann man dort FreiFunk Verbreiten mit seinem Auto, vorteilhaft ist es auch wenn Leute kleine Camper wie z.b. T5 / T6 California damit ausstatten da diese Zweit Batterien haben und es somit nicht nötig ist das der Motor läuft.
== Bisherige Erfahrung ==
Testaufbau erst seit ca 4 Tagen im Einsatz, bisher wenig bis keine Probleme gehabt, Netzabdeckung durch Vodafone sehr gut und dadurch immer Verbindung.
== Kosten ==
Um mal für alle das etwas anschaulicher zu machen, die Kosten die ich momentan für das kleine Spaß-Projekt ausgegeben habe:
Version 1.0.0
* GigaCube ca 130€ + 35€ / monat die ich das System nutze
* WR841N ca 20€
* LAN Kabel (war beim WR841N dabei, ebenfalls liegt der GigaCube eines bei)
* Holzbrett 0€ (hatte ich rumliegen, im Baumarkt denke ich nichtmal 5€)
* Steckdosenleiste 0€ (hatte ich rumliegen, im Baumarkt ca 5€, je nach Qualität)
* LochBand 10€ im Baumarkt
Version 1.0.1
* Huawei B315s-22 ca. 140€
* TP-Link WR1043ND ca. 47€
* Krimskrams ca. 50€
Bilanz:
Bisher habe ich rund 400€ ausgegeben und ca 3h Zeit in das Projekt gesteckt
== Bilder ==
Version 1.0.0
 Datei:Board-AutoFunk.png
 Datei:GigaCube-AutoFunk.png
 Datei:WR841N-AutoFunk.png
Version 1.0.1
 Datei:LTERouter-AutoFunk.jpeg
 Datei:WR1043ND-AutoFunk.jpeg
Freifunk-Gateway aufsetzen/Batman bridge

Achtung!
Wer Dienste im Netz anbieten möchte, sollte das unabhängig der Hood tun und den Dienst im L3 Netz routen lassen.
--------------------------------------------
Veraltet!
Für viele Dinge ist es praktisch, um bat0 eine Bridge zu haben. Beispiele sind lokale Testclients oder wenn Dienste im Freifunknetz angeboten werden sollen, die auf einer anderen VM oder anderen Server laufen.
Dafür muss statt der in der Freifunk-Gateway_aufsetzen-Anleitung unter "B.A.T.M.A.N Netzwerk-Interface, fff Routingregeln und -tabelle" beschriebene Teil in der /etc/network/interfaces folgender Schnippsel verwendet werden:
# device: bat0
iface br0 inet manual
post-up ifconfig $IFACE up
 post-up ifconfig $IFACE up
 bridge_ports bat0 eth1
 ##Einschalten post-up:
 # IP des Gateways am B.A.T.M.A.N interface:
 post-up ip addr add 10.50.32.5/21 dev $IFACE
 # Regeln, wann die fff Routing-Tabelle benutzt werden soll:
 post-up ip rule add iif $IFACE table fff
 post-up ip rule add from 10.0.0.0/8 table fff
 post-up ip rule add to 10.0.0.0/8 table fff
 # Route in die Fuerther Hood:
 post-up ip route add 10.50.32.0/21 dev $IFACE table fff
 # Start des DHCP Servers:
 post-up invoke-rc.d isc-dhcp-server restart
 ##Ausschalten post-down:
 # Loeschen von oben definieren Routen, Regeln und Interface:
 post-down ip route del 10.50.32.0/21 dev $IFACE table fff
 post-down ip rule del from 10.0.0.8/8 table fff
 post-down ip rule del to 10.0.0.0/8 table fff
 post-down ip rule del iif $IFACE table fff
 post-down ifconfig $IFACE down
iface bat0 inet manual
 post-up ifconfig $IFACE up
 post-up ifup br0
 post-down ifdown br0
# VPN Verbindung in die Fuerther Hood
iface ffffuerthVPN inet manual
 post-up batctl -m bat0 if add $IFACE
 post-up ifconfig $IFACE up
 post-up ifup bat0
 post-down ifdown bat0
 post-down ifconfig $IFACE down
 post-down brctl delif br0 bat0
Wichtig Die Konfiguration vom DHCP-Server muss ebenfalls angepasst werden!
Und zwar muss in der /etc/default/isc-dhcp-server statt bat0 br0 angegeben werden.
Freifunk-Gateway aufsetzen/Fehlersuche

= fe80::1 wurde gecapert =
== Folgendes ist auf dem GW zu erkennen ==
Im dmesg
[ 3492.113573] ICMPv6: NA: someone advertises our address fe80:0000:0000:0000:0000:0000:0000:0001 on bat9!
== Was genau ist passiert? ==
Irgendwer hat im Layer 2 Netz sich die fe80::1 gecapert, die auf den Gateways eigentlich für Hoodfiles verwendet wird. Warum das passiert ist aktuell noch unklar
== Wie kann ich den Verursacher finden? ==
Zuerst tcpdump angucken:
tcpdump -i bat9 icmp6 and src fe80::1 -vv
Wichtig ist die Zeile:
source link-address option (2), length 8 (1): aa:bb:ff:**:**:**
hier haben wir die MAC des Problematischen Endgerätes, dieses können wir nun im Batman tracen:
batctl -m bat9 tr aa:bb:ff:**:**:**
der vorletzte Hop, ist der Router mit dem der "böse" Client verbunden ist.
Router betreiber anschreiben, Router sperren o.ä. (nach eigenen Ermessen) um das Problem zu beheben
Freifunk-Gateway aufsetzen/Optimierungen

= Problem nf_conntrack =
Bei vielen Clients und vorallem NAT und anderen Iptables kann es passieren das die nf_conntrack auf den Server voll läuft. Wenn dies passiert fängt der Server an Pakete zu verwerfen und ist dann nur noch schwer erreichbar.
Zu erkennen ist das auch wenn dmesg unmengen von
nf_conntrack: table full, dropping packet
um sich wirft.
Folgendes sollte man im Auge behalten:
== Ermitteln des conntrack_max ==
cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max
Debian9:
cat /proc/sys/net/nf_conntrack_max
== Ermitteln des aktuellen conntrack count ==
/sbin/sysctl net.netfilter.nf_conntrack_count
sollte die aktuell Größe nahe an die maximale Größe kommen, kann diese vergrößert werden:
sysctl -w net.netfilter.nf_conntrack_max=131072
echo 32768 > /sys/module/nf_conntrack/parameters/hashsize
Der hashsize sollte 1/4 des conntrack_max Wertes betragen
Der Wert kann auch permamenent angepasst werden:
vi /etc/sysctl.conf // Am Ende einfügen
net.netfilter.nf_conntrack_max=131072
vi /etc/rc.local
echo 32768 > /sys/module/nf_conntrack/parameters/hashsize
zusätzlich kann das unnötig lange Timeout verringert werden um den conntrack count schon von Grund auf kleiner zu halten:
vi /etc/sysctl.conf // Am Ende einfügen
net.ipv4.netfilter.ip_conntrack_generic_timeout = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 54000
bzw. die Werte sofort setzen:
sysctl -w net.ipv4.netfilter.ip_conntrack_generic_timeout=120
sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=54000
Quelle: 
= ARP Cache erhöhen =
ACHTUNG: Das ganze ist noch nicht intensiv getestet, bitte bei Änderungen beobachten!
Default ist im Linux der Arp Cache relativ klein. Wenn man mehrmals hintereinander die Menge an ARP Einträgen im Cache abfragt (z.b. ip neigh show | wc -l) und man feststellt das der Cache regelmäßig aufgeräumt wird (Zahl springt alle paar Sekunden wieder auf einen deutlich kleineren Wert zurück) sollte man den Wert erhöhen um die Arp Requests im Netz zu verringern. Dies geht über sysctl Variablen:
sysctl -w net.ipv6.neigh.default.gc_thresh1=128
sysctl -w net.ipv6.neigh.default.gc_thresh2=512
sysctl -w net.ipv6.neigh.default.gc_thresh3=1024
sysctl -w net.ipv4.neigh.default.gc_thresh1=128
sysctl -w net.ipv4.neigh.default.gc_thresh2=512
sysctl -w net.ipv4.neigh.default.gc_thresh3=1024
die oben angegeben Werte sind die default Werte. Weitere Infos zu den Werten:
https://wiki.manitu.de/index.php/Server:Fehlermeldung_%22kernel:_Neighbour_table_overflow%22
Ich hab z.b. auf nue2gw3 mit ~2400 Clients die Werte auf 2048 4096 8192 gesetzt.
Da aber Batman sowieso die ARP Table cached (batctl dc) werden die ARP Requests im Netz vermutlich sowieso schon eingespart und das ganze dürfte fast nichts bringen. Da es aber auch praktisch nichts kostet kann man es dennoch erhöhen, dies muss im Einzelfall entschieden werden.
Für IPv6 gibt es im Batman keinen Neighbor Cache. Es macht hier vermutlich Sinn den Wert deutlich zu erhöhen.
Freifunk-Gateway aufsetzen/VPN/vxlan

== Funktion ==
Layer2 Tunnel zwischen node und Gateway.
== Installation ==
Keine weitere Installaton notwendig. 
== Konfiguation ==
===vxlan===
Als erstes die vxlan interfaces in /etc/network/interfaces../... anlegen:
auto vxbat0
iface vxbat0 inet manual
pre-up ip l a dev $IFACE type vxlan id 7 dstport 8472 srcport 8472 8473 local ipv6:vom:gate:way
pre-up ip l s dev $IFACE mtu 1422
post-up batctl meshif bat0 if add $IFACE
pre-down batctl -m bat0 if del $IFACE
post-down ip l d dev $IFACE
###
auto vxbat1
iface vxbat1 inet manual
.... usw.
Achtung! port ist immer 8472. Nur id, local und die Interfaces anpassen. 
id = hoodid
Jetzt braucht man noch das vxmon.sh Skript
Nach /usr/local/sbin/vxmon.sh
#!/bin/bash
DEVS=$@
handle_add() {
 mac="${1:?}"
 dev="${2:?}"
 dst="${3:?}"
 echo "bridge fdb append 00:00:00:00:00:00 dst $dst dev $dev"
 bridge fdb append 00:00:00:00:00:00 dst "$dst" dev "$dev"
}
handle_cleanup() {
 mac="${1:?}"
 dev="${2:?}"
 dst="${3:?}"
 if ! bridge fdb show dev "$dev" | grep -v 00:00:00:00:00:00 | grep "$dst"; then
 bridge fdb del 00:00:00:00:00:00 dst "$dst" dev "$dev"
 fi
}
handle_entry() {
 cmd=handle_add
 if [ "$1" = "Deleted" ]; then
 shift
 cmd=handle_cleanup
 fi
 mac="${1:?}"
 dev="${3:?}"
 grep -w "$dev" <<<"$DEVS" || return
 if [ "$mac" = "00:00:00:00:00:00" ]; then
 echo "skipping" "$@"
 return
 fi
 $cmd "$mac" "$3" "$5"
}
bridge monitor fdb | while read args; do
 handle_entry $args
done
Executable Bit setzen: chmod 755 /usr/local/sbin/vxmon.sh
Zum Starten des Skriptes kann man sich eine unit anlegen: 
# /etc/systemd/system/vxmon.service 
[Unit]
Description=vxlan monitoring to add peers
Before=networking.service
[Service]
Type=simple
EnvironmentFile=/etc/default/vxmon
ExecStart=/usr/local/sbin/vxmon.sh $INTERFACES
Restart=on-abort
[Install]
WantedBy=multi-user.target
Unit enablen -> systemctl enable vxmon
Wie man sieht, können jetzt die Interfaces in /etc/default/vxmon eingetragen werden:
# /etc/default/vxmon 
# Hier alle vxlan interfaces eintragen. z.B
# INTERFACES="vxbat0 vxbat2"
vxmon starten -> sysemctl start vxmon
===vxlan bevorzugen===
Mit einem neuern batman-adv (batman-adv: 2020.3) kann man eine hop_penalty pro hardif einstellen.
Default ist 30 per hop. Wenn wir für fastd eine hop_penalty von 30 einstellen, wird fastd einen hop teurer.
Irgendwo findet man die Zeile, in der das Interface in das bat-device gehängt wird. Ev. in /etc/network/interfaces.... oder hier:
# /etc/fastd/fff-xxx/up.sh
#!/bin/bash
ip l s dev $INTERFACE up
batctl meshif bat0 if add $INTERFACE
batctl hardif $INTERFACE hp 30
===Eintrag im keyserver===
Änderungen am keyserver werden als pullrequest in diesem git gemacht:
https://git.freifunk-franken.de/freifunk-franken/hoods
Neuer VPN-Eintrag
'''
 {
 "name": "my_gateway",
 "protocol": "vxlan",
 "address": "url.from.gateway",
 "contact": "mailaddress"
 }
'''
Freifunk-Gateway aufsetzen/bird2

In dieser Anleitung geht es darum, babeld durch bird2 zu ersezten.
== Bird installieren und einrichten ==
=== arm64 ===
gefrickel
=== Debian Bullseye (Debian 11) / amd64 ===
bird2 sollte wegen verschiedener Bugfixes mindestens in Version 2.0.8 verwendet werden.
Stand April 2022 ist diese Version in den Backports verfügbar.
==== Backports einrichten ====
Frei nach https://backports.debian.org/Instructions/ wird das Backports Repository im System aufgenommen, werden die Paketquellen aktualisiert und bird2 aus den Backports installiert.
Als root sind hierzu folgende Befehle auszuführen:
echo "deb http://deb.debian.org/debian bullseye-backports main" >> /etc/apt/sources.list.d/backports.list
apt update
apt install bird2/bullseye-backports bird2-doc/bullseye-backports
bird wird hierbei als systemd-Service installiert.
Die Hauptkonfiguration findet sich in der Datei /etc/bird/bird.conf.
==== bird konfigurieren ====
Die Dokumentation zu bird findet sich unter bird.network.cz.
Der Inhalt der Konfigurationsdatei /etc/bird/bird.conf wird durch die folgende Konfiguration ersetzt:
Achtung, funktioniert so nicht.
Daher am besten an der Freifunk Firmware orientieren: https://git.freifunk-franken.de/freifunk-franken/firmware/src/branch/master/src/packages/fff/fff-babel-bird2/files/etc/bird-fff.conf
# Logging
log syslog all;
# Nimm die IP des interface als Router ID
router id from "fff-peer";
# Beziehe regelmaessig Updates der lokalen Interfacekonfiguration
protocol device {
 scan time 10;
}
# Schreibe Routen in die FIB des Systems, beziehe von dort aber keine Updates
protocol kernel {
 ipv6 {
 import none;
 export all;
 };
}
protocol kernel {
 ipv4 {
 import none;
 export all;
 };
}
# Statische Announcements der eigenen IPs
protocol static {
 ipv6;
 route 2001:db8:XX::/48 blackhole;
 route fd43:5602:29bd:XXXX::/64 blackhole;
 route 2001:db8:XX::1/128 "fff-peer";
 route fd43:5602:29bd:XXXX::1/128 "fff-peer";
}
protocol static {
 ipv4;
 route 10.50.X.0/24 blackhole;
 route 10.83.252.X/32 "fff-peer";
}
# Konfiguration des Babel Protokolls
protocol babel FFFbabel {
 # Interfaces auf denen babel gesprochen wird
 # interface "eth0", "eth1";
 interface "fff-peer" {
 # rx-tx-Kosten dem Tunneltypen ggf. anpassen
 rxcost 96;
 };
 ipv6 {
 import all;
 export all;
 };
 ipv4 {
 import all;
 export all;
 };
}
Hierbei ist der Name des Peering-Interfaces fff-peer an die lokalen Gegebenheiten anzupassen.
Ebenso müssen die IPv6- und ggf. IPv4-Adressen, sowie das öffentliche Subnetz angepasst werden.
In obiger Konfiguration wird implizit davon ausgegangen, dass das Pering Interface fff-peer die folgenden drei IP-Adressen bekommt:
2001:db8:XX::1/128
fd43:5602:29bd:XXXX::1/128
10.83.252.X/32
und der Host über diese Adressen im Netzwerk erreichbar sein soll. 
Die Netzwerke
2001:db8:XX::/48
fd43:5602:29bd:XXXX::/64
10.50.X.0/24
sind zu anderweitiger Verwendung gedacht, z.B. DHCP/SLAAC. Eine Anpassung an die eigenen Bedürfnisse ist entsprechend erforderlich.
Nach erfolgter Konfiguration muss diese noch aktiviert werden (wieder als root):
systemctl reload bird.service
Freifunk-Gateway aufsetzen/gre

== GRE ==
Da GRE ein sehr schnelles Tunnelprotokoll ist und wenig Overhead erzeugt ist es für die Verbindung zwischen Routern in Rechenzentren sehr gut geeigent.
=== Interface anlegen ===
Um die einzelnen Hoods miteinander zu verbinden werden die jeweiligen Router über GRE-Tunnel miteinander verbunden.
Dafür muss auf beiden Seiten ein passendes Interface angelegt werden. Hierfür muss man mit dem Admin des jeweiligen Tunnelpartners in Kontakt treten. Eine unvollständige Liste an Peeringangeboten findet sich hier: Portal:Layer3Peering.
Ein GRE-Tunnel kann sowohl IPv4, als auch IPv6 Daten transportieren. Es genügt daher, einen Tunnel entweder über IPv4 oder IPv6 aufzubauen.
Da Babel über IPv6-Multicasts kommuniziert, müssen dem Interface noch link-local Adressen hinzugefügt (passiert nicht immer automatisch) und Multicast aktiviert werden.
Am besten generiert man sich die link-local zufällig um Kollisionen zu vermeiden.
Die Debian Interfacekonfiguration sollte dann etwa so aussehen.
Der Interfacename (Platzhalter "<IFNAME>") kann frei gewählt werden (meist maximal 15 Zeichen):
auto <IFNAME>
iface <IFNAME> inet6 static
	address fe80::IRGENDWAS/64
	
	# IPv6 GRE
	pre-up ip -6 tunnel add $IFACE mode ip6gre local EIGENEPUBLICIP remote REMOTEPUBLICIP ttl 255
 post-down ip tunnel del $IFACE
 # Alternativ: IPv4 GRE
	#pre-up ip -4 tunnel add $IFACE mode gre local EIGENEPUBLICIP remote REMOTEPUBLICIP ttl 255
 #post-down ip tunnel del $IFACE
	# Enable Multicast for Babel
	pre-up ip link set dev $IFACE multicast on
	# iif rules
	post-up ip -6 rule add iif $IFACE prio 200 table fff
	pre-down ip -6 rule del iif $IFACE prio 200 table fff
iface <IFNAME> inet static
	address 10.83.252.x/32
	scope link
	# iif rules
	post-up ip -4 rule add iif $IFACE prio 200 table fff
	pre-down ip -4 rule del iif $IFACE prio 200 table fff
Die Interfacekonfiguration kann dann über den Aufruf von ifup <IFNAME> bzw. ifdown <IFNAME> gestartet bzw. gestoppt und damit das Interface konfiguriert bzw. dekonfiguriert werden.
Abschließend müssen GRE Interfaces in die Datei "/etc/default/babeld" eingefügt werden. (Siehe Freifunk-Gateway_aufsetzen/Babel)
=== Verbindung testen ===
Nach Aufruf von ip link bzw. ip addr sollte ein passender Eintrag für den Tunnel auftauchen:
7: <IFNAME>@NONE: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1448 qdisc noqueue state UNKNOWN group default qlen 1
 link/gre6 EIGENEPUBLICIP peer REMOTEPUBLICIP
 inet 10.83.252.x/32 brd 10.83.252.x scope link <IFNAME>
 valid_lft forever preferred_lft forever
 inet6 fe80::IRGENDWAS/64 scope link 
 valid_lft forever preferred_lft forever
Ein Multicast Ping auf das GRE-Tunnel-Interface zeigt, ob die Gegenstelle korrekt erreichbar ist:
ping ff02::1%<IFNAME>
Freifunk-Gateway aufsetzen/gwinfo

= gwinfo =
== Gatewayinfos an das Monitoring senden ==
Dies kann optional gemacht werden und muss nicht zwingend durchgeführt werden.
Übermittelt werden können:
* Interface-Namen und Mac-Adressen (ermöglicht Zuordnung von Router<->Gateway)
* Admin-Name
* Statistik-Seite
* IPv4/IPv6-Adressen aller Hoods
* DHCP Adressbereiche der Hoods
Der Einsatzzweck des Skriptes ist relativ begrenzt auf Szenarios mit dezentralen oder V2-Gateways unter Verwendung von batman-adv.
In anderen Fällen bietet das Skript keinen Mehrwert.
Das Skript für normale Gateways gibt es unter:
https://github.com/FreifunkFranken/fff-monitoring/blob/testing/gwinfo/sendgwinfo.sh
Danach mit chmod +x ausführbar machen.
Im Kopfteil des Scripts müssen Konstanten an das jeweilige Gateway angepasst werden.
Außerdem gibt es ziemlich weit oben im Programmcode eine Zeile, die auf die Buchstaben "fff" im Namen der Interfaces parst. Insbesondere wenn das Gateway nach dieser Anleitung (Stand Oktober '21) aufgesetzt ist, beginnen die Namen der fastd-Interfaces nicht mehr mit "fff", sondern mit "fastd-". Deshalb muss die entsprechende Codezeile geändert werden:
 batctl="$("$batctlpath" -m "$netif" if | grep "fastd-" | sed -n 's/:.*//p')"
Für dezentrale Gateways mit GW-Firmware gibt es eine eigene Variante:
https://github.com/FreifunkFranken/fff-monitoring/blob/testing/gwinfo/gwinfofirmware.sh
Danach noch einen neuen crontab Eintrag mit
*/5 * * * * root /usr/local/bin/sendgwinfo.sh
setzen