Layer3Firmware: Unterschied zwischen den Versionen

Aktuelle Version vom 18. April 2024, 16:04 Uhr

Allgemeine Informationen

Mit der Layer3-Firmware können leicht dezentrale Hoods aufgesetzt werden. Damit unterscheidet sie sich fundamental von der "alten", jetzt Node-Firmware genannten, Variante. Unter anderem betrifft dies folgende Punkte:

Der Datenaustausch findet jetzt auf IP-Ebene, also auf Schicht (layer) 3 (Wikipedia: OSI-Modell), statt und ist damit effizienter und näher an allgemeiner Netzwerktechnik.
Peering (Verbindung mit Funk-Nachbarn oder Gateways im Rechenzentrum) findet nicht mehr automatisch, sondern über dedizierten Richtfunk oder wireguard-Tunnel statt (siehe Peering-Partner).
Es ist kein Batman enthalten. Ein Meshen über Batman mit der normalen Node-Firmware ist zum aktuellen Zeitpunkt nicht möglich. Es können aber generischer Accesspoints mit original Firmware, OpenWRT o.ä. angeschlossen werden.

Kompatibilität und alternative Versionen

Vorsicht: Die offizielle Layer3-Firmware unterscheidet sich in der Konfiguration teilweise deutlich von den alten inoffiziellen Varianten. Bestehende Konfigurationen müssen ggf. überarbeitet werden.

Anleitung wie man trotz offiziell fehlendem Batman ein lokales layer2-Mesh hin basteln kann, gibt es hier.

Weiterhin gibt es die inoffizielle Firmware von Adrian, siehe Gatewayfirmware_Adrian.

Wichtige Dateien

Gatewaykonfiguration
/etc/config/gateway

Script configure-layer3

Die Layer-3 Firmware kann sehr einfach mithilfe des Skripts configure-layer3 auf Basis der Gatewaykonfiguration konfiguriert werden.

Das Script configure-layer3 wird - außer nach einem Update - nie automatisch ausgeführt. Entsprechend muss es nach Änderungen erneut ausgeführt werden.

Achtung: Unbekannte Einstellungen außerhalb der Gatewaykonfiguration (z.B. manuell gesetzte Einstellungen in /etc/config/network) werden möglicherweise entfernt!

Router Auswahl

Es wird ein von uns unterstützer Router mit mindestens 8MB Flash benötigt. Auf der Geschwindigkeitsseite kann angeguckt werden was die Modelle schaffen: https://wiki.freifunk-franken.de/w/Geschwindigkeiten#Leistungstests Die Firmware wird genauso geflasht wie die normale Node Firmware https://wiki.freifunk-franken.de/w/Portal:Firmware, danach ist die Einrichtung allerdings anders

Download

https://dev.freifunk-franken.de/layer3/

Typischer Ablauf einer Installation

Router flashen: https://wiki.freifunk-franken.de/w/Portal:Firmware
Als Client mit dem Router per SSH verbinden ( bei TP-Link auf LAN-Port achten) oder aus dem Heimnetzwerk über die WAN-IP des Routers per SSH verbinden: "ssh root@fdff::1" Passwort:ffol Bitte sofort ändern!
WireGuard-Keypair generieren nur falls WireGuard als VPN verwendet wird (Schlüssel sichern!) oder sich für eine Richtfunkstrecke absprechen
Peering-Partner für WireGuard suchen, persönlich treffen und Schlüssel austauschen oder auf eigenen Server verbinden
Die Gatewaykonfiguration auf das Gerät kopieren (/etc/config/gateway)
IP-Adressen (IPv4, IPv6), Subnetz vergeben und dokumentieren und in /etc/config/gateway eintragen
Mit „configure-layer3 -c“ die Einstellungen aus der Gatewayconfig in die Openwrt Configs übernehmen.
Mit „configure-layer3 -t“ die Einstellungen testen, falls das Script nicht manuell abgebrochen wird, werden nach 200 Sekunden die Einstellungen zurück gesetzt
Falls der Router noch erreichbar ist, das Script beenden (STRG + C) falls man von der SSH Session heruntergeflogen ist, innerhalb 200 Sekunden erneut verbinden und dann configure-layer3 -k ausführen. Sollte man auf den Router nicht mehr drauf kommen, werden nach 200 Sekunden alle Einstellungen zurück gesetzt und man ist wieder im Ursprungszustand
Alle Einstellungen prüfen
Mit „configure-layer3 -a“ werden alle Einstellungen fest gespeichert, erst hiermit wird alles rebootfest geschrieben. Davor kann durch einen „reboot“ jederzeit der Urzustand wieder erreicht werden.

Eine Schritt für Schritt Fassung ist hier zu finden

Peering-Partner

https://wiki.freifunk-franken.de/w/Portal:Layer3Peering

Allgemein sollte eigene Infrastruktur (z.b. Richtfunk) dem VPN immer bevorzugt werden. Wir wollen unser eigenes Netz aufbauen und nicht auf den Rücken von großen Providern. Wenn es keine Möglichkeit gibt sich an dem Netz per Richtfunk oder andere eigene Transporttechnologien anzuschließen kann auch VPN über bestehende Internetleitung verwendet werden. Hier eignet sich wireguard oder GRE sehr gut was beides mit der Firmware möglich ist.

Per LAN Kabel/Richtfunk/Glasfaser

Bevorzugte Variante: Es kann am Gateway Babel auf einen (oder mehrere) Ethernetport(s) (wenn nötig auch VLAN-getagget) gelegt werden. Somit kann auch über Kabel gepeered werden. Natürlich kann das Peering auch über Richtfunk, Glasfaser oder sonstige Technologien (z. B. Internet-Exchange) realisiert werden.

VPN-Tunnel via WireGuard

Wenn du über das Internet peeren willst, muss die Gegenseite WireGuard sprechen.

Für WireGuard musst du dir einen Peering-Partner suchen – mit einem Menschen reden, ob er mit dir ein Peering eingehen will – und mit ihm deinen Public-Key austauschen. Mit diesem könnt ihr die VPN-Verbindung aufbauen.

Generieren der Keys für WireGuard

Ausführliche Anleitung: https://www.wireguard.com/quickstart/

