Parallele Änderungen auf mehreren Nodes (OSX)
- Details
- Geschrieben von: Eric
- Kategorie: Router
SSH mit RSA-Schlüssel unter Windows
- Details
- Geschrieben von: Eric
- Kategorie: Router
Allgemeines
Die Sendeleistung ist ein wichtiger Parameter für jeden Freifunk-Router. Zum Einen steigt mit höherer Leistung die Reichweite, die Verbindung wird stabiler und der Datendurchsatz ist höher. Zum Anderen stört man mit hoher Leistung den Empfang benachbarter WLAN-Router. Außerdem müssen die gesetzlichen Vorgaben beachtet werden.
Für den Zugriff aufs Freifunk-Netz mittels verschiedener Endgeräte ist es nicht unbedingt hilfreich, wenn der Freifunk-Router mit besonders hoher Leistung sendet. An einem Smartphone wird dann z.B. auch in größerer Entfernung noch ein einwandfreier Empfang angezeigt ("viele Balken"). Für eine nutzbare Verbindung muß das Smartphone aber auch Daten in Richtung Router senden können. Da die Sendeleistung eines Smartphones aber nicht so hoch wie die des Routers ist, kann der Router vom Smartphone nichts mehr empfangen. Der Benutzer des Smartphones sieht also das Freifunk-Netz mit scheinbar guter Qualität, kann dieses aber nicht nutzen. Ein Betrieb der Freifunk-Router oberhalb der gesetzlich vorgeschriebenen maximalen Sendeleistung ist deswegen nicht sinnvoll.
Gesetzliche Vorgaben
Für Freifunk nutzen wir die beiden für den den Betrieb ohne Anmeldung zugelassenen Frequenzbereiche bei 2,4 GHz und bei 5 GHz. In der Community Gera-Greiz verwenden wir konkret die Kanäle 6 (2,437 GHz) und 44 (5,220 GHz). Im 2,4 GHz-Bereich ist eine maximale Sendeleistung von 100mW (entspricht 20 dBm) ohne weitere Einschränkungen zulässig.
Im 5GHz-Bereich ist das komplizierter. Dort existieren die Subbänder 1a (5,150 bis 5,250 GHz), 1b (5,250 bis 5,350 GHz) und 2 (5,470 bis 5,725 GHz)
Subband | Frequenz | Kanäle | max. Leistung | Besonderheiten |
---|---|---|---|---|
1a | 5,150 bis 5,250 GHz | 36, 40, 44, 48 | 23 dBm (200 mW) | nur indoor |
1b | 5,250 bis 5,350 GHz | 52, 56, 60, 64 | 20 dBm (100 mW) | DFS, nur indoor |
23 dBm (200 mW) | DFS und TPC, nur indoor | |||
2 | 5,470 bis 5,725 GHz | 100, 104, 108, 112 136, 140 |
27 dBm (500 mW) | DFS |
30 dBm (1000 mW) | DFS und TPC |
Da derzeit unsere Firmware (GLUON) weder Dynamische Frequenzwahl (DFS) noch Transmission Power Control (TPC) unterstützt, können wir damit nur drinnen auf den Kanälen 36-44 mit 200mw (entspricht 23 dBm) funken.
Routerparameter
Für die von unserer Firmware unterstützten Router gilt folgende Tabelle. Dabei ist der unter "Antenne" angegebene Wert der Antennengewinn laut Datenblatt. Die Defaultwerte wurden nach der Installation unserer Freifunk-Firmware ermittelt, ohne daß irgendwelche Parameter geändert wurden. Die einzelnen Werte können auf der Konsole (Login mit SSH) wie folgt ermittelt werden:
- TX-Power, TX power offset: "iwinfo"
- TX power list: "iwinfo client0 txpowerlist" bzw. "iwinfo client1 txpowerlist"
Der TX power offset drückt die Erhöhung der Sendeleistung durch Antennengewinn und evtl. Verstärker aus. Dieser Wert wird bei der Anzeige von TX-Power und der txpowerlist von iwinfo bereits berücksichtigt (Quelle: Sourcecode). Kommen also z.B. bei der Ubiquiti Picostation M2 8dBm Leistung aus dem WLAN-Chip, werden diese vom nachfolgenden Verstärker um 12dB auf 20 dBm verstärkt. Letzteren Wert zeigt iwinfo unter TX-Power an. Der Wert des TX power offset wird übrigens nicht aus dem Router ausgelesen, sondern ist in der Freifunk-Firmware (GLUON/OpenWRT) hinterlegt.
Die empfohlene TX-Power ergibt sich aus:
max. Sendeleistung entsprechend der gesetzlichen Vorgaben
- Antennengewinn
+ 1 dB geschätzter Verlust durch Lötstellen/Kabel/Stecker
Damit ergibt sich die durch gesetztliche Vorgaben und die Routerhardware eingeschränkte maximal mögliche Sendeleistung. Gesetzt wird der Wert auf der Konsole (SSH) wie folgt:
uci set wireless.radio0.txpower=x uci commit wifi
x ist hierbei die gewünschte Leistung in dBm. Dummerweise wird nun hier der TX power offset nicht berücksichtigt. Für das Beispiel der Ubiquiti Picostation M bedeutet das, daß zum Erzielen der gewünschten maximal zulässigen Sendeleistung von 20 dBm ein Wert von 8 eingetragen werden muß (8 dBm + 12 dB Offset = 20 dBm).
Im Config-Mode kann dies unter den Experteneinstellungen auch geändert werden. Wie der Offset und andere Parameter an dieser Stelle berücksichtigt werden, müssen wir noch ermitteln. Die Ergebnisse werden dann hier einfließen.
Modell | Band | Antenne | Defaultwerte unter GLUON v2016.1.2 | empfohlene TX-Power | Bemerkungen | ||
---|---|---|---|---|---|---|---|
TX-Power | TX power offset | txpowerlist | |||||
TP-Link TL-WR841N/ND v9 TP-Link TL-WR841N/ND v10 |
2,4 GHz | 5 dBi | 16 dBm | unknown | 0...20 | default (leer) | vor GLUON 2016.x war die Sendeleistung per default zu hoch |
TP-Link TL-WR1043N/ND v2 | 2,4 GHz | 5 dBi | 14 dBm | unknown | 0...20 | 16 | geht nur mit „uci set wireless.radio0.country=00“ |
TP-Link TL-WDR3600 v1 | 2,4 GHz | 2 dBi | 17 dBm | unknown | 0...21 | 19 | geht nur mit „uci set wireless.radio0.country=00“ |
5 GHz | 3 dBi | 14 dBm | none | 0...15 | default (leer) | geht nicht höher wie 14 (egal welches Country) | |
Ubiquiti Nanostation M (2) | 2,4 GHz | 11 dBi | 29 dBm | 11 dB | 11...29 | 20 (Anzeige iwinfo) 9 (wireless.radio0.txpower) |
per default Sendeleistung zu hoch! |
Ubiquiti Bullet M (Picostation M2) | 2,4 GHz | 2 dBi | 28 dBm | 12 dB | 12...28 | 20 (Anzeige iwinfo) 8 (wireless.radio0.txpower) |
per default Sendeleistung zu hoch! TX power offset 12 wohl wegen Antenne=2dBi und Zusatzverstärker 10 dB |
Ubiquiti Bullet M (Nanostation Loco M2) | 2,4 GHz | 8 dBi | 28 dBm | 8 dB | 8...28 | 20 (Anzeige iwinfo) 12 (wireless.radio0.txpower) |
per default Sendeleistung zu hoch! |
Ubiquiti UAP Pro | 2,4 GHz | 5 dBi | 20 dBm | unknown | 0...20 | 15 | per default Sendeleistung zu hoch! |
5 GHz | 4 dBi | 20 dBm | unknown | 0...20 | 19 | per default Sendeleistung zu hoch! |
Interessante Links zum Thema
https://wiki.opennet-initiative.de/wiki/WLAN_Frequenzen
http://www.wlan-skynet.de/docs/rechtliches/etsi_301_893.shtml
http://www.wlan-skynet.de/docs/rechtliches/sendeleistung.shtml
- Details
- Geschrieben von: Matthias Drobny
- Kategorie: Router
Ein Firmware-Update des Routers per SSH ist für "Profis" einfacher als der normale Weg über den Konfigurationsmodus. Bei letzterem muß man an den Router erst einen PC anschließen, den Router in den Konfigurationsmodus versetzen und dann im Expert-Mode updaten. Per SSH funktioniert das Updaten mittels Netzwerkzugriff von überall an einem laufenden Router. Man muß natürlich vorher den SSH-Zugriff auf den Router freigeschaltem haben.
Die einzelnen Schritte:
sync echo 3 > /proc/sys/vm/drop_caches cd /tmp wget http://1.updates.services.ffggrz/stable/sysupgrade/gluon-ffggrz-0.7.2-ubiquiti-picostation-m-sysupgrade.bin sysupgrade gluon-ffggrz-0.7.2-ubiquiti-picostation-m-sysupgrade.bin
Zuerst werden alle eventuellen Änderungen in den Flash geschrieben, dann zum Freigeben des Speichers die caches gelöscht. Nach dem Verzeichniswechsel nach /tmp wird das Update-Image dorthin kopiert. Im Beispiel per wget direkt von unserem Updateserver für eine Picostation, das geht alternativ z.B. auch mit scp vom lokalen Rechner. Mit "sysupgrade" erfolgt dann das eigentliche Upgrade. Der Router startet danach mit dem neuen Image.
Achtung: beim Link zur Firmware ggf von https auf http umstellen, sonst geht es nicht.
- Details
- Geschrieben von: Hendrik Wittig
- Kategorie: Router
<
Allgemeines
In den Freifunk-Netzwerken wird auf den Nodes nicht die originale Firmware der Router-Hersteller genutzt, sondern eine speziell für diesen Zweck von den Mitgliedern der Communities erstellte eigene Firmware. Diese basiert generell auf OpenWrt, welches durch verschiedene Pakete ergänzt wird.
Leider gibt es keine einheitliche "Freifunk-Firmware", stattdessen erstellt jede Community ihre eigene Variante. Diese unterscheiden sich teilweise erheblich, wie auch die gesamte darunterliegende Infrastruktur. Es spricht aber nichts dagegen, beim Aufbau einer neuen Community die Firmware einer anderen Community zu nutzen und diese an die eigene Infrastruktur anzupassen. Trotzdem bleibt zumindest die schwierige Aufgabe, sich für eine der Firmware-Varianten zu entscheiden. Da auch die Infrastruktur dazu passen muß, ist eine spätere Umstellung nicht ganz einfach.
Um das Erstellen der Firmware zu erleichern, wurden im Laufe der Zeit verschiedene Frameworks entwickelt. In letzter Zeit verbreitet sich besonders Gluon, welches von der Lübecker Community entwickelt wird. Da es sich um ein aktuell stark entwickelndes Framework mit vielen interessanten Funktionen handelt, haben wir uns auch in unserer Community für Gluon entschieden.
Firmware erstellen
Im Normalfall wird die aktuell in der Community verwendete Firmware für die unterstützten Routertypen fix und fertig zum Download zur Verfügung gestellt. Diese muß dann nur noch auf dem Router installiert werden. Demgegenüber wird im Folgenden beschrieben, wie man sich das Firmware-Paket selbst erstellen kann, sei es nur "für die Wissenschaft" oder um z.B. ein nicht unterstütztes Routermodell zu verwenden.
Voraussetzungen
Das Erstellen der Firmware erfolgt unter Linux. Im Prinzip ist jede aktuelle Distribution nutzbar, wir verwenden meist Gentoo. Da es sich hierbei um eine Source-Distribution handelt, sind die benötigten Build-Tools (GCC usw.) i.d.R. bereits installiert. Zusätzlich wird Git zum Zugriff auf die Versionsverwaltung benötigt. Gluon verfügt über eine gute Dokumentation, diese benutzen wir als Grundlage für die folgenden Schritte.
Download der Quellen
Die Quellen werden nach dem Wechsel ins Build-Root mitels Git ausgecheckt (heruntergeladen):
$ mkdir -p ~/Develop/Freifunk $ cd ~/Develop/Freifunk $ export RELEASE="ffggrz-1.0.2" $ export GLUON_RELEASE="1.0.2" $ git clone https://github.com/ffggrz/gluon.git gluon-$RELEASE -b $RELEASE $ cd gluon-$RELEASE
export GLUON_RELEASE="1.0.2" gibt an, daß wir nachfolgend unsere Firmware-Version 1.0.2 erstellen wollen. Diese Versionsnummer ist später in den Image-Namen enthalten und wird z.B. auch in der Karte angezeigt.
Durch export RELEASE="ffggrz-1.0.2" wird in diesem Beispiel das mit "ffggrz-1.0.2" markierte GLUON-Release unserer Community (eigener Fork auf Github) ausgecheckt und anschließend gebaut. Um stattdessen den aktuellen Entwicklungsstand zu verwenden, kann man
$ export RELEASE="master"
angeben. Das sollte aber nur für Experimente genutzt werden.
Site-Konfiguration
Jede Community nutzt eine eigene Infrastruktur, welche sich zumindest durch Hostnamen und IP-Adressen von der anderer Communities unterscheidet. Diese Unterschiede müssen in der eigenen Firmware hinterlegt werden. Dazu gibt es die sogenannte Site-Konfiguration, normalerweise ist jede Community eine eigene Site. Theoretisch könnten sich aber auch mehrere Communities eine Infrastruktur teilen und haben dann eine identische Site-Konfiguration. Andererseits könnte eine große Community mehrere Sites mit unterschiedlicher Infratruktur und damit unterschiedlicher Konfigurationen betreiben.
Im Verzeichnis docs/site-example befindet sich eine Beispiel-Konfiguration. Diese wird in das site-Verzeichnis kopiert und anschließend an die eigene Infrastruktur angepaßt:
$ cp -r docs/site-example site
Die aktuell von unserer Community genutzte Konfiguration ist in unserem Repository auf GitHub abgelegt. Um diese zu verwenden, wird statt dem Kopierbefehl mit Git ausgecheckt:
$ git clone https://github.com/ffggrz/site-ffggrz.git site -b $RELEASE
Damit wird die zum Bauen der in $RELEASE definierten Firmware-Version (im Beispiel 1.0.2) genutzte site-Konfiguration heruntergeladen. Die zum Bauen der letzten experimentellen Version genutzte Konfiguration liegt im Master-Branch, um diese auszuchecken, kann einfach das "-b $RELEASE" weggelassen werden.
Firmware bauen
Die Firmware wird nun mit den folgenden Kommandos erstellt:
$ export GLUON_LANGS="en de" $ export GLUON_BRANCH=stable $ make update $ make GLUON_TARGET=ar71xx-generic
Mittels "make update" werden die aktuellen Sourcen der verschiedenen Projektbestandteile heruntergeladen.
Das anschließende make-Kommando baut dann die Firmware. Dabei kennzeichnet "GLUON_BRANCH=stable" die Firmware als stabile Variante, das ist wichtig für den Auto-Updater. In unserer site.conf sind noch die Branches "beta" und "experimental" definiert. GLUON_LANGS="en de" ergibt die Sprachunterstützung für deutsch und englisch. "GLUON_TARGET=ar71xx-generic" erstellt die Firmware für die üblichsten der unterstützten Router (AR71xx-basierend).
Alle derzeit verfügbaren Targets können mit dem Script "buildalltargets" auf einmal erstellt werden:
$ export GLUON_LANGS="en de" $ export GLUON_BRANCH=stable $ make update $ buildalltargets
Router flashen
Die erstellte Firmware befindet sich, ausgehend vom Build-Root (~/Develop/Freifunk/gluon-$RELEASE) im Verzeichnis "output/images". Die factory-Images werden zum Flashen von Routern benutzt, welche noch die Original-Firmware des Herstellers besitzen. Mit den sysupgrade-Images werden Router upgedatet, welche bereits mit der Freifunk-Firmware oder einer anderen OpenWRT-Version laufen.
Update
Ein Update von Gluon erfolgt mit folgender Befehlssequenz:
$ cd ~/Develop/Freifunk $ export RELEASE="ffggrz-1.0.2" $ export GLUON_RELEASE="1.0.2" $ export GLUON_LANGS="en de" $ export GLUON_BRANCH=stable $ cd gluon-$RELEASE $ git pull $ make update $ make GLUON_TARGET=ar71xx-generic
Nach "git pull" sollte noch kontrolliert werden, ob die site-Konfiguration angepaßt werden muß.
Signieren
Damit die automatischen Updates der Nodes funktionieren, muß die Firmware signiert werden. Dafür benötigt man die ECDSA-Utils:
# emerge -av ecdsautils
Danach werden die Key erzeugt:
$ cd ~/Develop/Freifunk $ mkdir Update-Signaturen $ cd Update-Signaturen $ ecdsakeygen -s > user-secret $ ecdsakeygen -p < user-secret > user-public
Der public Key (Inhalt von user-public) wird in die site.conf eingetragen. Das Signieren erfolgt dann mittels:
{{{ $ cd ~/Develop/Freifunk $ export RELEASE="ffggrz-1.0.2" $ export GLUON_BRANCH=stable $ cd gluon-$RELEASE $ make manifest $ ./contrib/sign.sh ~/Develop/Freifunk/Update-Signaturen/user-secret ./output/images/sysupgrade/$GLUON_BRANCH.manifest }}}- Details
- Geschrieben von: Jörg
- Kategorie: Router