|
|
| (5 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt) |
| Zeile 13: |
Zeile 13: |
| | | | |
| | elektra in berlin macht so was aehnliches mit einer mesh disk distro | | elektra in berlin macht so was aehnliches mit einer mesh disk distro |
| − |
| |
| − | =Netz=
| |
| − | ==Bandbreiten Management==
| |
| − | Wenn man mehrere Uplinks hat sollte sich der Verkehr automatisch an die Nutzung anpassen.
| |
| − |
| |
| − | ==Kennzahlen zur Statistik==
| |
| − | * Dichte des Graphen (Knoten nicht device)
| |
| − | * mittlere Dichte (Knoten nicht device)
| |
| − | * Anzahl an funktionierenden Knoten
| |
| − |
| |
| − | Das alles mit Graphen, die die Entwicklung über die Zeit darstellen - Historie.
| |
| − |
| |
| − | == Anbieten von SMTP-eMail ==
| |
| − |
| |
| − | Derzeit ist es '''nicht möglich ''' per smtp emails aus dem funkfeuer Netz zu schicken. Es sei denn man verwendet folgenden Workaround:
| |
| − | # man macht seinen eigenen SMTP server -> hoher Aufwand
| |
| − | # man hat einen SMTP-Server mit user/pw, der von jeder IP voll verfügbar ist
| |
| − | # man macht eine VPN- oder sonstige Verbindung in ein anderes Netz (z.B. TU) und verwendet den SMTP-Server dort.
| |
| − |
| |
| − | Vorschlag: Wir verwenden Login / PW aus dem Frontend und bieten den mail.funkfeuer.at als SMTP server mit login/pw-authentifizierung an.
| |
| − | postmaster@funkfeuer.at möge sich drum kümmern.
| |
| − |
| |
| − | Vorschlag: Wir verwenden Login / PW aus dem Frontend und bieten den outpost als SMTP server mit login/pw-authentifizierung an.
| |
| − | # Dies war bereits der Fall (wenn auch über outpost:/etc/passwd und n icht User/Password aus der NodeDB). Wurde von der hehren Vereinsleitung bzw. deren engster Umgebung "damals" offenbar als nicht erwünscht angesehen.
| |
| − |
| |
| − | ==SSH Zugang==
| |
| − |
| |
| − | ==Voip==
| |
| − |
| |
| − | ==Alternative Hardware==
| |
| − |
| |
| − | Asus 500g
| |
| − |
| |
| − | ...
| |
| − |
| |
| − | ==Wenn ein Server (outpost etc) down -> Notiz von sandwich==
| |
| − | Mit Angabe von Grund warum.
| |
| − |
| |
| − | Vielleicht sogar so machen, dass mehrere Ips/Server sich hinter einem DNS Eintrag befinden. Damit man eine höhere Verfügbarkeit erreicht. -> synchronisation zwischen den Servern
| |
| − |
| |
| − | oder auch eine Backup-Version auf dem Sandwich falls etwas anderes ausfällt.
| |
| − |
| |
| − | =Frontend=
| |
| − | ==kleine info-"i"s mit JS-Popup ==
| |
| − | à la http://www6.inode.at/inode.at/privat/internet/xdsl-privat/
| |
| − | - z.b. neben "Transfervolumen"
| |
| − |
| |
| − | Stellen:
| |
| − | # Client-IPs subnet, linksys IP, Client Ip 1-5, Broadcast
| |
| − | # neben HNA bei devices
| |
| − | # neben Smokeping bei devices
| |
| − | # neben Titel Mobile / Client IPs / Node / Device
| |
| − |
| |
| − | ==Anzeige der Firmware-Version==
| |
| − | im Frontend. jeder sieht nur die eigene. Jedoch kann man dann auch eine Statistik sehen, wie viele welche Firmware haben.
| |
| − |
| |
| − | Das können wir erreichen mit einem Script, dass alle 24h zurückruft (wget) mit einer verschlüsselten Meldung "ich bin version XXX". Alternativ kann man auch schauen, welche Version man zuletzt herunter geladen hat.
| |
| − |
| |
| − | ==Anzeige von Konfigurations-Empfehlungen==
| |
| − | durch die Daten von sight_scan.sh:
| |
| − | # welche SSID soll verwendet werden (falls wir andere als freiesnetz_www.funkfeuer.at verwenden wollen)
| |
| − | # welcher channel am Besten wäre
| |
| − | ## damit man mit anderen omnis in Kontakt treten könnte
| |
| − | ## damit man nicht unter der Belastung von anderen WLAN devices der Gegend steht, die auf dem gleichen Channel funken.
| |
| − |
| |
| − | ==Subnet mask bei Client IPs ändern oder streichen==
| |
| − | im Moment wird neben jeder der 8 IPs eine Subnet mask angezeigt. das sollte sich ändern(*):
| |
| − | # entweder einfach streichen und kurz davor hinschreiben dass wir statt 255.255.252.0 255.255.255.248 verwenden müssen.
| |
| − | # ersetzen von 255.255.252.0 durch die richtige 255.255.255.248 (anzeigen neben den IPs 3-7)
| |
| − |
| |
| − | (*) Warum? Seit es CIDR gibt ist eine IP-Adresse ohne Netzmaske im Prinzip wertlos. Bei einer Übersicht über
| |
| − | genau ein IP-Netz reicht es wohl, da die allgemein gültige Netzmaske einmal hinzuschreiben, aber im Zweifelsfall
| |
| − | lieber öfters wie seltener hinschreiben.
| |
| − | Wenn Platzverbrauch/Übersichtlichkeit leidet, dann eher auf 1.2.3.4/29 Schreibweise umsteigen - spart Platz, ist
| |
| − | genauso verständlich und bei IPv6 gibt es eh nichts anderes mehr.
| |
| − | -> sehr gut, wer kann das umsetzen?
| |
| − |
| |
| − | =Webseite www.funkfeuer.at=
| |
| − | ==Shop zum tauschen / kaufen / verkaufen==
| |
| − | * Siehe [[Kauf-/Tauschplattform]]
| |
| − |
| |
| − | == Google Earth Integration in der Karte ==
| |
| − |
| |
| − |
| |
| − | -> erledigt! siehe aktuelle karte http://sandwich.funkfeuer.at/patrick/map
| |
| − |
| |
| − | Wie wäre es, wenn wir auf der Wien Karte einen Link zu einem kml-File machen mit den Koordinaten des Knotens. Dann sieht man sofort die Straße usw.
| |
| − |
| |
| − | Hier ein Beispiel des KML-Files (mit Koordinaten des Google HQs):
| |
| − | <?xml version="1.0" encoding="UTF-8"?>
| |
| − | <kml xmlns="http://earth.google.com/kml/2.0">
| |
| − | <Placemark>
| |
| − | <description>Tethered to the ground by a customizable tail</description>
| |
| − | <name>Tethethed placemark</name>
| |
| − | <LookAt>
| |
| − | <longitude>-122.0856375356631</longitude>
| |
| − | <latitude>37.42240551227282</latitude>
| |
| − | <range>305.8880792294568</range>
| |
| − | <tilt>46.72425699662645</tilt>
| |
| − | <heading>49.06133439171233</heading>
| |
| − | </LookAt>
| |
| − | <visibility>0</visibility>
| |
| − | <Style>
| |
| − | <IconStyle>
| |
| − | <Icon>
| |
| − | <href>root://icons/palette-3.png</href>
| |
| − | <x>96</x>
| |
| − | <y>160</y>
| |
| − | <w>32</w>
| |
| − | <h>32</h>
| |
| − | </Icon>
| |
| − | </IconStyle>
| |
| − | </Style>
| |
| − | <Point>
| |
| − | <extrude>1</extrude>
| |
| − | <altitudeMode>relativeToGround</altitudeMode>
| |
| − | <coordinates>-122.0856204541786,37.42244015321688,50</coordinates>
| |
| − | </Point>
| |
| − | </Placemark>
| |
| − | </kml>
| |
| − | ----
| |
| − | Ein .kml-File kann auch mehrere Ordner, Layer und Placemarks beinhalten.
| |
| − | Hierzu ein Beispiel:
| |
| − |
| |
| − | http://www.ofenmarkt.at/funkfeuer/0xFF.kml (<- "Ziel speichern unter...", sonst nackter source im Browser(.xml)! GoogleEarth muß installiert sein, DL @ http://earth.google.com
| |
| − |
| |
| − | --lst20050412
| |
| − |
| |
| − | =Funkfeuer Firmware=
| |
| − |
| |
| − | == Asus WL-500g Anleitung ==
| |
| − | Wie konfiguriere ich die Asus damit sie mit FF funktioniert?
| |
| − |
| |
| − | == Linksys Konfigurationsvaliderung ==
| |
| − | Folgende Möglichkeiten:
| |
| − | * update_nvram_and_configs.sh anpassen, dass nur gültige Einstellungen (z.B. HNA) benutzt werden. Sonst werden sie einfach ignoriert. Am Besten Nachricht sofort (oder vielleicht automatisches Mail?)
| |
| − | * kleiner Cron-Job, der Änderungen an HNA und vars.sh-Settings an eine Zentrale Stelle (PHP Script mit DB) verschickt. Dann eMail oder blackliste wenn Verstoß.
| |
| − | * Auf jeden Fall Dokumentation der Conf-Files...
| |
| − |
| |
| − | == Lösung des BSSID-Split Problems ==
| |
| − |
| |
| − | Derzeit kann es vorkommen, dass die Linksys oder andere OLSR Clients durchknallen (schon 3x mal zirka passiert):
| |
| − | # der Channel ändert sich bei einem Client und manche ziehen mit. Dann bleiben manche übrig die nicht mitgezogen haben.
| |
| − | # ähnlich: eine Device möchte auf einmal WEP haben: plötzlich versuchen alle mitzuziehen, jedoch haben sie kein key: die verbindung bricht ab.
| |
| − |
| |
| − | Es fallen dadurch Knoten mehrere Stunden / Tage aus.
| |
| − |
| |
| − | Sie müssen rebootet / resettet werden (gleichzeitig, sonst fängt das theater gleich wieder an).
| |
| − |
| |
| − | Lösungsvorschläge:
| |
| − | * Watchdogtimer, der auf WEP und Channel achtet. WLAN sollte danach kurz ruhen, dass alle anderen auch reseten können. Dann sollte sich der Watchdog eine Zeitlang still stellen damit die Linsys nicht ständig rebootet. Problem sind andere devices -> auf die kann man so nicht einwirken. [[Benutzer:Muelmann|Muellmann]]
| |
| − |
| |
| − | * Linksys: neuer WL treiber - aaron
| |
| − | * Linksys: BSSID treiber - aaron
| |
| − |
| |
| − | ==ausdokumentieren der Configurationsfiles==
| |
| − | in /etc sollte man folgende infos in einer README finden.
| |
| − |
| |
| − | # Fimware version + Datum in der vars.sh
| |
| − |
| |
| − | ==Nice to have==
| |
| − | # Schreiben der Firmware-Version auf den outpost mit der versionnummer in MD5 kodiert (gemeinsam mit dem ursprünglichen Password aus dem Frontend)
| |
| − | # Schreiben der Einstellungen der Linksys (HNA etc.) auf den outpost damit ein check erfolgt. Wenn fehler -> sofort email oder sogar automatischer Asterisk VOIP anruf auf Handy!
| |
| − | # Im Laufe der zeit braucht das update-script immer länger!?
| |
| − | # schnelleres draufspielen
| |
| − | # sight_scan.sh-ergebnis im Webinterface sehen -> siehe [[Muel3]]
| |
| − | # sight_scan script anpassen um die Channels benutzung in der Nähe des Knoten anzuzeigen => in welchem Bereich können wir ungestört funken?
| |