Für WireGuard muss ein Keypair generiert werden. Am einfachsten macht man dies per SSH direkt am Layer3-Router:

wg genkey | tee privatekey | wg pubkey > publickey

Den privatekey in der gleichnamigen Datei trägst du in deine gatewayconfig ein. Den publickey teilst du deinem Peering-Partner mit.

Prinzipiell ist es möglich, pro Router jeweils ein Keypair zu generieren oder immer das gleiche Keypair für alle Wireguard Verbindungen zu verwenden (mit größerem Risiko bei „Verlust“).

Es empfiehlt sich, den privatekey zu sichern, da man sonst vom Peering-Partner gehauen wird, wenn deswegen der Tunnel neu eingerichtet werden muss.

VPN über GRE

folgt

Babel Metrik

Siehe hier: Richtlinien für Babel Penalty bei dezentralen Hoods

configure-layer3

Folgende Parameter können übergeben werden:

-c: Konfiguriert das Gateway mit uci. Kein commit, kein Anwenden der Einstellungen!
-t: Startet alle Dienste neu, damit werden die Einstellungen aus -c angewendet. Script wartet bis zu 200 Sekunden darauf, dass es beendet wird (Strg + C, wenn SSH nicht verloren geht. Ansonsten `configure-layer3 -k`). Wird das Script in dieser Zeit nicht beendet, werden die Einstellungen zurückgesetzt und die Dienste erneut neu gestartet.
-a: Übernimmt die Änderungen (uci commit), startet Dienste neu.
-r: Macht die Änderungen rückgängig.

Diagnose

Um im Fehlerfall mehr Infos zu haben, kann folgender Befehl ausgeführt werden

yes | sh -x /usr/sbin/configure-layer3 -c >> /tmp/diag  2>&1

in der Datei /tmp/diag kann dann der Fehler gesucht werden

/etc/config/gateway

Siehe hier: Layer3Firmware_Config

Remote-Upgrade

Seit der Firmware 20210211-beta werden die Einstellungen nach einem Update automatisch wieder richtig gesetzt. Es ist also nicht mehr nötig vorher spezielle Skripte einzustellen.

Aktuell (Stand 20200501) ist es nach einem Upgrade nötig, configuregateway manuell auszuführen. Bis dahin ist die Netzwerkkonfiguration des Routers so wie beim ersten flashen! (/etc/config/gateway und /etc/config/fff werden aber übernommen)

Daher ist ein Remote-Upgrade derzeit nicht einfach möglich. Behelfsmäßig kann configuregateway aber nach dem Booten automatisiert gestartet werden. Dies kann aber unter Umständen anfällig für diverse Nebenläufigkeitsprobleme sein.

Dafür in /etc/rc.local.fff_userconfig folgendes einfügen (und nach abgeschlossenem Upgrade wieder entfernen!):

sleep 100
yes | configuregateway -c
configuregateway -a

SNAT

Ab der Firmware 20220405-beta ist es möglich bei IPv4 für die Clients Adressen zu verwenden die nicht im Freifunk geroutet werden und auf eine einzelne IP Adresse zu NATten. Somit ist nur noch eine einzelne Freifunk IPv4 Adresse nötig. Dazu muss unter gateway 'meta' die Option router_ip gesetzt werden mit einer einzelnen IPv4 Adresse mit /32 Subnetzmaske die im Wiki reserviert wird (Beispiel: 10.50.261.33/32). Im Clientblock muss dann SNAT aktiviert werden indem die Option SNAT '1' gesetzt wird. Als IPv4 Adressen für die Clients sollten dort Adressen verwendet werden, die nicht im Freifunk geroutet werden z.b. 192.168.0.1/16, da hier ein NAT auf die einzelne Adresse erfolgt, kann dieses Subnetz auf vielen Routern gleichzeitig verwendet werden.

Eine Beispielconfig kann so aussehen:

config gateway 'meta'
	option router_ip '10.50.267.35/32' #die einzelne IP Adresse die im Wiki registriert wurde
	option config_version '3'

config vlan '10'
	option comment 'client'
	option ports 'eth0:* eth1:* eth2:* eth3:* eth4:*'

config vlan '202'
	option comment 'er_xxx'
	option ports 'eth0:t'

config client
	option vlan '10'
	option ipaddr '192.168.0.1/16' # das Subnetz das überall verwendet werden kann, die exakt eingegebene Adresse hier bekommt der Router
	list ip6addr '2a0b:f4c0:xx:xx::x/64'
	list ip6addr 'fd43:5602:29bd:xx::x/64'
	option dhcp_start '192.168.1.0' #DHCP Start
	option snat '1' #aktiviert SNAT

config dns
	list server 'fd43:5602:29bd:ffff:1:1:1:1'
	list server 'fd43:5602:29bd:ffff:a:a:a:a'

config babelpeer 'er_xxx'
	option vlan '202'
	option type 'wired'
	option rxcost '1024'

Achtung! Die ClientIP Adressen sollten sich auf keinen Fall mit den IP Adressen vom Internetrouter (Fritzbox o.ä.) überschneiden wo der Freifunkrouter mit den WAN Port angeschlossen wird. Da hat die Firmware leider noch Probleme damit: https://git.freifunk-franken.de/freifunk-franken/firmware/issues/240 (dies gilt auch für nicht NAT, wenn da im priv. Netz 10.50/16 oder 10.83/16 verwendet wird, ist dies ebenfalls aktuell ein großes Problem!) Klassisch würde ich nicht 192.168.0/24 192.168.1/24 192.168.88/24 192.168.178/24 verwenden, es eignet sich z.b. 192.168.208.1/20 sehr gut

Besondere Konfigurationen (optional)

Mit der Layer-3 Firmware sind relativ einfach auch individuelle Ergänzungen konfigurierbar, ein paar Beispiele können hier gesammelt werden.

Die Client-Seite mit dem Freifunk kann per VLAN ins Hausnetz ins Hausnetz getunnelt werden, wenn kein Platz für zusätzliche Kabel ist.

@@ Zeile 1: / Zeile 1: @@
 == Allgemeine Informationen ==
