Es wurden verschiedene Szenarien aufgebaut um Engpässe im Datenverkehr zu lokalisieren. Dabei zeigte sich, dass es einen deutlichen Unterschied zwischen der "normalen" Richtfunknutzung und der Übertragung von Freifunk-Datenverkehr gab.
| Aufbauszenario | Technik |
Bandbreite2 in MBit/s |
|---|---|---|
| 1a |  |
930 |
| 1b |  |
934 |
| 2a |
originale Ubiquiti-Firmware |
460 |
| 2b | wie 2a, aber mit Verschlüsselung WPA2/PSK | 450 |
| 2c |
wie 2a, aber mit VLANs |
411 |
| 3a |
|
- Dieser Aufbau funktioniert nicht, da auf dem Laptop kein Batman vorhanden ist. |
| 3b |  |
180 Die Messung erfolgte zwischen Laptop und HP DC direkt. iperf wurde per opkg nachinstalliert. |
| 3c |  |
180 |
| 3d |  |
190 |
| 4 |  |
880 möglicher Loop im Netz! |
- Details
- Geschrieben von: Eric
- Kategorie: Backbone Planung
Zweck
Der Backbone bildet das Rückgrat unseres Netzwerkes. Er soll größere Strecken überbrücken und so die Vernetzung auch weiter voneinander entfernter Standorte ermöglichen.
Aufbau
Gesamtstruktur
In folgenden Bild ist als Beispiel der grundlegende Aufbau mit mehreren Standorten dargestellt:
- Details
- Geschrieben von: Matthias Drobny
- Kategorie: Backbone Planung
<
Hardware
Auf Grund des vergleichweise hohen Traffics, welcher an Backbone-Standorten zu erwarten ist, scheiden die üblichen Consumer-Router zur Anbindung an die Gateways aus. Das gilt erst recht, wenn an dieser Stelle gleich ein separates Gateway eingesetzt wird. Eine empfehlenswerte Hardware für diesen Einsatz sind die APU-Boards von PC Engines. Diese haben z.B. eine recht leistungsfähige CPU (AMD G series, Duals- oder Quad-Core, 1 GHz), Verschlüsselungsunterstützung in Hardware (AES-NI), 2-4 GB RAM u.v.a.
Konkret kommt im Folgenden eine APU.2C4 (Quad-Core, 4 GB RAM) mit einer mSATA-SSD von 30 GB zum Einsatz.
Linux-Installation
Allgemeines
Als Linux-Distribution wird im folgenden Beispiel Gentoo installiert. Die Installation findet von einem PC aus statt, auf welchem ebenfalls Gentoo Linux läuft.
SystemRescueCd am APU-Board
Die Installation soll mit Hilfe der SystemRescueCd erfolgen. Diese ist allerdings beim APU-Board nicht so einfach wie gewohnt einsetzbar. Neben dem fehlenden CD-Laufwerk hat dieses auch keine Videokarte. Also muß als Installationsmedium ein USB-Stick genutzt werden, alle Ein-und Ausgaben müssen anfangs über die serielle Schnittstelle erfolgen.
Dazu wird die SystemRescueCd laut Anleitung auf einem USB-Stick installiert. In Kurzform (ACHTUNG: nicht einfach kopieren! Datei- und Gerätenamen anpassen!):
# mount -o loop /tmp/systemrescuecd-x86-4.7.2.iso /mnt/cdrom/ # mkfs.vfat -F 32 -n SYSRESC /dev/sdb1 # dd if=/usr/share/syslinux/mbr.bin of=/dev/sdb # sync # mount -t vfat /dev/sdb1 /mnt/usbstick/ # cp -af /mnt/cdrom/* /mnt/usbstick/ # rm -rf /mnt/usbstick/syslinux # mv /mnt/usbstick/isolinux/isolinux.cfg /mnt/usbstick/isolinux/syslinux.cfg # mv /mnt/usbstick/isolinux /mnt/usbstick/syslinux # umount /mnt/usbstick/ # syslinux /dev/sdb1 # sync
Im obigen Beispiel ist der USB-Stick /dev/sdb, dieser verfügt bereits über eine Partition /dev/sdb1. Das ISO-Image der SystemRescueCd Version 4.7.2 liegt in /tmp.
Anschließend wird der Inhalt der Datei "/syslinux/syslinux-cfg" auf dem USB-Stick mit Folgendem ersetzt:
SERIAL 0 115200
CONSOLE 0
default SystemRescue
ALLOWOPTIONS 0
TIMEOUT 600
LABEL SystemRescue
MENU LABEL ^SystemRescue
KERNEL rescue64
INITRD initram.igz
APPEND console=ttyS0,115200n8 docache setkmap=de rootpass=root
Damit startet ein 64Bit-Kernel, der gesamte Inhalt der SystemRescueCD wird in den RAM kopiert und als Console dient ttyS0 mit einer Geschwindigkeit von 115200 Baud.
Das APU-Board wird nun über die linke Netzwerkbuchse (Blick auf die Buchsen) ans Netzwerk angeschlossen, in welchem sich ein DHCP-Server befinden sollte. An die serielle Schnittstelle wird ein PC angeschlossen und dort ein Terminalprogramm gestartet, welches auf 115200 baud (8N1) eingestellt wird. Nach Anschließen des Netzteiles ans APU-Board sollte im Terminal der Start verfolgt werden können.
Um nicht die gesamte Installation über die serielle Konsole durchführen zu müssen, sollte man sich nun per SSH anmelden (Nutzer "root" mit Paßwort "root").
Gentoo-Grundinstallation
Es erfolgt eine normale Installation entsprechend dem Gentoo-Handbuch für AMD64-Systeme. Auf dem mSATA-Laufwerk wird eine GUID Partition Table (GPT) angelegt, die Partitionierung erfolgt nach dem Default Partitioning Scheme mit einer 2MB BIOS-Boot-Partition (sda1), einer 128MB Boot-Partition (sda2), 4GB Swap (sda3) und dem Rest als Root-Partition (sda4).
Es wird ein Hardened Gentoo installiert, dafür also das passende Stage3 und der entsprechende Kernel gewählt.
Um nach der Installation wieder über die serielle Console zugreifen zu können, wurde folg. angepaßt:
/etc/inittab:
# SERIAL CONSOLES s0:12345:respawn:/sbin/agetty -L 115200 ttyS0 vt100
/etc/default/grub:
# Append parameters to the linux kernel command line for non-recovery entries GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0,115200n8" # Uncomment to disable graphical terminal (grub-pc only) GRUB_TERMINAL=serial GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"
Die Netzwerk-Konfiguration erfolgt vorerst nur für den ersten Port (enp1s0) mit DHCP.
Nach dem abschließenden Neustart sollte der Zugriff sowohl über die serielle Konsole als auch über Netzwerk per SSH möglich sein.
Anpassungen
Nach der Installation werden noch grundlegende Anpassungen vorgenommen:
NTP wird installiert:
# emerge -av ntp
Danach wird die Konfiguration angepaßt:
/etc/ntp.conf:
driftfile /var/lib/ntp/ntp.drift # Pools for Gentoo users server 0.gentoo.pool.ntp.org server 1.gentoo.pool.ntp.org server 2.gentoo.pool.ntp.org server 3.gentoo.pool.ntp.org # By default, exchange time with nobody. restrict default ignore restrict -6 default ignore # allow server pools above restrict source nomodify notrap noquery # Local users may interrogate the ntp server more closely. restrict 127.0.0.1 restrict ::1
Nun werden Client und Server gestartet und in den Default-Runlevel aufgenommen:
# rc-service ntp-client start # rc-service ntpd start # rc-update add ntp-client default # rc-update add ntpd default
Es wird Layman installiert und unser Freifunk-Gentoo-Repository angelegt:
# emerge -av layman # cd /etc/layman/overlays # wget https://raw.githubusercontent.com/ffggrz/ff-overlay/master/ff-overlay.xml # layman -L # layman -a ff-overlay
Nun werden noch etliche nützliche Programme installiert:
# emerge -av logrotate sudo nano man-pages-de mc screen screenservice gentoolkit nullmailer tcpdump traceroute bind-tools nfs-utils iperf dmidecode iproute2 pciutils pam_ssh_agent_auth acpid
Der Screen-Service wird in den Default-Runlevel integriert:
# rc-update add screen default
sudo wird konfiguriert:
sudoedit /etc/sudoers
## Uncomment to allow members of group wheel to execute any command %wheel ALL=(ALL) ALL Defaults env_keep += SSH_AUTH_SOCK
/etc/pam.d/sudo:
auth [success=2 default=ignore] pam_ssh_agent_auth.so file=~/.ssh/authorized_keys auth include system-auth account include system-auth session include system-auth
Nach dieser Konfiguration ist es nach einem erfolgreichen Login als normaler Benutzer möglich, mittels sudo Root-Rechte zu bekommen. dazu muß der Benutzer Mitglied der Gruppe "wheel" sein und ssh mit dem Parameter "-A" aufrufen.
Es werden alle Administrator-Accounts angelegt, inkl. der zugehörigen SSH-Keys.
Offloader-Konfiguration
Allgemeines
Bei der Konfiguration als Offloder arbeitet das APU-Board im Wesentlichen wie ein normaler Freifunk-Knoten.
Interfaces
Das APU-Board verfügt über 3 Interfaces. Beim Blick auf die Interfaces werden die von links nach rechts wie folgt nummeriert:
enp1s0, enp2s0, enp3s0
enp1s0 wird als externes (WAN-) Interface verwendet und je nach Anforderung konfiguriert (/etc/conf.d/net). Im einfachsten Fall für DHCP:
############################### # Externe Anbindung ############################### config_enp1s0="dhcp"
Über enp2s0 kann ein Client angeschlossen werden, welcher sich mit dem Mesh-Netz verbindet. Dafür wird erstmal keine Konfiguration benötigt:
############################### # Client-Interface (Mesh) ############################### config_enp2s0="null"
enp3s0 wird als IEEE802.1Q-Trunk konfiguriert. Über einen Switch werden daran dir Richtfunkstrecken und die Router für den Clientzugriff angeschlossen.
############################### # Trunk ############################### vlans_enp3s0="11 12 13 14" config_enp3s0="null" config_enp3s0_11="null" config_enp3s0_12="null" config_enp3s0_13="null" config_enp3s0_14="null"
enp1s0 ist bereits aktiviert, die anderen beiden Interfaces werden wie folgt in den Runlevel "default" aufgenommen:
# cd /etc/init.d # ln -s net.lo net.enp2s0 # ln -s net.lo net.enp3s0 # rc-service net.enp2s0 start # rc-service net.enp3s0 start # rc-update add net.enp2s0 default # rc-update add net.enp3s0 default
Client-Bridge
Die Client-Brige "br-client"überträgt den Traffic des Mesh-Netzes.
Dafür werden die Bridgeutil benötigt:
# emerge -av bridge-utils
Zur Konfiguration wird /etc/conf.d/net wie folgt ergänzt:
############################### # Bridge ############################### bridge_ggrzBR="enp2s0" config_br_client="null" brctl_br_client="setfd 0 sethello 10 stp off"
Die Bridge wird nach Anlegen der erforderlichen Symlinks gestartet und in den Runlevel default aufgenommen:
# cd /etc/init.d # ln -s net.lo net.br-client # rc-service net.br-client start # rc-update add net.br-client default
B.A.T.M.A.N.
Zuerst wird B.A.T.M.A.N. installiert:
emerge -av batman-adv batctl
Die dazugehörige Konfiguration in /etc/conf.d/net:
###############################
# Mesh-Interfaces
###############################
config_bat0="null"
rc_net_bat0_need="net.br-client"
###############################
# Up-/Down-Scripts
###############################
preup() {
if [[ $IFACE == bat0 ]] ; then
/sbin/modprobe batman-adv
fi
return 0
}
postup() {
if [[ $IFACE == bat0 ]] ; then
/sbin/brctl addif br-client $IFACE
fi
return 0
}
predown() {
if [[ $IFACE == bat0 ]] ; then
/sbin/brctl delif br-client $IFACE
fi
return 0
}
Das B.A.T.M.A.N.-Interface bat0 wird nach Anlegen der erforderlichen Symlinks gestartet und in den Runlevel default aufgenommen:
# cd /etc/init.d # ln -s net.lo net.bat0 # rc-service net.bat0 start # rc-update add net.bat0 default
FastD
FastD baut einen Tunnel zu den Gateways auf, über welchen dann die weitere Kommunikation erfolgt. Die Installation erfolgt mittels:
# emerge -av fastd
wird fortgesetzt...
- Details
- Geschrieben von: Jörg
- Kategorie: Backbone Planung
- Erster Besuch
- Persönlicher Kontakt zählt auch heute noch viel
- Besichtigung der Örtlichkeiten
- Hochauflösende Fotos der Umgebung machen
- Wichtig für die spätere Auswertung und Nachschlagemöglichkeit
- ggf. später wenn Wetter/Sicht besser (Gegenlicht-Problem vermeiden)
- Fotos der möglichen Montagebereiche (Innen) machen
- Vertragsentwurf vorbereiten
- Besonderheiten mit einarbeiten
- Entwurf vorab aushändigen
- Technisches Konzept erstellen
- Linkstrecken definieren
- Userzugänge definieren
- Notwendiges Material kalkulieren
- Installationsplan erstellen
- Zweiter Besuch
- Technisches Konzept vorstellen
- Lokale Infrastruktur klären
- Strom
- Erdung
- Was darf angebohrt werden, was nicht
- Bestellung/Bereitstellung Material
- Installation (VDE-gerecht)
- ggf. Abnahme durch ??? / Abnahmeprotokoll Kopie an Standortverantwortlichen/Genehmiger
- Dokumentation der Installation (Fotos machen!)
- ggf. Installationsplan den Realitäten anpassen (für Ablage)
- Allgemeine Definitionen
- Hardware Einsatz
- Backbone -> WDS Linkstrecken auf 5 GHZ Ubi-Geräte (Radardetection gibts mit OpenWrt nicht)
- Userzugänge -> Freifunk-Software, 2,4 GHZ, Ubi-Geräte
- Hardware Einsatz
- Details
- Geschrieben von: Eric
- Kategorie: Backbone Planung
Im Folgenden werden Kriterien für Backbone-Standorte definiert. Die Punkte liefern eine Orientierung, worauf bei der Auswahl von Standorten zu achten ist. Aus Dokumentationsgründen könnte eine Bewertungstabelle bei der Auswahl helfen.
Standort
- Genehmigung des Eigentümers
- Sichtverbindung (inkl. Fresnel-Zone) zu anderen Backbone-Standorten
- Platz/Installationstauglichkeit/Geschütztheit
- Router
- Antenne
- Gateway/Supernode
- möglichst leistungsfähige Internet-Anbindung (um Gateway/Supernode zu installieren)
- Nutzbarer Stromanschluß, Verlegung bis Installationort möglich
- Blitzschutz notwendig/vorhanden/installierbar
Medienwirksamkeit/Wichtigkeit für das gesamte Netz
- Anbindungsnutzen
- Endnutzer im Umkreis
- Abstrahlung für Endknoten
- Abstrahlung andere Backbonestandorte (Brückenknoten)
- Details
- Geschrieben von: Eric
- Kategorie: Backbone Planung
<name>space
geschlossen seit 09.10.2024 23:37 Uhr