FunkFeuer Wiki - Benutzerbeiträge [de]

Startseite

2018-02-27T11:12:54Z

Kaefert:

Diese wiki wurde durch [http://wiki.funkfeuer.at das neue wiki] ersetzt. Dieses hier bitte ausschließlich als Read-Only Archiv verwenden!

{{ContainerBox|Wer sind wir?|
Funkfeuer.at ist jene Plattform, unter der österreichweit freie WLAN-Netze betrieben werden. Die Grundidee dabei ist, einen eigenen Wireless-LAN Netzwerkknoten zu betreiben und darüber entsprechend dem '''[http://www.funkfeuer.at/PicoPeeringAgreement.59.0.html PicoPeering Agreement]''' anderen Netzteilnehmern freien Daten-Transit zu ermöglichen.<br/>
Im Zusammenspiel mit dem dynamischen Routing Protokoll [http://www.olsr.org OLSR] entsteht damit fast von selbst ein gemeinschaftliches Netzwerk, bei dem jedoch die Komponenten des Netzes im Besitz der einzelnen Users verbleiben.
}}


== Bei Funkfeuer.at mitmachen ==
Funkfeuer versteht sich als ein soziales Netz, bei dem sich technisch Interessierte über alle politischen, kulturellen und sozialen Grenzen hinweg dem Thema [http://de.wikipedia.org/wiki/Freies_Funknetz Freier Netze in Österreich] widmen. Eine kurze Einführung wie ihr mitachen könnt findest du in unserer [[0xff_Einführung|Kurzeinführung]]

==Weitere Informationen zu Funkeuer.at==
*[http://www.funkfeuer.at Die 0xFF-Funkfeuer Homepage]
:ist das Aushängeschild des Vereins und stellt Links zu den einzelnen örtlichen Initiativen und den wichtigsten Services des Vereins zur Verfügung.

*[https://lists.funkfeuer.at/mailman/listinfo Die Funkfeuer Mailinglisten]
:dienen der schriftlichen Kontaktaufnahme innerhalb der einzelnen Communities und ist neben der Wiki eines unserer wichtigsten Dokumentaionsquellen.

*[http://gallery.funkfeuer.at/ Die Bildergalerie]
:ist unsere Foto-Sammlung, in der sich viele Panoramas, bilder von Knoten aber auch Events finden. Möglicherweise entdeckst du dein Dach auf einem Foto, dann ist es sehr wahrscheinlich dass du einen Link aufbauen kannst. Du kannst in der Galerie auch selbst Fotos von deinem Knoten hochladen.

*[[FAQ|Die Funkfeuer FAQs]]
:sind eine Sammlung von wissenswerten Informationen zu allen Themen im Kontext von Funkfeuer.at, freien Netzen und Wireless.Netzworks.

== Noch kein Funkfeuer in deiner Region? ==
Unter <b>[[Neue Initiativen]]</b> kannst du deine Kontaktinformationen veröffentlichen und so weitere Interessenten in deiner Gegend finden, die mit dir gemeinsam ein neues Netz aufbauen. Die bestehenden Funkfeuer-Netze stehen euch dann gerne mit Rat und Tat zur Seite!

__NOTOC__
__NOEDITSECTION__

Startseite

2014-01-24T10:16:28Z

Kaefert: /* Wer sind wir? */

<div style="background:#EEEEFF; border: 2px solid #C0C0D5; margin:10px; padding:0.5em">
== Wer sind wir? ==
Funkfeuer.at ist jene Plattform, unter der österreichweit freie WLAN-Netze betrieben werden. Die Grundidee dabei ist, einen eigenen Wireless-LAN Netzwerkknoten zu betreiben und darüber entsprechend dem '''[http://www.funkfeuer.at/PicoPeeringAgreement.59.0.html PicoPeering Agreement]''' anderen Netzteilnehmern freien Daten-Transit zu ermöglichen.<br/>
Im Zusammenspiel mit dem dynamischen Routing Protokoll [http://www.olsr.org OLSR] entsteht damit fast von selbst ein gemeinschaftliches Netzwerk, bei dem jedoch die Komponenten des Netzes im Besitz der einzelnen Users verbleiben.
</div>


== Bei Funkfeuer.at mitmachen ==
Funkfeuer versteht sich als ein soziales Netz, bei dem sich technisch Interessierte über alle politischen, kulturellen und sozialen Grenzen hinweg dem Thema [http://de.wikipedia.org/wiki/Freies_Funknetz Freier Netze in Österreich] widmen. Eine kurze Einführung wie ihr mitachen könnt findest du in unserer [[0xff_Einführung|Kurzeinführung]]

==Weitere Informationen zu Funkeuer.at==
*[http://www.funkfeuer.at Die 0xFF-Funkfeuer Homepage]
:ist das Aushängeschild des Vereins und stellt Links zu den einzelnen örtlichen Initiativen und den wichtigsten Services des Vereins zur Verfügung.

*[https://lists.funkfeuer.at/mailman/listinfo Die Funkfeuer Mailinglisten]
:dienen der schriftlichen Kontaktaufnahme innerhalb der einzelnen Communities und ist neben der Wiki eines unserer wichtigsten Dokumentaionsquellen.

*[http://gallery.funkfeuer.at/ Die Bildergalerie]
:ist unsere Foto-Sammlung, in der sich viele Panoramas, bilder von Knoten aber auch Events finden. Möglicherweise entdeckst du dein Dach auf einem Foto, dann ist es sehr wahrscheinlich dass du einen Link aufbauen kannst. Du kannst in der Galerie auch selbst Fotos von deinem Knoten hochladen.

*[[FAQ|Die Funkfeuer FAQs]]
:sind eine Sammlung von wissenswerten Informationen zu allen Themen im Kontext von Funkfeuer.at, freien Netzen und Wireless.Netzworks.

== Noch kein Funkfeuer in deiner Region? ==
Unter <b>[[Neue Initiativen]]</b> kannst du deine Kontaktinformationen veröffentlichen und so weitere Interessenten in deiner Gegend finden, die mit dir gemeinsam ein neues Netz aufbauen. Die bestehenden Funkfeuer-Netze stehen euch dann gerne mit Rat und Tat zur Seite!

__NOTOC__

Buffalo WHR-HP-G54

2012-04-23T10:46:29Z

Kaefert:

Dieser Router unterscheidet sich vom [[Buffalo_WHR-G54S]] lediglich dadurch, dass der auf dem WLAN-Chip integrierte Verstärker leistungsmäßig auf 10mW heruntergeschraubt wurde und dafür ein externer Verstärker dahinter platziert wurde ([[Vorverstärker-Endstufe-Prinzip]]).

Diese Konstruktion führt zu einem wesentlich saubereren (weil rauschfreieren) Ausgangssignal und soll laut Hersteller-Angaben zu einer Erhöhung der Reichweite um bis zu 70% bzw. zu einer Erhöhung der Performance um bis zu 50% (Buffalo's Turbo-G 125 "Highpower" - Technologie) führen.

Die Freifunk-Firmware überträgt man auf dieses Gerät [[Buffalo_WHR-G54S | wie beim Buffalo WHR-G54S per tftp]].

=== Recovery ===
Hatte letztens das Problem, dass mein Buffalo nicht mehr normal booten wollte. Habe das Problem mit Hilfe ein paar netter Leute auf der Mailingliste folgendermaßen beheben können:

1.) Beim booten den Schalter "SW1" drücken/kurzschliesen um in den Failsafe-Mode zu kommen. In diesem Failsafe mode reagiert der Router auf Pings und erlaubt telnet Verbindungen auf port 23. Alles andere scheint deaktiviert zu sein.

2.) Per Telnet verbinden

3.) mittels "cat /proc/mtd" die liste der filesysteme auslesen

4.) mittels "mtd -r erase rootfs_data" diese partition löschen --> durch die -r option wird nachher automatisch rebootet.

5.) Router ist wieder ganz normal funktionsfähig und kann per webinterface geflashed werden (was ich anschließend gemacht hab, um auf die default-funkfeuer-config zu kommen).

=== Die nvram boardflags Werte ===

* 0x0758: normale Sendeleistung und normale Empfangsempfindlichkeit
* 0x1758: normale Sendeleistung und verstärkte Empfangsempfindlichkeit
* 0x2758: verstärkte Sendeleistung und normale Empfangsempfindlichkeit
* 0x3758: verstärkte Sendeleistung und verstärkte Empfangsempfindlichkeit

=== Anzeigen und ändern der Boardflags ===

* Per SSH auf dem Router einloggen, dann auf der Kommandozeile eingeben:
nvram show | grep boardflags
oder
nvram get boardflags

Es sollte "0x1758" angezeigt werden.

* Z.B. den Wert auf 0x3758 ändern:
nvram set boardflags=0x3758
nvram commit
reboot

Dies führt zur Aktivierung der Sender-Endstufe und des Empfangs-Vorverstärkers.

[http://wiki.leipzig.freifunk.net/Buffalo_WHR-G54S#Anmerkungen Siehe auch die Anmerkungen hier]

zurück zu 0xff_Backfire-Vienna<br>
< [[0xff_Backfire-Vienna-Startseite|Startseite]] > < [[0xff_Backfire-Vienna-Firmware|Firmware]] > < [[0xff_Backfire-Vienna-Hardware|Hardware]] > < [[0xff_Backfire-Vienna-Standards|Standards]] > < [[0xff_Backfire-Vienna-Installation|Installation]] > < [[0xff_Backfire-Vienna-Aktivitäten|Aktivitäten]] > < [[0xff_Backfire-Vienna-Diverses|Diverses]] >

Arbeitsgruppe Chat

2011-10-18T07:05:21Z

Kaefert: /* Update: */

Unser Funknetz ermöglicht theoretisch noch immer Kommunikation unter den einzelnen Knotenbetreibern, selbst wenn alle zentrale Infrastruktur ausgefallen ist. Da aber nur wenige Leute überzeugt werden können, einen bestimmten dezentralen Instant Messenger zu installieren, muss eine Alternative her:

Der olsrd, der auf allen Knoten läuft, ist über Plugins in der Lage, beliebige Nachrichten über das Netz zu verbreiten ("zu flooden"). Normalerweise werden eben die Routinginformationen übertragen, genauso könnte man aber die derzeitige GPS-Position des Knotens mitsenden, den Ladezustand eines Akkus (bei Solarnodes) oder eben Chatnachrichten! Dabei werden diese Informationen nur von den Knoten auch verarbeitet, die das entsprechende Plugin installiert haben. Jeder Knoten leitet die Information aber an alle anderen weiter.

Es fehlt also nur noch eine Verbindung zwischen dem olsrd (bzw. einem zu entwickelnden "Chat-Plugin") und der Darstellung der Nachrichten auf der Weboberfläche des Routers.

Diese Schnittstelle können zum Beispiel einfache "Flat Files" sein: Textdateien, an die das Plugin empfangene Nachrichten anhängt (und den Anfang bei Überschreiten einer gewissen Größe der Datei abschneidet - die Größe der Datei bzw. die Anzahl der Zeilen könnte z.B. auf der Webseite des Chatplugins wählbar sein) bzw. aus denen es die zu übertragenden Nachrichten "abholt".

== Mitarbeiter: ==
* [[Benutzer:Aaron|Aaron]]: kümmert sich darum, dass so ein Plugin funktioniern würde bzw. wird es entwickeln
* [[Benutzer:Gregor|Gregor]]: Schnittstelle Plugin/Webinterface
* ???

== Update: ==
* Das Webinterface ist soweit fertig, fehlt nur noch das Plugin... Coders wanted! ;-)

* Nachdem es zur Zeit nicht zur Programmierung des Plugins kommen wird, wäre eine Alternative sich unter den an einem netzinternen Chat interessierten Personen auf einen LAN-Messenger zu einigen und diesen auszutesten.
* Liste von eingen LAN-Messengern: http://en.wikipedia.org/wiki/Comparison_of_LAN_messengers
* Vorzuziehen wäre einer der sowohl auf Linux als auch Windows funktioniert, wie z.B. http://sourceforge.net/projects/netc/

== Details ==
Schnittstelle Router/Client: Webinterface des Routers / AJAX

Ein Bild folgt in Kürze...

Am Client wird die Datei chat.html geladen (über Freifunk-Firmware/Administration). Nachrichten, die im Eingabefeld eingegeben werden, werden per AJAX an outbox.html übergeben, von dieser in outbox.txt eingetragen und an die Inbox von chat.html zurückgegeben. outbox.html muss prüfen ob das Plugin läuft, damit outbox.txt nicht übergeht! Vom Plugin wird die Nachricht aus outbox.txt abgeholt, dort gelöscht und per olsr übertragen...

Ankommende Nachrichten werden vom Plugin nach inbox.txt geschrieben. Überschreitet die Länge von inbox.txt einen vorgegebenen Wert, wird automatisch die älteste Nachricht gelöscht. Anschließend wird der Wert in counter.txt um eins erhöht, außer der Wert ist schon gleich der Anzahl an Nachrichten in inbox.txt.

chat.html fragt in regelmäßigen Abständen bei inbox.html nach neuen Nachrichten. Ist der Wert n in counter.txt ungleich Null, liegen neue Nachrichten vor. inbox.txt holt die letzten n Nachrichten aus inbox.txt ab, überträgt sie an die inbox von chat.html und setzt counter.txt auf Null. (Beim Start des Chats holt inbox.html ungeachtet von counter.txt alle Nachrichten aus inbox.txt und setzt counter.txt auf Null)

== Dateien ==
/www/cgi-bin/chat.html - Chatseite für das Webinterface
/www/cgi-bin/98olsrchat - Menüpunkt für das Webinterface
/www/cgi-bin/inbox.html - Script zur Beanwortung der AJAX-Anfragen
/www/cgi-bin/outbox.html - Script zur Beanwortung der AJAX-Anfragen
/www/inbox.txt - Link nach /tmp/chat/inbox.txt
/www/outbox.txt - Link nach /tmp/chat/outbox.txt
/www/counter.txt - Link nach /tmp/chat/counter.txt
/tmp/chat/inbox.txt - Container für die empfangenen Nachrichten. Ist vom Plugin beim Systemstart zu erstellen!
/tmp/chat/outbox.txt - Container für die zu sendenden Nachrichten. Ist vom Plugin beim Systemstart zu erstellen!

== Offene Fragen ==
* Was ist die maximale Nachrichtenlänge, die OLSR übertragen kann???
(einerseits detektiert der olsr die mtu eh selber (interface-specific), andererseits können pakete dann eh auch fragmentiert werden, allerdings ohne reliability im broadcast, machen solche riesenpakete dann wohl recht wenig freude (wenn nur teile ankommen),..)
* Soll ein Benutzername wählbar sein?
* Soll der Name des Routers mit den Nachrichten mit übertragen werden?
* Sollte man eine primitive Möglichkeit für Channels implementieren? (z.b. 1 byte channel-identifier)
** Hm... Es wäre natürlich sinnvoll, die dafür nötigen Voraussetzungen schon jetzt einzuplanen. Allerdings bezweifle ich, dass bei der zu erwartenden Nutzerzahl fürs Erste Bedarf dafür besteht... Außerdem: Kann man dann nur in einem Channel gleichzeitig sein? Falls nein: wo sollen die unterschiedlichen Channel aufscheinen, wie kann man zwischen ihnen wechseln?
(egal, hauptsache das feature ist drin, evt kann man das system dann auch für andere zwecke nutzen, nicht nur fürn webchat)

[[Category: WorkingWiki]]
[[Category: Arbeitsgruppen|Chat]]
[[Category: Arbeitsgruppe Chat]]
[[Category: Chat]]
[[Category: Software]]
[[Category: Development]]

Arbeitsgruppe Chat

2011-10-18T07:03:23Z

Kaefert: /* Update: */

Unser Funknetz ermöglicht theoretisch noch immer Kommunikation unter den einzelnen Knotenbetreibern, selbst wenn alle zentrale Infrastruktur ausgefallen ist. Da aber nur wenige Leute überzeugt werden können, einen bestimmten dezentralen Instant Messenger zu installieren, muss eine Alternative her:

Der olsrd, der auf allen Knoten läuft, ist über Plugins in der Lage, beliebige Nachrichten über das Netz zu verbreiten ("zu flooden"). Normalerweise werden eben die Routinginformationen übertragen, genauso könnte man aber die derzeitige GPS-Position des Knotens mitsenden, den Ladezustand eines Akkus (bei Solarnodes) oder eben Chatnachrichten! Dabei werden diese Informationen nur von den Knoten auch verarbeitet, die das entsprechende Plugin installiert haben. Jeder Knoten leitet die Information aber an alle anderen weiter.

Es fehlt also nur noch eine Verbindung zwischen dem olsrd (bzw. einem zu entwickelnden "Chat-Plugin") und der Darstellung der Nachrichten auf der Weboberfläche des Routers.

Diese Schnittstelle können zum Beispiel einfache "Flat Files" sein: Textdateien, an die das Plugin empfangene Nachrichten anhängt (und den Anfang bei Überschreiten einer gewissen Größe der Datei abschneidet - die Größe der Datei bzw. die Anzahl der Zeilen könnte z.B. auf der Webseite des Chatplugins wählbar sein) bzw. aus denen es die zu übertragenden Nachrichten "abholt".

== Mitarbeiter: ==
* [[Benutzer:Aaron|Aaron]]: kümmert sich darum, dass so ein Plugin funktioniern würde bzw. wird es entwickeln
* [[Benutzer:Gregor|Gregor]]: Schnittstelle Plugin/Webinterface
* ???

== Update: ==
* Das Webinterface ist soweit fertig, fehlt nur noch das Plugin... Coders wanted! ;-)

* Nachdem es zur Zeit nicht zur Programmierung des Plugins kommen wird, wäre eine Alternative sich unter den an einem Netzinternen Chat interessierten Personen auf einen LAN-Messenger zu einigen und auszutesten.
* Liste von eingen LAN-Messengern: http://en.wikipedia.org/wiki/Comparison_of_LAN_messengers
* Vorzuziehen wäre einer der sowohl auf Linux als auch Windows funktioniert, wie z.B. http://sourceforge.net/projects/netc/

== Details ==
Schnittstelle Router/Client: Webinterface des Routers / AJAX

Ein Bild folgt in Kürze...

Am Client wird die Datei chat.html geladen (über Freifunk-Firmware/Administration). Nachrichten, die im Eingabefeld eingegeben werden, werden per AJAX an outbox.html übergeben, von dieser in outbox.txt eingetragen und an die Inbox von chat.html zurückgegeben. outbox.html muss prüfen ob das Plugin läuft, damit outbox.txt nicht übergeht! Vom Plugin wird die Nachricht aus outbox.txt abgeholt, dort gelöscht und per olsr übertragen...

Ankommende Nachrichten werden vom Plugin nach inbox.txt geschrieben. Überschreitet die Länge von inbox.txt einen vorgegebenen Wert, wird automatisch die älteste Nachricht gelöscht. Anschließend wird der Wert in counter.txt um eins erhöht, außer der Wert ist schon gleich der Anzahl an Nachrichten in inbox.txt.

chat.html fragt in regelmäßigen Abständen bei inbox.html nach neuen Nachrichten. Ist der Wert n in counter.txt ungleich Null, liegen neue Nachrichten vor. inbox.txt holt die letzten n Nachrichten aus inbox.txt ab, überträgt sie an die inbox von chat.html und setzt counter.txt auf Null. (Beim Start des Chats holt inbox.html ungeachtet von counter.txt alle Nachrichten aus inbox.txt und setzt counter.txt auf Null)

== Dateien ==
/www/cgi-bin/chat.html - Chatseite für das Webinterface
/www/cgi-bin/98olsrchat - Menüpunkt für das Webinterface
/www/cgi-bin/inbox.html - Script zur Beanwortung der AJAX-Anfragen
/www/cgi-bin/outbox.html - Script zur Beanwortung der AJAX-Anfragen
/www/inbox.txt - Link nach /tmp/chat/inbox.txt
/www/outbox.txt - Link nach /tmp/chat/outbox.txt
/www/counter.txt - Link nach /tmp/chat/counter.txt
/tmp/chat/inbox.txt - Container für die empfangenen Nachrichten. Ist vom Plugin beim Systemstart zu erstellen!
/tmp/chat/outbox.txt - Container für die zu sendenden Nachrichten. Ist vom Plugin beim Systemstart zu erstellen!

== Offene Fragen ==
* Was ist die maximale Nachrichtenlänge, die OLSR übertragen kann???
(einerseits detektiert der olsr die mtu eh selber (interface-specific), andererseits können pakete dann eh auch fragmentiert werden, allerdings ohne reliability im broadcast, machen solche riesenpakete dann wohl recht wenig freude (wenn nur teile ankommen),..)
* Soll ein Benutzername wählbar sein?
* Soll der Name des Routers mit den Nachrichten mit übertragen werden?
* Sollte man eine primitive Möglichkeit für Channels implementieren? (z.b. 1 byte channel-identifier)
** Hm... Es wäre natürlich sinnvoll, die dafür nötigen Voraussetzungen schon jetzt einzuplanen. Allerdings bezweifle ich, dass bei der zu erwartenden Nutzerzahl fürs Erste Bedarf dafür besteht... Außerdem: Kann man dann nur in einem Channel gleichzeitig sein? Falls nein: wo sollen die unterschiedlichen Channel aufscheinen, wie kann man zwischen ihnen wechseln?
(egal, hauptsache das feature ist drin, evt kann man das system dann auch für andere zwecke nutzen, nicht nur fürn webchat)

[[Category: WorkingWiki]]
[[Category: Arbeitsgruppen|Chat]]
[[Category: Arbeitsgruppe Chat]]
[[Category: Chat]]
[[Category: Software]]
[[Category: Development]]

0xFF-Backfire Vienna - Testtage 2011

2011-10-01T15:53:29Z

Kaefert: /* Testobjekte: */

Unsere experimentellen '''Funkfeuer-Netze''' in Wien, in Graz, dem Weinviertel und all die kleinräumigen Initiativen in Österreich, die auf OpenWRT setzen, sind seit ihrem Bestehen mittlerweile zu einer beträchtlichen Größe herangewachsen. Lange haben wir von der Entwicklungsarbeit der Berliner Community und Sven Ola gelebt und nicht zuletzt mit Markits Patches und den bewährten Linksys & Cos. erfolgreich unsere Netze aufgebaut.

Jedoch, die Entwicklung ist nicht stehen geblieben - Durch die unsagbare Kompaktheit der Ubiquity-Produkte und den unschlagbaren Preisen von TP-Link wird es langsam an der Zeit, sich auch anderen Herstellern zuzuwenden, die aus Gründen der Politik der FCC mehrheitlich auf die offenen Treiber der Atheros-Reihe setzen.

Mit 0xFF-Backfire Vienna ist es uns gelungen, einen mehr oder weniger passenden Snapshot mit allen relevanten Settings für unser Wiener Netz zu erstellen, der allen gängigen Anforderungen für die Netzerweiterung mit Atheros-Produkten erfüllt. Eine Ausweitung auf andere Netze in Österreich und eine Konsolidierung mit der deutschen Freifunk-Community ist angestrebt und sehr wünschenswert.

Diese Testtage sollen Kompatibilität und Alltagstauglichkeit der Images demonstrieren und dazu beitragen, Konfigurationsfehler zu erkennen und diese optimieren.

== Zielsetzung: ==

===== Kompatibilität: =====
Bei der Einführung einer neune Softwaregeneration ist es unabdingbar, auf deren Kompatibilität zu bestehenden Konfiguration zu achten.

Aus diesem Grund ist eines unserer wichtigsten Aufgabe, die Tauglichkeit neuer Geräte (Hard- und Software) zueinander und mit bestehenden Geräten unter Laborbedingungen zu beweisen. Erst dann können wir diese mit gutem gewissen als "Standard" bewerben.

===== Mythen: =====
Ein experimentelles Netz dient dem experimentieren - Logisch. Jedoch entstehen durch Experimente in einem weitgehend inhomogenen Netz auch Mythen, die sich kaum mehr beseitigen lassen.

Ziel der Testtage soll es sein, einige dieser Mythen zu beweisen oder sie zu eliminieren.

===== Standard-Konfigurationen: =====
Der Support von Interessenten, die den Weg ins Metalab finden, ist erdenklich schlecht geworden. Klar haben wir Snapshots, die Wiki und auch unsere Mailing-Listen aber ich bin der Ansicht, durch die Vielzahl an Geräten und Konfigurationen ist die Hürde für eine nachhaltige Netzwerweiterung einfach zu hoch.

Ziel der Testtage soll es sein, hier zu einer überschaubaren Anzahl an Geräten und Konfigurationen zu finden, die den Einstieg um ein Vielfaches erleichtern. Wenn die Leute dann Fuß gefasst haben, kommt die experimentelle Komponente sicher nicht zu kurz.

===== Rating: =====
Welche Konfiguration für einen Anwendungsfall die Beste ist, entscheidet letztendlich jener, der den Node errichtet. Da Standardisierung aber immer nur zu einem gewissen Teil auf einen Anwendungsfall passt kann ein Rating als Entscheidungshilfe herangezogen werden.

Ziel der Testtage soll es sein, Geräte und Konfigurationen auf ihre Anwendungsfälle zu bewerten und mittels Rating eine Entscheidungsgrundlage für Node-Verantwortliche liefern.

== Organisatorisches: ==

===== Termin: =====
* Samstag, 15.10.2011, 10:00 - 22:00
* Sonntag, 16.10.2011, 10:00 - 17:00

===== Location: =====
''(Wird noch bekannt gegeben. Abhängig von der zu erwartenden Teilnehmerzahl)''

===== Team: =====
''Folgende Personen werden bei den Testtagen anwesend sein. (Bitte ergänzen)''

* JoeSemler ''Planung & Koordination''
* Erich Pekarek
* Aaron
* Gregor
* Martin A. (Sa. erst ab 18h)
* Martin M.
* Thomas K.

== Aufbau & Ablauf: ==

===== Testanoednung: =====
Die Tests finden an beigestellter Hardware unter Laborbedingungen statt. D.h. die Geräte werden über regelbare Dämpfungsanordnungen verbunden und über einen Messausgang messtechnisch überwacht. ''(Das Messequipment wir bereitgestellt)''

Dadurch wird klar, dass im Zuge der Testtage weniger das Verhalten im Mesh, sondern das Gerät mit seinen Schnittstelleneigenschaften im Funknetz im Vordergrund steht.

===== Agenda: =====
''Die detaillierte Agenda wird auf Basis der Testobjekte und Fragen zu einem späteren Zeitpunkt erstellt''

* 15.10.2011
* 16.10.2011

== Testobjekte & Tests: ==

In diesem Abschnitt sind alle Geräte, Konfigurationen und Kompatibilitätstests gelistet, die wir im Zuge der 0xFF-Backfire Vienna - Testtage 2011 untersuchen wollen. ''(Bitte ergänzen. Die einzelnen Fragestellungen können vorerst noch allgemein formuliert sein)''

==== Testobjekte: ====

{| border="3" cellpadding="10" cellspacing="0"
! Type || Beisteller 1* || Beisteller 2*
|-
| Bullet2 || Joe || Amadeus
|-
| Bullet5 || ? || ?
|-
| Bullet M2 || Martin A. || ?
|-
| Bullet M5 || Joe || Martin A.
|-
| AirGrid M2 || Joe || ?
|-
| AirGrid M5 || Harald || ?
|-
| Nanostation Loco M2 || Gregor || Runout
|-
| Nano Bridge M5 || Joe || ?
|-
| TL-1043ND || Martin A. || Runout (lagernd bei Alex S.)
|-
| TL-741ND || Joe || ?
|-
| TL-743ND || Runout || ?
|-
| R52 || Joe || ?
|-
| WRT54GL || Martin A. || ?
|-
| Buffalo WHR-HP-G54 || Thomas K. || ?
|-
| ''bitte Testobjekt zufügen'' || ? || ?
|}
'' * Um Gerätefehler ausschließen zu können sollten wir von jedem Testobjekt 2 Geräte zur Verfügung haben. Bitte hier eintragen, welche Personen die jeweiligen Testobjekte bereitstellen können''

==== Tests: ====

{| border="3" cellpadding="10" cellspacing="0"
! Testname* || Testart** || Testobjekt*** || Testpartner**** || Beschreibung || Eingebracht von
|-
| Sendeleistung der Geräte || G || alle || || Entsprechen die Leistungsangaben in der Firmware der Realität? || Joe
|-
| Empfindlichkeit der Geräte || G || alle || Referenzgerät || Vergleich der Empfindlichkeiten bis wann Übertragungen und mit welcher Bandbreite möglich sind. ''(Aufgrund des gewählten Testaufbaus ist n-Betrieb nicht möglich) Ideen?'' || Joe
|-
| Korrektheit der SNR Werte || G || alle || Referenzgerät/Quelle || Vergleich, ob die WLAN Parameter (SNR, noise, signal, biterror rate (?)) auch dem entspricht, was physikalisch stimmen sollte. Manche Treiber "schummeln" und liefern ungenaue Werte. Korrekte Werte bzw. bekannte Korrekturfaktoren sind aber wichtig, um SNR basierte Metriken fuer OLSR zu entwickeln || Aaron
|-
| Mythos ESSID bei AdHoc-Mode || K || noch festzulegen || ''noch festzulegen'' || Welchen Einfluss hat die Vergabe gleicher oder ungleicher ESSID bei der Verwendung von Backfire zu Backfire, von Backfire zu Freifunk, von Broadcom zu Broadcom, von Broadcom zu Atheros (oder madwifi zu ath9k),... || Joe
|-
| Zuverlässigkeit des Auto-Modes bei der Frequenzwahl || K || ausgewählte Geräte || Gerät mit fixer Kanalzuteilung || || Joe
|-
| Multi-SSID-Mode || K/G || alle || Diverse Geräte || Ist ein das Gerät in der Lage mehrere SSIDs auszustrahlen, ad-hoc und station mode nebeneinander zu betreiben und kann man auch tatsächlich über beide SSIDs verbinden. || Erich
|-
| max.Datenraten || G || einige || diverse Geräte || max.speed mit min.dBm und speed-diff ad-hoc zu master-client || Harald
|-
| EIRP-Messung || G || einige || diverse Geräte || in einigem Abstand (10-20m) 1-2-3 devs gleichzeitig ''Wird schwierig, da wir keinen Messraum haben und so mit ext. Störungen zu rechnen haben (Joe)''|| Harald
|-
| ''bitte nächsten Test hinzufügen'' || || || || ||
|}
'' * Eindeutiger Name der Testanordnung''
'' ** Gerätetest, Parametertest(G), Kompatibilitätstest(K)''
'' *** Name des Gerätes, das untersucht werden soll''
'' **** Gegenstelle, die bei Kompatibilitätstest der WLAN-Schnittstelle verwendet werden soll''

zurück zu 0xff_Backfire-Vienna<br>
< [[0xff_Backfire-Vienna-Startseite|Startseite]] > < [[0xff_Backfire-Vienna-Firmware|Firmware]] > < [[0xff_Backfire-Vienna-Hardware|Hardware]] > < [[0xff_Backfire-Vienna-Standards|Standards]] > < [[0xff_Backfire-Vienna-Installation|Installation]] > < [[0xff_Backfire-Vienna-Aktivitäten|Aktivitäten]] > < [[0xff_Backfire-Vienna-Diverses|Diverses]] >

0xFF-Backfire Vienna - Testtage 2011

2011-10-01T15:46:26Z

Kaefert: /* Team: */

Unsere experimentellen '''Funkfeuer-Netze''' in Wien, in Graz, dem Weinviertel und all die kleinräumigen Initiativen in Österreich, die auf OpenWRT setzen, sind seit ihrem Bestehen mittlerweile zu einer beträchtlichen Größe herangewachsen. Lange haben wir von der Entwicklungsarbeit der Berliner Community und Sven Ola gelebt und nicht zuletzt mit Markits Patches und den bewährten Linksys & Cos. erfolgreich unsere Netze aufgebaut.

Jedoch, die Entwicklung ist nicht stehen geblieben - Durch die unsagbare Kompaktheit der Ubiquity-Produkte und den unschlagbaren Preisen von TP-Link wird es langsam an der Zeit, sich auch anderen Herstellern zuzuwenden, die aus Gründen der Politik der FCC mehrheitlich auf die offenen Treiber der Atheros-Reihe setzen.

Mit 0xFF-Backfire Vienna ist es uns gelungen, einen mehr oder weniger passenden Snapshot mit allen relevanten Settings für unser Wiener Netz zu erstellen, der allen gängigen Anforderungen für die Netzerweiterung mit Atheros-Produkten erfüllt. Eine Ausweitung auf andere Netze in Österreich und eine Konsolidierung mit der deutschen Freifunk-Community ist angestrebt und sehr wünschenswert.

Diese Testtage sollen Kompatibilität und Alltagstauglichkeit der Images demonstrieren und dazu beitragen, Konfigurationsfehler zu erkennen und diese optimieren.

== Zielsetzung: ==

===== Kompatibilität: =====
Bei der Einführung einer neune Softwaregeneration ist es unabdingbar, auf deren Kompatibilität zu bestehenden Konfiguration zu achten.

Aus diesem Grund ist eines unserer wichtigsten Aufgabe, die Tauglichkeit neuer Geräte (Hard- und Software) zueinander und mit bestehenden Geräten unter Laborbedingungen zu beweisen. Erst dann können wir diese mit gutem gewissen als "Standard" bewerben.

===== Mythen: =====
Ein experimentelles Netz dient dem experimentieren - Logisch. Jedoch entstehen durch Experimente in einem weitgehend inhomogenen Netz auch Mythen, die sich kaum mehr beseitigen lassen.

Ziel der Testtage soll es sein, einige dieser Mythen zu beweisen oder sie zu eliminieren.

===== Standard-Konfigurationen: =====
Der Support von Interessenten, die den Weg ins Metalab finden, ist erdenklich schlecht geworden. Klar haben wir Snapshots, die Wiki und auch unsere Mailing-Listen aber ich bin der Ansicht, durch die Vielzahl an Geräten und Konfigurationen ist die Hürde für eine nachhaltige Netzwerweiterung einfach zu hoch.

Ziel der Testtage soll es sein, hier zu einer überschaubaren Anzahl an Geräten und Konfigurationen zu finden, die den Einstieg um ein Vielfaches erleichtern. Wenn die Leute dann Fuß gefasst haben, kommt die experimentelle Komponente sicher nicht zu kurz.

===== Rating: =====
Welche Konfiguration für einen Anwendungsfall die Beste ist, entscheidet letztendlich jener, der den Node errichtet. Da Standardisierung aber immer nur zu einem gewissen Teil auf einen Anwendungsfall passt kann ein Rating als Entscheidungshilfe herangezogen werden.

Ziel der Testtage soll es sein, Geräte und Konfigurationen auf ihre Anwendungsfälle zu bewerten und mittels Rating eine Entscheidungsgrundlage für Node-Verantwortliche liefern.

== Organisatorisches: ==

===== Termin: =====
* Samstag, 15.10.2011, 10:00 - 22:00
* Sonntag, 16.10.2011, 10:00 - 17:00

===== Location: =====
''(Wird noch bekannt gegeben. Abhängig von der zu erwartenden Teilnehmerzahl)''

===== Team: =====
''Folgende Personen werden bei den Testtagen anwesend sein. (Bitte ergänzen)''

* JoeSemler ''Planung & Koordination''
* Erich Pekarek
* Aaron
* Gregor
* Martin A. (Sa. erst ab 18h)
* Martin M.
* Thomas K.

== Aufbau & Ablauf: ==

===== Testanoednung: =====
Die Tests finden an beigestellter Hardware unter Laborbedingungen statt. D.h. die Geräte werden über regelbare Dämpfungsanordnungen verbunden und über einen Messausgang messtechnisch überwacht. ''(Das Messequipment wir bereitgestellt)''

Dadurch wird klar, dass im Zuge der Testtage weniger das Verhalten im Mesh, sondern das Gerät mit seinen Schnittstelleneigenschaften im Funknetz im Vordergrund steht.

===== Agenda: =====
''Die detaillierte Agenda wird auf Basis der Testobjekte und Fragen zu einem späteren Zeitpunkt erstellt''

* 15.10.2011
* 16.10.2011

== Testobjekte & Tests: ==

In diesem Abschnitt sind alle Geräte, Konfigurationen und Kompatibilitätstests gelistet, die wir im Zuge der 0xFF-Backfire Vienna - Testtage 2011 untersuchen wollen. ''(Bitte ergänzen. Die einzelnen Fragestellungen können vorerst noch allgemein formuliert sein)''

==== Testobjekte: ====

{| border="3" cellpadding="10" cellspacing="0"
! Type || Beisteller 1* || Beisteller 2*
|-
| Bullet2 || Joe || Amadeus
|-
| Bullet5 || ? || ?
|-
| Bullet M2 || Martin A. || ?
|-
| Bullet M5 || Joe || Martin A.
|-
| AirGrid M2 || Joe || ?
|-
| AirGrid M5 || Harald || ?
|-
| Nanostation Loco M2 || Gregor || Runout
|-
| Nano Bridge M5 || Joe || ?
|-
| TL-1043ND || Martin A. || Runout (lagernd bei Alex S.)
|-
| TL-741ND || Joe || ?
|-
| TL-743ND || Runout || ?
|-
| R52 || Joe || ?
|-
| WRT54GL || Martin A. || ?
|-
| ''bitte Testobjekt zufügen'' || ? || ?
|}
'' * Um Gerätefehler ausschließen zu können sollten wir von jedem Testobjekt 2 Geräte zur Verfügung haben. Bitte hier eintragen, welche Personen die jeweiligen Testobjekte bereitstellen können''

==== Tests: ====

{| border="3" cellpadding="10" cellspacing="0"
! Testname* || Testart** || Testobjekt*** || Testpartner**** || Beschreibung || Eingebracht von
|-
| Sendeleistung der Geräte || G || alle || || Entsprechen die Leistungsangaben in der Firmware der Realität? || Joe
|-
| Empfindlichkeit der Geräte || G || alle || Referenzgerät || Vergleich der Empfindlichkeiten bis wann Übertragungen und mit welcher Bandbreite möglich sind. ''(Aufgrund des gewählten Testaufbaus ist n-Betrieb nicht möglich) Ideen?'' || Joe
|-
| Korrektheit der SNR Werte || G || alle || Referenzgerät/Quelle || Vergleich, ob die WLAN Parameter (SNR, noise, signal, biterror rate (?)) auch dem entspricht, was physikalisch stimmen sollte. Manche Treiber "schummeln" und liefern ungenaue Werte. Korrekte Werte bzw. bekannte Korrekturfaktoren sind aber wichtig, um SNR basierte Metriken fuer OLSR zu entwickeln || Aaron
|-
| Mythos ESSID bei AdHoc-Mode || K || noch festzulegen || ''noch festzulegen'' || Welchen Einfluss hat die Vergabe gleicher oder ungleicher ESSID bei der Verwendung von Backfire zu Backfire, von Backfire zu Freifunk, von Broadcom zu Broadcom, von Broadcom zu Atheros (oder madwifi zu ath9k),... || Joe
|-
| Zuverlässigkeit des Auto-Modes bei der Frequenzwahl || K || ausgewählte Geräte || Gerät mit fixer Kanalzuteilung || || Joe
|-
| Multi-SSID-Mode || K/G || alle || Diverse Geräte || Ist ein das Gerät in der Lage mehrere SSIDs auszustrahlen, ad-hoc und station mode nebeneinander zu betreiben und kann man auch tatsächlich über beide SSIDs verbinden. || Erich
|-
| max.Datenraten || G || einige || diverse Geräte || max.speed mit min.dBm und speed-diff ad-hoc zu master-client || Harald
|-
| EIRP-Messung || G || einige || diverse Geräte || in einigem Abstand (10-20m) 1-2-3 devs gleichzeitig ''Wird schwierig, da wir keinen Messraum haben und so mit ext. Störungen zu rechnen haben (Joe)''|| Harald
|-
| ''bitte nächsten Test hinzufügen'' || || || || ||
|}
'' * Eindeutiger Name der Testanordnung''
'' ** Gerätetest, Parametertest(G), Kompatibilitätstest(K)''
'' *** Name des Gerätes, das untersucht werden soll''
'' **** Gegenstelle, die bei Kompatibilitätstest der WLAN-Schnittstelle verwendet werden soll''

zurück zu 0xff_Backfire-Vienna<br>
< [[0xff_Backfire-Vienna-Startseite|Startseite]] > < [[0xff_Backfire-Vienna-Firmware|Firmware]] > < [[0xff_Backfire-Vienna-Hardware|Hardware]] > < [[0xff_Backfire-Vienna-Standards|Standards]] > < [[0xff_Backfire-Vienna-Installation|Installation]] > < [[0xff_Backfire-Vienna-Aktivitäten|Aktivitäten]] > < [[0xff_Backfire-Vienna-Diverses|Diverses]] >