Version vom 21. Mai 2006, 21:02 Uhr

Allgemein

Funkfeuer VMWare DVD mit allen interessanten Tools

• Radio Mobile
• Firmware Builder
• DB
• Scripts
• Einstellungen

z.B für folgende Leute:

• Leute die ausprobieren möchten und Sachen verbessern möchten
• Andere Funkfeuer Initiativen (NÖ)
• Sicherung des heutigen Standes

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:

1. man macht seinen eigenen SMTP server -> hoher Aufwand
2. man hat einen SMTP-Server mit user/pw, der von jeder IP voll verfügbar ist
3. 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.

1. 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:

1. Client-IPs subnet, linksys IP, Client Ip 1-5, Broadcast
2. neben HNA bei devices
3. neben Smokeping bei devices
4. 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:

1. welche SSID soll verwendet werden (falls wir andere als freiesnetz_www.funkfeuer.at verwenden wollen)
2. welcher channel am Besten wäre
   1. damit man mit anderen omnis in Kontakt treten könnte
   2. 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(*):

1. entweder einfach streichen und kurz davor hinschreiben dass wir statt 255.255.252.0 255.255.255.248 verwenden müssen.
2. 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):

1. der Channel ändert sich bei einem Client und manche ziehen mit. Dann bleiben manche übrig die nicht mitgezogen haben.
2. ä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. Muellmann

• Linksys: neuer WL treiber - aaron
• Linksys: BSSID treiber - aaron

ausdokumentieren der Configurationsfiles

in /etc sollte man folgende infos in einer README finden.

1. Fimware version + Datum in der vars.sh

Nice to have

1. Schreiben der Firmware-Version auf den outpost mit der versionnummer in MD5 kodiert (gemeinsam mit dem ursprünglichen Password aus dem Frontend)
2. 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!
3. Im Laufe der zeit braucht das update-script immer länger!?
4. schnelleres draufspielen
5. sight_scan.sh-ergebnis im Webinterface sehen -> siehe Muel3
6. sight_scan script anpassen um die Channels benutzung in der Nähe des Knoten anzuzeigen => in welchem Bereich können wir ungestört funken?