+Mit der Layer3-Firmware können leicht [[Layer_3_Firmware|dezentrale Hoods]] aufgesetzt werden.
+Damit unterscheidet sie sich fundamental von der "alten", jetzt [[Anleitungen/Node_Firmware|Node-Firmware]] genannten, Variante.
+Unter anderem betrifft dies folgende Punkte:
+* Der Datenaustausch findet jetzt auf IP-Ebene, also auf Schicht (layer) 3 ([[wikipedia:de:OSI-Modell|Wikipedia: OSI-Modell]]), statt und ist damit effizienter und näher an allgemeiner Netzwerktechnik.
+* Peering (Verbindung mit Funk-Nachbarn oder Gateways im Rechenzentrum) findet nicht mehr automatisch, sondern über dedizierten Richtfunk oder wireguard-Tunnel statt (siehe [[Layer3Firmware#Peering-Partner|Peering-Partner]]).
+* Es ist kein Batman enthalten. Ein Meshen über Batman mit der normalen Node-Firmware ist zum aktuellen Zeitpunkt nicht möglich. Es können aber generischer Accesspoints mit original Firmware, OpenWRT o.ä. angeschlossen werden.
-=== Wichtige Dateien ===
+== Kompatibilität und alternative Versionen ==
-'''[[Hood file]]'''<br />
+'''Vorsicht''': Die offizielle Layer3-Firmware unterscheidet sich in der Konfiguration teilweise deutlich von den alten inoffiziellen Varianten. Bestehende Konfigurationen müssen ggf. überarbeitet werden.
-<code>/etc/hoodfile</code>
-(Fabian, Adrian ab 2019)<br />
-<code>/www/hood/keyxchangev2data</code>
-(Adrian bis 2018)
-'''Gatewaykonfiguration'''<br />
-<code>/etc/config/gateway</code>
-=== Script ''configuregateway'' ===
+Anleitung wie man trotz offiziell fehlendem Batman ein lokales layer2-Mesh hin basteln kann, gibt es [[Gatewayfirmware/Batman|hier.]]
-Die Gatewayfirmware kann sehr einfach mithilfe des Skripts ''configuregateway'' auf Basis von '''Hood file''' und der '''Gatewaykonfiguration''' konfiguriert werden.
-Das Script ''configuregateway'' wird nie automatisch ausgeführt.
+Weiterhin gibt es die inoffizielle Firmware von Adrian, siehe [[Gatewayfirmware_Adrian]].
-Entsprechend muss es nach Änderungen erneut ausgeführt werden, sowie nach Updates.
-(Es werden zwar die o.&nbsp;g. Dateien beim Upgrade ''kopiert'', jedoch muss eben manuell ''configuregateway'' ausgeführt werden, um sie ''anzuwenden'' …)
-'''Achtung:''' Unbekannte Einstellungen werden möglicherweise entfernt!
+== Wichtige Dateien ==
-ULA und Wifi bezieht das Script aus der '''Hood file''', den Rest aus der '''Gatewaykonfiguration'''.
+'''Gatewaykonfiguration'''<br />
+<code>/etc/config/gateway</code>
-=== Firmwarezweige ===
-Die Gatewayfirmware wird aktuell größtenteils hier entwickelt:
+== Script ''configure-layer3'' ==
-* https://github.com/fblaese/firmware/tree/l3-fbl
-** Rebase auf aktuelle Firmware und aktuelle Entwicklung im l3-fbl Branch!
-* https://github.com/adrianschmutzler/fff-firmware/tree/mainline
-Die beiden Firmwarezweige unterscheiden sich funktional wenig voneinander.
+Die Layer-3 Firmware kann sehr einfach mithilfe des Skripts ''[https://wiki.freifunk-franken.de/w/Layer3Firmware#configure-layer3| configure-layer3]'' auf Basis der '''Gatewaykonfiguration''' konfiguriert werden.
-Am besten immer den aktuellen Stand abfragen, was gerade wie zu installieren ist.
-== Download ==
+Das Script ''configure-layer3'' wird - außer nach einem Update - nie automatisch ausgeführt.
+Entsprechend muss es nach Änderungen erneut ausgeführt werden.
-Fertige Builds gibt es entsprechend den Tags aus dem o.&nbsp;g. Repository hier:
+'''Achtung:''' Unbekannte Einstellungen außerhalb der Gatewaykonfiguration (z.B. manuell gesetzte Einstellungen in /etc/config/network) werden möglicherweise entfernt!
-* http://fw.sgstbr.de/gateway/
-* https://freifunk.jubt.org/fff-firmware.php (Variante gw_* wählen!)
+== Router Auswahl ==
+Es wird ein von uns unterstützer Router mit mindestens 8MB Flash benötigt. Auf der Geschwindigkeitsseite kann angeguckt werden was die Modelle schaffen: https://wiki.freifunk-franken.de/w/Geschwindigkeiten#Leistungstests
+Die Firmware wird genauso geflasht wie die normale Node Firmware https://wiki.freifunk-franken.de/w/Portal:Firmware, danach ist die Einrichtung allerdings anders
+== Download ==
-'''Achtung:''' Die Imagedatei *.bin darf nicht länger als 64 Zeichen sein, sonst wird sie beim flashen nicht erkannt!
+* https://dev.freifunk-franken.de/layer3/
 == Typischer Ablauf einer Installation ==
-# Router flashen
+# Router flashen: https://wiki.freifunk-franken.de/w/Portal:Firmware
-# Als Client mit dem Router per SSH verbinden ''oder'' aus dem Heimnetzwerk über die WAN-IP des Routers per SSH verbinden
+# Als Client mit dem Router per SSH verbinden ([[Firmwareinstallation/wr841 | bei TP-Link auf LAN-Port achten]]) ''oder'' aus dem Heimnetzwerk über die WAN-IP des Routers per SSH verbinden: "ssh root@fdff::1" Passwort:ffol Bitte sofort ändern!
-# [[#Generieren_der_Keys_für_WireGuard|WireGuard-Keypair generieren]] falls WireGuard verwendet wird (Schlüssel sichern!) oder sich für eine Richtfunkstrecke absprechen
+# [[#Generieren_der_Keys_für_WireGuard|WireGuard-Keypair generieren]] nur falls WireGuard als VPN verwendet wird (Schlüssel sichern!) oder sich für eine Richtfunkstrecke absprechen
-# [[#Peering-Partner|Peering-Partner]] für WireGuard suchen, persönlich treffen und Schlüssel austauschen
+# [[#Peering-Partner|Peering-Partner]] für WireGuard suchen, persönlich treffen und Schlüssel austauschen oder auf eigenen Server verbinden
-# Die [[#.2Fetc.2Fconfig.2Fgateway|Gatewaykonfiguration]] auf das Gerät kopieren (/etc/config/gateway)
+# Die [[#.2Fetc.2Fconfig.2Fgateway|Gatewaykonfiguration]] auf das Gerät kopieren (/etc/config/gateway)<br />IP-Adressen (IPv4, IPv6), Subnetz vergeben und dokumentieren und in /etc/config/gateway eintragen
-# Das [[#hood_file|Hoodfile]] auf das Gerät kopieren (/etc/hoodfile oder /www/hood/keyxchangev2data, siehe oben!)
+# Mit „[[#configure-layer3|configure-layer3]] -c“ die Einstellungen aus der Gatewayconfig in die Openwrt Configs übernehmen.
-# Mit „[[#configuregateway|configuregateway]] -c“ die Einstellungen aus der Gatewayconfig in die Openwrt Configs übernehmen.
+# Mit „[[#configure-layer3|configure-layer3]] -t“ die Einstellungen testen, falls das Script nicht manuell abgebrochen wird, werden nach 200 Sekunden die Einstellungen zurück gesetzt
-# Mit „[[#configuregateway|configuregateway]] -t“ die Einstellungen testen, falls das Script nicht manuell abgebrochen wird, werden nach 200 Sekunden die Einstellungen zurück gesetzt
+# Falls der Router noch erreichbar ist, das Script beenden (STRG + C) falls man von der SSH Session heruntergeflogen ist, innerhalb 200 Sekunden erneut verbinden und dann ''configure-layer3 -k'' ausführen. Sollte man auf den Router nicht mehr drauf kommen, werden nach 200 Sekunden alle Einstellungen zurück gesetzt und man ist wieder im Ursprungszustand
-# Falls der Router noch erreichbar ist, das Script beenden (STRG + C) falls man von der SSH Session heruntergeflogen ist, innerhalb 200 Sekunden erneut verbinden und das ''configuregateway''-Script killen (z.&nbsp;B. mit „killall configuregateway“). Sollte man auf den Router nicht mehr drauf kommen, werden nach 200 Sekunden alle Einstellungen zurück gesetzt und man ist wieder im Ursprungszustand
 # Alle Einstellungen prüfen
-# Mit „[[#configuregateway|configuregateway]] -a“ werden alle Einstellungen fest gespeichert, erst hiermit wird alles rebootfest geschrieben. Davor kann durch einen „reboot“ jederzeit der Urzustand wieder erreicht werden.
+# Mit „[[#configure-layer3|configure-layer3]] -a“ werden alle Einstellungen fest gespeichert, erst hiermit wird alles rebootfest geschrieben. Davor kann durch einen „reboot“ jederzeit der Urzustand wieder erreicht werden.
+Eine Schritt für Schritt Fassung ist [[Anbindung#Einrichtung_der_Layer_3_Firmware|hier]] zu finden
 == Peering-Partner ==
 https://wiki.freifunk-franken.de/w/Portal:Layer3Peering
-Für Redundanz sollten (mindestens) zwei Peerings eingestellt werden(zum Testen reicht eines aber völlig aus).
+Allgemein sollte eigene Infrastruktur (z.b. Richtfunk) dem VPN immer bevorzugt werden. Wir wollen unser eigenes Netz aufbauen und nicht auf den Rücken von großen Providern. Wenn es keine Möglichkeit gibt sich an dem Netz per Richtfunk oder andere eigene Transporttechnologien anzuschließen kann auch VPN über bestehende Internetleitung verwendet werden. Hier eignet sich wireguard oder GRE sehr gut was beides mit der Firmware möglich ist.
-Sinnvoll ist es auch, wenn nicht beide Peerings einfach per VPN-Tunnel laufen, sondern z.&nbsp;B. ein weiteres per Richtfunk; somit läuft das Netz auch weiter wenn der Internetanschluss ausfällt!
+=== Per LAN Kabel/Richtfunk/Glasfaser ===
+Bevorzugte Variante:
+Es kann am Gateway Babel auf einen (oder mehrere) Ethernetport(s) (wenn nötig auch VLAN-getagget) gelegt werden. Somit kann auch über Kabel gepeered werden.
+Natürlich kann das Peering auch über [https://wiki.freifunk-franken.de/w/VLAN_und_Richtfunk Richtfunk], [[Glasfaser-Verbindung|Glasfaser]] oder sonstige Technologien (z.&nbsp;B. Internet-Exchange) realisiert werden.
 === VPN-Tunnel via WireGuard ===
 Wenn du über das Internet peeren willst, muss die Gegenseite WireGuard sprechen.
-Es ist aktuell in der Firmware nicht möglich, aber man kann theoretisch auch andere Tunneltechnologien (z.&nbsp;B. GRE eignet sich sehr gut) für Babel verwenden.
 Für WireGuard musst du dir einen Peering-Partner suchen – mit einem Menschen reden, ob er mit dir ein Peering eingehen will – und mit ihm deinen Public-Key austauschen. Mit diesem könnt ihr die VPN-Verbindung aufbauen.
@@ Zeile 75: / Zeile 73: @@
 Ausführliche Anleitung: https://www.wireguard.com/quickstart/
-Für WireGuard muss ein Keypair generiert werden. Am einfachsten macht man dies per SSH direkt am Gateway-Router:
+Für WireGuard muss ein Keypair generiert werden. Am einfachsten macht man dies per SSH direkt am Layer3-Router:
 <code>
@@ Zeile 83: / Zeile 81: @@
 Den ''privatekey'' in der gleichnamigen Datei trägst du in deine ''gatewayconfig'' ein. Den ''publickey'' teilst du deinem Peering-Partner mit.
-Prinzipiell ist es möglich, pro Router jeweils ein Keypair zu generieren oder immer das gleiche Keypair für alle Gateways zu verwenden (mit größerem Risiko bei „Verlust“).
+Prinzipiell ist es möglich, pro Router jeweils ein Keypair zu generieren oder immer das gleiche Keypair für alle Wireguard Verbindungen zu verwenden (mit größerem Risiko bei „Verlust“).
 Es empfiehlt sich, den ''privatekey'' zu sichern, da man sonst vom Peering-Partner gehauen wird, wenn deswegen der Tunnel neu eingerichtet werden muss.
-=== Per LAN Kabel/Richtfunk/Glasfaser ===
+=== VPN über GRE ===
-Es kann am Gateway Babel auch auf einen Ethernetport (wenn nötig auch VLAN-getagget) gelegt werden. Somit kann auch über Kabel gepeered werden.
+*folgt
-Natürlich kann das Peering auch über Richtfunk, [[Glasfaser-Verbindung|Glasfaser]] oder sonstige Technologien (z.&nbsp;B. Internet-Exchange) realisiert werden.
-== Hood file ==
-Das Hood File ist konzeptionell identisch zu der unter V2 verwendeten Datei.
-Details zum Hood-File unter: [[Hood file]]
-'''Benutzte IP-Adressbereiche eintragen!'''
-IPv4: [[Portal:Netz]]
-IPv6: [[Portal:Netz/IPv6]]
 == Babel Metrik ==
-Siehe hier: [[Freifunk-Gateway_aufsetzen/Babel#Richtlinien_f.C3.BCr_Babel_Penalty_bei_dezentralen_Hoods|Richtlinien für Babel Penalty bei dezentralen Hoods]]
+Siehe hier: [[Freifunk-Gateway_aufsetzen/Babel#Richtlinien_f.C3.BCr_Babel_Penalty_.28rxcost.29|Richtlinien für Babel Penalty bei dezentralen Hoods]]
-== ''configuregateway'' ==
+== ''configure-layer3'' ==
 Folgende Parameter können übergeben werden:
 * ''-c'': Konfiguriert das Gateway mit ''uci''. Kein ''commit'', kein Anwenden der Einstellungen!
-* ''-t'': Startet alle Dienste neu, damit werden die Einstellungen aus ''-c'' angewendet. Script wartet bis zu 200 Sekunden darauf, dass es beendet wird (Strg + C, wenn SSH nicht verloren geht, ansonsten „kill(all)“). Wird das Script in dieser Zeit nicht beendet, werden die Einstellungen zurückgesetzt und die Dienste erneut neu gestartet.
+* ''-t'': Startet alle Dienste neu, damit werden die Einstellungen aus ''-c'' angewendet. Script wartet bis zu 200 Sekunden darauf, dass es beendet wird (Strg + C, wenn SSH nicht verloren geht. Ansonsten `configure-layer3 -k`). Wird das Script in dieser Zeit nicht beendet, werden die Einstellungen zurückgesetzt und die Dienste erneut neu gestartet.
 * ''-a'': Übernimmt die Änderungen (''uci commit''), startet Dienste neu.
 * ''-r'': Macht die Änderungen rückgängig.
-== /etc/config/gateway ==
+== Diagnose ==
+Um im Fehlerfall mehr Infos zu haben, kann folgender Befehl ausgeführt werden
-'''Benutzte IP-Adressbereiche eintragen:'''
-IPv4: [[Portal:Netz]]
-IPv6: [[Portal:Netz/IPv6]]
-=== Beispielkonfiguration ===
-Eine Bespielkonfiguration mit einem direkten Peer und einem WireGuardpeer gibt’s hier: https://gist.github.com/fblaese/ca4d903b20b4d7033553f48625b93ca6
-Erklärung:
-{|
-! !! Port !! VLAN !! Ziel
-|-
-| || P1 || 2 || Intern
-|-
-| || P2 || 3 || BATMAN
-|-
-| || P3 || 3 || BATMAN
-|-
-| || P4 || 1 || Client
-|-
-| || P5 || 1t, 101t || Client, Babel-Peeringnachbar
-|-
-|}
-{|
-! !! VLAN !! Name !! Ziel
-|-
-| || 1 || Client || Geräte als Client anbinden
-|-
-| || 2 || WAN || Internetverbindung, Babel zu FFF-GW via Wireguard
-|-
-| || 3 || BATMAN || Versorgung von v2 Knoten
-|-
-| || 101 || babel-neigh || VLAN zu Nachbargateway, Babel z.B. über Richtfunk
-|-
-|}
-'''Achtung:''' Die VLAN-Einstellungen hier sind für den TL-WDR4900, für andere Geräte muss z.&nbsp;B. geprüft werden auf welchen Port der WAN liegt. Eine Liste ist ganz unten zu finden oder in der offiziellen Firmware: https://github.com/FreifunkFranken/firmware/tree/master/src/packages/fff/fff-network/ar71xx
-==== VLAN-Konfiguration Firmware Adrian ====
-In der obigen Beispieldatei müssen alle zu konfigurierenden VLANs mittels "config vlan" angegeben werden. Alle vorigen Einstellungen werden überschrieben.
-In Adrians gw_* Firmware ab gw_20190525 wird die VLAN-Konfiguration abgewandelt:
-Die bisherige Konfiguration bleibt erhalten, neue VLANs können mit folgenden Blöcke angelegt werden:
 <pre>
-config add_vlan
+yes | sh -x /usr/sbin/configure-layer3 -c >> /tmp/diag  2>&1
-        option vlan '11'
-        option ports '0t 4'
 </pre>
-'''Achtung:''' Meine Firmware erfordert die Angabe des CPU-Ports (hier 0t).
+in der Datei /tmp/diag kann dann der Fehler gesucht werden
-Soll ein VLAN geändert werden, sodass die alte VLAN-ID entfernt werden muss, kann folgender Block verwendet werden:
+== /etc/config/gateway ==
-<pre>
-config del_vlan
-        option vlan '2'
-</pre>
-Die bisherigen Blöcke 'config vlan' werden ignoriert.
-Möchte man die Standardkonfiguration verwenden, muss man demnach keine add_vlan/vlan-Blöcke verwenden.
-Notwendig ist weiterhin die Verknüpfung eines VLAN oder Interfaces mit client bzw. batman; Beispiel client:
-<pre>
-config client
-        option vlan '1'
-</pre>
-oder
-<pre>
-config client
-        option iface 'eth0'
-</pre>
-Diese Blöcke sind für batman und client Pflicht. Für wan ist eine entsprechende Angabe nur notwendig, wenn die Verknüpfung geändert werden soll (z.B. VLAN 12 statt VLAN 2).
-'''Achtung:''' Die Angabe der VLAN-ID als Verknüpfung (option vlan) ist nur möglich, wenn nur ''eines'' der beiden Interfaces mit tagged Ports konfiguriert ist. Ansonsten muss die option iface gewählt werden, z.B. Archer C7 v2:
-<pre>
-config client
-        option iface 'eth1.1'
-config batman
-        option iface 'eth1.3'
-# Diese Angabe erfolgt nur zur Erklärung.
-# Da es sich um die Standardkonfiguration handelt,
-# kann diese am Gerät entfallen
-config wan
-        option iface 'eth0.2'
-</pre>
-Zur Zeit benutzen folgende Geräte per default tagged-Ports an mehreren ethX-Devices: Archer C7 v2, TL-WR1043ND v2/v3
-=== Parameter-Übersicht ===
-==== Varianten: ====
-O = offiziell; F = Fabian; A = Adrian
-==== gateway ====
-{|
-! style="width:80px;text-align:left" | Name
-! style="width:120px;text-align:left" | Typ
-! style="width:80px;text-align:left" | Pflicht
-! style="width:80px;text-align:left" | Variante
-! style="text-align:left" | Beschreibung
-|-
-| name || string || nein || F ||
-|-
-| peer_ip || IPv4-Adresse || nein || F/A || IPv4-Adresse für Peerings
-|-
-| peer_ip6 || IPv6-Adresse || nein || F/A || IPv6-Adresse für Peerings
-|-
-|}
-==== vlan ====
-{|
-! style="width:80px;text-align:left" | Name
-! style="width:120px;text-align:left" | Typ
-! style="width:80px;text-align:left" | Pflicht
-! style="width:80px;text-align:left" | Variante
-! style="text-align:left" | Beschreibung
-|-
-| comment || string || nein || F ||
-|-
-| port || list || nein || F || Ports auf dem Standard-Switch
-|-
-|}
-==== add_vlan ====
-{|
-! style="width:80px;text-align:left" | Name
-! style="width:120px;text-align:left" | Typ
-! style="width:80px;text-align:left" | Pflicht
-! style="width:80px;text-align:left" | Variante
-! style="text-align:left" | Beschreibung
-|-
-| vlan || int || ja || A || VLAN-ID
-|-
-| ports || list || ja || A || Ports inkl. CPU-Ports
-|-
-|}
-==== del_vlan ====
-{|
-! style="width:80px;text-align:left" | Name
-! style="width:120px;text-align:left" | Typ
-! style="width:80px;text-align:left" | Pflicht
-! style="width:80px;text-align:left" | Variante
-! style="text-align:left" | Beschreibung
-|-
-| vlan || int || ja || A || VLAN-ID
-|-
-|}
-==== client ====
-{|
-! style="width:80px;text-align:left" | Name
-! style="width:120px;text-align:left" | Typ
-! style="width:80px;text-align:left" | Pflicht
-! style="width:80px;text-align:left" | Variante
-! style="text-align:left" | Beschreibung
-|-
-| iface || interface || nein || F/A || Clientnetz auf Interface legen (z.B. eth0, eth0.1)
-|-
-| vlan || int || nein || F/A || Clientnetz auf VLAN mit angegebener IP auf dem Standard-Switch* legen '''(alternativ zu ''iface''!)'''
-|-
-| ipaddr || IPv4-Adresse || nein || F/A || Router-IP im Client-Netz (CIDR Notation)
-|-
-| ip6addr || IPv6-Adresse || nein || F/A || Router-IP im Client-Netz (CIDR Notation)**
-|-
-| dhcp_start || IPv4-Adresse || nein || F/A || DHCP-Startadresse
-|-
-| dhcp_limit || int || nein || F/A || Maximale Anzahl an DHCP-Leases (default 150)
-|-
-|}
-<nowiki>*</nowiki> Bei Adrian: Nur verwenden, wenn maximal EIN ethX mit tagged VLANs vorhanden ist!
-<nowiki>**</nowiki> Zum Beispiel 2001:DB8:aaaa:bbbb::1/64, wobei 2001:DB8: und aaaa den du beim reservieren erhältst und bbbb der selbst festgelegte Teil (damit es zu einen /64 wird), mit dem Du die jeweiligen Netze der dezentralen Gateways unterscheidest. Im Monitoring wird die Adresse dann unter 2001:DB8:ffff:ffff:ffff:ffff:ffff:ff01 versteckt.
-==== dns ====
-{|
-! style="width:80px;text-align:left" | Name
-! style="width:120px;text-align:left" | Typ
-! style="width:80px;text-align:left" | Pflicht
-! style="width:80px;text-align:left" | Variante
-! style="text-align:left" | Beschreibung
-|-
-| server || list || nein || F/A || DNS-Server, auf den geforwarded wird*
-|-
-|}
-<nowiki>*</nowiki> Hinweis: Hier sollten auch IPv6-DNS-Server aufgelistet werden.
-==== batman ====
-{|
-! style="width:80px;text-align:left" | Name
-! style="width:120px;text-align:left" | Typ
-! style="width:80px;text-align:left" | Pflicht
-! style="width:80px;text-align:left" | Variante
-! style="text-align:left" | Beschreibung
-|-
-| iface || interface || nein || F/A || [[B.A.T.M.A.N.]] auf physikalisches auf Interface legen
-|-
-| vlan || int || nein || F/A || B.A.T.M.A.N. auf VLAN mit angegebener IP auf dem Standard-Switch* legen '''(alternativ zu ''iface''!)'''
-|-
-|}
-<nowiki>*</nowiki> Bei Adrian: Nur verwenden, wenn maximal EIN ethX mit tagged VLANs vorhanden ist!
-==== wan ====
-{|
-! style="width:80px;text-align:left" | Name
-! style="width:120px;text-align:left" | Typ
-! style="width:80px;text-align:left" | Pflicht
-! style="width:80px;text-align:left" | Variante
-! style="text-align:left" | Beschreibung
-|-
-| iface || interface || nein || A || WAN auf physikalisches auf Interface legen
-|-
-| vlan || int || nein || A || WAN auf VLAN mit angegebener IP auf dem Standard-Switch* legen '''(alternativ zu ''iface''!)'''
-|-
-|}
-<nowiki>*</nowiki> Bei Adrian: Nur verwenden, wenn maximal EIN ethX mit tagged VLANs vorhanden ist!
-==== babelpeer ====
-{|
-! style="width:80px;text-align:left" | Name
-! style="width:120px;text-align:left" | Typ
-! style="width:80px;text-align:left" | Pflicht
-! style="width:80px;text-align:left" | Variante
-! style="text-align:left" | Beschreibung
-|-
-| iface || interface || nein || F/A || Babel auf physikalisches Interface legen
-|-
-| vlan || number || nein || F/A || Babel auf VLAN mit angegebener IP auf dem Standard-Switch* legen '''(alternativ zu ''iface''!)'''
-|-
-| type || babel-type || nein || F/A || Babel-Verbindungstyp (z.&nbsp;B. ''wired'', ''wireless'', ''tunnel'', ...)
-|-
-| rxcost || int || nein || F/A || Babel rxcost
-|-
-| babel_penalty || int || nein || A || Penalty für eingehenden und ausgehenden Traffic
-|-
-| mtu || int || nein || A || MTU für Babel peering
-|-
-| fix_mtu || 0 oder 1 || nein || A || PMTU clamping aktivieren (default: aus)
-|-
-|}
-<nowiki>*</nowiki> Bei Adrian: Nur verwenden, wenn maximal EIN ethX mit tagged VLANs vorhanden ist!
-==== wireguardpeer ====
-{|
-! style="width:80px;text-align:left" | Name
-! style="width:120px;text-align:left" | Typ
-! style="width:80px;text-align:left" | Pflicht
-! style="width:80px;text-align:left" | Variante
-! style="text-align:left" | Beschreibung
-|-
-| endpoint_host || host oder ip || ja || F/A || Hostname oder IP-Adresse der Gegenstelle
-|-
-| endpoint_port || port || ja || F/A || Port der Gegenstelle
-|-
-| persistent_keepalive || seconds || nein || F/A ||
-|-
-| public_key || wireguard pubkey || ja || F/A || Öffentlicher Schlüssel des Peering-Partners
-|-
-| private_key || wireguard privkey || nein || F/A || Eigener privater Schlüssel (''automatisch generiert wenn nicht angegeben'')
-|-
-| rxcost || int || nein || F/A || Babel rxcost
-|-
-| babel_penalty || int || nein || A || Penalty für eingehenden und ausgehenden Traffic
-|-
-| mtu || int || nein || A || MTU für Babel peering
-|-
-| fix_mtu || 0 oder 1 || nein || A || PMTU clamping aktivieren (default: aus)
-|-
-|}
-==== babelfilter '<name>' ====
-{|
-! style="width:80px;text-align:left" | Name
-! style="width:120px;text-align:left" | Typ
-! style="width:80px;text-align:left" | Pflicht
-! style="width:80px;text-align:left" | Variante
-! style="text-align:left" | Beschreibung
-|-
-| &lt;name&gt; || string || ja || A || Name des generierten uci Eintrags
-|-
-| net || IPv6 network || ja || A || IPv6 Netzwerk (z.b. aaaa:bbbb:cccc::/48)
-|-
-| type || string || ja || A || z. Zt. nur 'redist'
-|-
-|}
-==== monitoring 'gwinfo' ====
-{|
-! style="width:80px;text-align:left" | Name
-! style="width:120px;text-align:left" | Typ
-! style="width:80px;text-align:left" | Pflicht
-! style="width:80px;text-align:left" | Variante
-! style="text-align:left" | Beschreibung
-|-
-| admin || list || nein || A || Admin-Namen für Monitoring
-|-
-| statslink || URL || nein || A || Web-Adresse für Statistik-Seite des GW
-|-
-| urls || list || nein || A || Zieladressen für gwinfo-Skript*
-|-
-|}
-<nowiki>*</nowiki> Wird 'urls' nicht angegeben, wird die Standard-Adresse verwendet. Verwendet man die option, fällt der default weg, und alle Zieladressen müssen hier genannt werden.
-==== monitoring 'alfred' ====
-{|
-! style="width:80px;text-align:left" | Name
-! style="width:120px;text-align:left" | Typ
-! style="width:80px;text-align:left" | Pflicht
-! style="width:80px;text-align:left" | Variante
-! style="text-align:left" | Beschreibung
-|-
-| urls || list || nein || A || Zieladressen für alfred-proxy-Skript*
-|-
-|}
-<nowiki>*</nowiki> Wird 'urls' nicht angegeben, wird die Standard-Adresse verwendet. Verwendet man die option, fällt der default weg, und alle Zieladressen müssen hier genannt werden.
-== Hardware-Port-Belegungen ==
+Siehe hier: [[Layer3Firmware_Config]]
-Die Switch-Port-Belegung für die gängigen und genutzten Router für die VLAN-Konfiguration.
+== Remote-Upgrade ==
+Seit der Firmware 20210211-beta werden die Einstellungen nach einem Update automatisch wieder richtig gesetzt. Es ist also nicht mehr nötig vorher spezielle Skripte einzustellen.
-==== TP-Link WDR4900 v1 ====
+<div class="toccolours mw-collapsible mw-collapsed" style="overflow: auto">
+Aktuell (Stand 20200501) ist es nach einem Upgrade nötig, configuregateway manuell auszuführen. Bis dahin ist die Netzwerkkonfiguration des Routers so wie beim ersten flashen! (/etc/config/gateway und /etc/config/fff werden aber übernommen)
-{|
+Daher ist ein Remote-Upgrade derzeit nicht einfach möglich. Behelfsmäßig kann configuregateway aber nach dem Booten automatisiert gestartet werden. Dies kann aber unter Umständen anfällig für diverse Nebenläufigkeitsprobleme sein.
-! Port
-! Switch Port
-|-
-| WAN || 1
-|-
-| LAN 1 || 2
-|-
-| LAN 2 || 3
-|-
-| LAN 3 || 4
-|-
-| LAN 4 || 5
-|-
-|}
-==== TP-Link WR1043ND v1 ====
+Dafür in /etc/rc.local.fff_userconfig folgendes einfügen (und nach abgeschlossenem Upgrade wieder entfernen!):
+ sleep 100
+ yes | configuregateway -c
+ configuregateway -a
+</div>
-{|
+== SNAT  ==
-! Port
-! Switch Port
-|-
-| WAN   || 0
-|-
-| LAN 1 || 1
-|-
-| LAN 2 || 2
-|-
-| LAN 3 || 3
-|-
-| LAN 4 || 4
-|-
-|}
-==== TP-Link WR1043ND v2, v3 ====
+Ab der Firmware 20220405-beta ist es möglich bei IPv4 für die Clients Adressen zu verwenden die nicht im Freifunk geroutet werden und auf eine einzelne IP Adresse zu NATten. Somit ist nur noch eine einzelne Freifunk IPv4 Adresse nötig. Dazu muss unter gateway 'meta' die Option router_ip gesetzt werden mit einer einzelnen IPv4 Adresse mit /32 Subnetzmaske die im Wiki reserviert wird (Beispiel: 10.50.261.33/32). Im Clientblock muss dann SNAT aktiviert werden indem die Option SNAT '1' gesetzt wird. Als IPv4 Adressen für die Clients sollten dort Adressen verwendet werden, die nicht im Freifunk geroutet werden z.b. 192.168.0.1/16, da hier ein NAT auf die einzelne Adresse erfolgt, kann dieses Subnetz auf vielen Routern gleichzeitig verwendet werden.
-''Achtung: Bei Adrian anders!''
+Eine Beispielconfig kann so aussehen:
-{|
+ config gateway 'meta'
-! Port
+ 	option router_ip '10.50.267.35/32' #die einzelne IP Adresse die im Wiki registriert wurde
-! Switch Port
+ 	option config_version '3'
-|-
-| WAN   || 5
+ config vlan '10'
-|-
+ 	option comment 'client'
-| LAN 1 || 4
+ 	option ports 'eth0:* eth1:* eth2:* eth3:* eth4:*'
-|-
-| LAN 2 || 3
+ config vlan '202'
-|-
+ 	option comment 'er_xxx'
-| LAN 3 || 2
+ 	option ports 'eth0:t'
-|-
-| LAN 4 || 1
+ config client
-|-
+ 	option vlan '10'
-| CPU  || 0
+ 	option ipaddr '192.168.0.1/16' # das Subnetz das überall verwendet werden kann, die exakt eingegebene Adresse hier bekommt der Router
-|-
+ 	list ip6addr '2a0b:f4c0:xx:xx::x/64'
-|}
+ 	list ip6addr 'fd43:5602:29bd:xx::x/64'
+ 	option dhcp_start '192.168.1.0' #DHCP Start
+ 	option snat '1' #aktiviert SNAT
+ config dns
+ 	list server 'fd43:5602:29bd:ffff:1:1:1:1'
+ 	list server 'fd43:5602:29bd:ffff:a:a:a:a'
+  config babelpeer 'er_xxx'
+ 	option vlan '202'
+ 	option type 'wired'
+ 	option rxcost '1024'
-==== TP-Link WR1043ND v4 ====
+Achtung!
+Die ClientIP Adressen sollten sich auf keinen Fall mit den IP Adressen vom Internetrouter (Fritzbox o.ä.) überschneiden wo der Freifunkrouter mit den WAN Port angeschlossen wird. Da hat die Firmware leider noch Probleme damit: https://git.freifunk-franken.de/freifunk-franken/firmware/issues/240 (dies gilt auch für nicht NAT, wenn da im priv. Netz 10.50/16 oder 10.83/16 verwendet wird, ist dies ebenfalls aktuell ein großes Problem!)
+Klassisch würde ich nicht 192.168.0/24 192.168.1/24 192.168.88/24 192.168.178/24 verwenden, es eignet sich z.b. 192.168.208.1/20 sehr gut
-{|
+== Besondere Konfigurationen (optional)  ==
-! Port
-! Switch Port
-|-
-| WAN   || 5
-|-
-| LAN 1 || 4
-|-
-| LAN 2 || 3
-|-
-| LAN 3 || 2
-|-
-| LAN 4 || 1
-|-
-| CPU  || 0
-|-
-|}
-== Leistungstests ==
+Mit der Layer-3 Firmware sind relativ einfach auch individuelle Ergänzungen konfigurierbar, ein paar Beispiele können hier gesammelt werden.
-{|
+* Die Client-Seite mit dem Freifunk kann per [[VLAN_ins_Hausnetz|VLAN ins Hausnetz]] ins Hausnetz getunnelt werden, wenn kein Platz für zusätzliche Kabel ist.
-! Gerät
-! System-on-a-Chip (SoC)
-! CPU [MHz]
-! WireGuard [Mbit/s]
-! Routing [Mbit/s]
-|-
-| TP-Link Archer C2600 || Qualcomm Atheros IPQ8064 || 2 × 1400 || 140–170 || ''unbekannt''
-|-
-| TP-Link Archer C7 v2 || Qualcomm Atheros QCA9558 || 720 || ca. 50 || ''unbekannt''
-|-
-| TP-Link TL-WDR4300 v1 || Atheros AR9344 || 560 || ca. 55 || ''unbekannt''
-|-
-| TP-Link TL-WDR4900 v1 || Freescale MPC85xx || 800 || 95–110 || 650–700
-|-
-| TP-Link TL-WR1043N/ND v1 || Atheros AR9132 || 400 || 40–46 || 150–200
-|-
-| TP-Link TL-WR1043N/ND v2&3 || Qualcomm Atheros QCA9558 || 720 || ca. 50 || ''unbekannt''
-|-
-| TP-Link TL-WR1043N/ND v4 || Qualcomm Atheros QCA9563 || 750 || ca. 80 || ''unbekannt''
-|-
-| Ubiquiti EdgeRouter X || || || ~200 || 800–930
-|-
-|}
 [[Kategorie:Technik]]
 [[Kategorie:Dezentrale Hood]]
 [[Kategorie:Gateways]]
+[[Kategorie:Layer-3]]