Testbed-questions

2011-11-10T15:57:05Z

Aaron: initial list of testing steps and research questions

== Questions for tests in the CONFINE testbed ==

{| border="3" cellpadding="10" cellspacing="0"
! Testname || Description || Indoor (I)/Outdoor (O) || Requirements
|-
| noise-level || Use all Wifi cards to measure the noise level in a city wide mesh network. Aggregate the data. Average over time. The idea is to create a baseline of measurements which serve as a comparison for other measurements || O || identical Wi-Fi cards in each outdoor router
|-
|}

[[Category:CONFINE]]

0xFF-Backfire Vienna - Testtage 2011 (EN)

2011-11-10T15:48:28Z

Aaron: add confine category

= 0xFF-Backfire Vienna - Testing days 2011 =

Our Funkfeuer networks in Vienna, Graz, Bad Ischl, Weinviertel and many small initiatives in Austria grew to a respectable size. For a long time these communities have been highly influenced by Sven-Ola and the Berlin Freifunk Firmware.

However, time did not stand still and due to the very good compact design of Ubiquity and the unbeatable price of TP-Link time has come to take a look at new products which mainly build upon the successful atheros chipset line.

The 0xFF-Backfire Vienna firmware managed to offer a reasonable snapshot of the most common used settings of the Vienna Funkfeuer network. In addition this firmware manages to fulfill most requirements of above mentioned atheros based devices.

Therefore, theses "testing days" also have the goal of improving the 0xFF-Backfire Vienna firmware images. Mistakes in configuration and settings shall be discovered and solved.

== Goals ==

=== Compatibility ===

When introducing a new software generation (0xFF-Backfire Vienna) it is crucial to maintain compatibility with existing devices and configurations
Therefore our first goal shall be to prove the compatibility of the new software with the existing devices (hard- and software compatibility tests). Tests will be done under lab-conditions (with professional testing equipment). Only after this test, we can claim the new software and hardware generation to be our new (Funkfeuer) "standard" setup.

=== Myths ===
Over the course of the last years in Funkfeuer, a couple of myths developed around devices and configuration settings. The goal of the tests thus shall be to eliminate these myths or to confirm them via rigorous tests.

=== Standard Configuration ===

Funkfeuer has a large and diverse set of devices in it's network. The support for these devices deteriorated over the last years. Goal of the "testing days" shall be to find a smaller set of confirmed working hardware devices + firmware + settings combination which is easy enough for newcomers. Later, when a newcomer gained experience, experiments will be available anyway.

=== Rating: ===

We also want to rate different combinations in order to give newcomers a basis for deciding which hardware they should buy.

== Organizational things ==

=== Date & Time ===
* Sat, 15.10.2011, 10:00 - 22:00
* Sun, 16.10.2011, 10:00 - 17:00

=== Location: ===
ORF- Zentrum Wien
Würzburggasse 30, A-1136 Wien, Raum: GPS 0.3
[https://docs.google.com/document/d/1CfhFuR6tCzhXjO_duchPk6NT8twNTmVGr4qTH5CbFl0/edit?hl=de Orientierungsplan]

Reachability:

*U4 Station Hütteldorf. 58b -> Stop ORF-Zentrum
*U6 Philadelphiabrücke - 8a -> Stop ORF-Zentrum

=== Participants ===

[https://docs.google.com/document/d/1SAcgqe6KD5_1LYXHbaZLhFluc1OWB2z4JHRG_eFBcts/edit?hl=de list of participants]

== Schedule ==
=== Agenda ===
lage
=====15th Oct 2011=====
:10:00 - 11:00 Welcome & Socializing
:11:00 - 12:00 Agenda & MeetingPlanning
:12:00 - 13:00 Lunch
:13:00 - 18:00 Workshops 1st Part
:18:00 - 19:00 Dinner
:19:00 - 22:00 Workshops 2nd Part

=====16th Oct 2011=====
:10:00 - 10:30 Welcome & Review
:10:30 - 13:00 Presentation & Discussion (dokuSTREAM)
:13:00 - 14:00 Lunch
:14:00 - 16:30 Presentation & Discussion (testSTREAM)
:16:30 - 17:00 Closing

Printable [https://docs.google.com/document/d/1-T_UctHH5WHSurRmP3XsxK8it6Y6PFibFpXF-iZWlyo/edit?hl=de agenda]

=====dokuStream: Specification & Documentation=====
:"we want to improve the WIKI, structure it, create pictures and screenshots of the installation and we want to define the base-setup of any 0xFF-Backfire Vienna setup"

:''Specifically we want to handle these Work-Packages:''
:*[https://docs.google.com/document/d/1Hbi5SSIx267-ThmfizENZiPFSfNvXS0JaQlqF-45ddg/edit?hl=de Structure of the Backfire Wiki and base-info ''(infoWIKI)'']
:*[https://docs.google.com/document/d/1VP--Rs5Icmt90STY1Taz6b4Ktv_Mu-lrdE8-weSPCfk/edit?hl=de documentation on the installation of Backfire Vienna ''(installDOKU)'']
:*[https://docs.google.com/document/d/11Liv8sZjSpV1ux6UshVmzq1e2kOqxNsghzvLAs5THPg/edit?hl=de Packages & Defaults ''(devCONF)'']

=====testStream: Testing=====

:"Here we will handle technical issues concerning the Backfire Vienna firmeware as well as technical issues of hardware. We intend to produce confirmed and repeatable statements concerning transmission power, sensitivity of devices. We also want to do some 'mythbusting'"

:''Specifically we want to handle these Work-Packages:''
:*[https://docs.google.com/document/d/1UzLbOA44IVVG27MNvOLiRjoAdQUvsw6i3Uvbp2Z2AQE/edit?hl=de HF-Parameters & their Performance ''(testWIRELESS)'']
:*[https://docs.google.com/document/d/1lhDKxFuByJjZ_fnnj9pxMU0GPqIJiWqzEW-a4p_AkgE/edit?hl=de Mythbusting: ESSID & AdHoc ''(ESSID@AdHoc)'']
:*[https://docs.google.com/document/d/1p1SfNYFSDiOkplgLKbinx9yJLF6PGg6hAKmi--mxYd4/edit?hl=de Verfying AutoDeviceConfig Mode ''(LuCI-ADC)'']
:*[https://docs.google.com/document/d/1I9w62jJuowk6YrFhu0Li-Hde7sab2KekAseT-w4LerI/edit?hl=de MultiSSID-Mode ''(multiSSID)'']

Please take a look at the individual packages and decide upfront where you want to participate.

== Testobjekte & Tests: ==

This section lists all devices and configutations and compatbility tests which will be measured in the 0xFF-Backfire Vienna testing days 2011.
(please add any that you want to have tested)

==== Testobjects: ====

{| 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
|-
| Nanostation Loco M5 || Erich ? || ?
|-
| Nano Bridge M5 || Joe || markit
|-
| TL-1043ND || Martin A. || Runout (currently at Alex S.)
|-
| TL-741ND || Joe || ?
|-
| TL-743ND || Runout || ?
|-
| R52 || Joe || markit
|-
| evt. R52N + boards || markit || markit
|-
| (maybe) Rocket + mimo antennas || markit || markit
|-
| WRT54GL || Martin A. || Erich
|-
| Buffalo WHR-HP-G54 || Thomas K. || Joe
|-
| wlan-usbsticks || ? || markit
|-
| Alix Boards mit R52hn || Aaron || Aaron
|-
| QMP node [http://qmp.cat/redmine/projects/qmp/wiki/Monster_Box_v2] || p4u || roger
|-
| Compex WPE 72-7A [http://www.compexshop.com/product_info.php/cPath/63/products_id/395] & Compex WLE200NX [http://www.compexshop.com/product_info.php/cPath/57_93/products_id/379] || p4u || p4u
|-
| ''please add'' || ? || ?
|}
'' * in order to minimize individual errors of individual devices, please take two of each device''

==== Tests: ====

{| border="3" cellpadding="10" cellspacing="0"
! Testname* || Testtype** || Testobject*** || Testpartner**** || Description || Proposed by
|-
| TX power of the device || G || all || || Does the measured tx power match up with the txpower setting in the firmware? || Joe
|-
| Sensitivity of the device || G || all || reference device || Compare the sensitivities. Until when (which SNR limit) can we achieve good throughput (bits/sec rate)? (due to the testing method we will not be able to do tests for 802.11n in this case) || Joe
|-
| correctness of the SNR values || G || alle || reference device/ source || 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
|-
| bridge or not || G || tp-link1043 || u.a.switches || mit vlans - bridge-hakerl am lan od. wan ? || Harald
|-
| ips lokal-global || G || tp-link1043 || u.a.switches || sind mit vlans am lokal port globale ips nötig || Harald
|-
| real world throughput single-hop || G || || || welche wlan treiber && settings sind auf identer funkstrecke/(und idealerweise hardware) wie nützlich || markit
|-
| real world throughput multi-hop || G || || || same as above, aber zusätzlich wieviel stören dann nachbar kanäle, etc. || markit
|-
| loco or nanobridge || G || || || klein vs. gross && keine schirmung vs. schüssel || markit
|-
| ''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''

[[category:CONFINE]]
a

0xFF-Backfire Vienna - Testtage 2011

2011-11-10T15:48:08Z

Aaron: add confine category

<div style="background: wheat; border: 1px solid #999; padding: 5px; margin-bottom: 5px;"><b>NOTE: english version is [[0xFF-Backfire_Vienna_-_Testtage_2011_(EN)|here]].<br>
Please edit the english version so that other community wireless networks in the world have a chance to read this page and to learn from us.</b>
</div>

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 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: =====
ORF- Zentrum Wien
Würzburggasse 30, A-1136 Wien, Raum: GPS 0.3
[https://docs.google.com/document/d/1CfhFuR6tCzhXjO_duchPk6NT8twNTmVGr4qTH5CbFl0/edit?hl=de Orientierungsplan]

Erreichbarkeit:

*U4 Station Hütteldorf. 58b bis Haltestelle ORF-Zentrum
*U6 Philadelphiabrücke - 8a bist Endstation ORF-Zentrum

===== Teilnehmer: =====
''Das Management der Teilnehmer wurde über [http://doodle.com/29yed3niczc3pr4d doodle.com] organisiert und kann [https://docs.google.com/document/d/1SAcgqe6KD5_1LYXHbaZLhFluc1OWB2z4JHRG_eFBcts/edit?hl=de hier] abgerufen werden.''

Eine Teilnahme an dieser Veranstaltung ist aus organisatorische Gründen nicht mehr möglich.

== Aufbau & Ablauf: ==

=== Agenda: ===

=====15.Oktober 2011=====
:10:00 - 11:00 Welcome & Socializing
:11:00 - 12:00 Agenda & MeetingPlanning
:12:00 - 13:00 Lunch
:13:00 - 18:00 Workshops 1st Part
:18:00 - 19:00 Dinner
:19:00 - 22:00 Workshops 2nd Part

=====16.Oktober 2011=====
:10:00 - 10:30 Welcome & Review
:10:30 - 13:00 Präsentation & Discussion (dokuSTREAM)
:13:00 - 14:00 Lunch
:14:00 - 16:30 Präsentation & Discussion (testSTREAM)
:16:30 - 17:00 Closing

:''Die Agenda könnt ihr als Dokument [https://docs.google.com/document/d/1-T_UctHH5WHSurRmP3XsxK8it6Y6PFibFpXF-iZWlyo/edit?hl=de hier] abrufen.''

=== Ablauf: ===

Zu Beginn der Veranstaltung werden wir die vorliegende draftAgenda festlegen, die vorbereiteten Arbetspakete vorstellen und gegebenenfalls anpassen oder ergänzen.

Aus den Anfragen der letzten Wochen haben wir folgende Arbeitspakete geschnürt:

=====dokuStream: Spezifikation & Dokumentation=====
:''Dabei wollen wir uns allen organisatorischen Themen rund um Backfire Vienna widmen. In diesem Stream ist geplant, unsere WIKI zu strukturieren, Fotos und Screenshots der Installation anzufertigen sowie die Inhalte der Basis-Config und der Erweiterungsparameter festzulegen.''

:''Im Detali sind das die Work-Pakages:''
:*[https://docs.google.com/document/d/1Hbi5SSIx267-ThmfizENZiPFSfNvXS0JaQlqF-45ddg/edit?hl=de Struktur der Backfire-WIKI & Basisinfos unserer Geräte ''(infoWIKI)'']
:*[https://docs.google.com/document/d/1VP--Rs5Icmt90STY1Taz6b4Ktv_Mu-lrdE8-weSPCfk/edit?hl=de Dokumentierte Installation von Backfire Vienna ''(installDOKU)'']
:*[https://docs.google.com/document/d/11Liv8sZjSpV1ux6UshVmzq1e2kOqxNsghzvLAs5THPg/edit?hl=de Packages & Defaults ''(devCONF)'']

=====testStream: Testing=====
:''Hier widmen wir uns allen technischen Themen rund um Backfire Vienna und den Geräten. Hier ist geplant, verbindliche Aussagen über Sendeleistungen, die Empfindlichkeit der Geräte, aber auch klare und nachweisbare Aussagen über Automatismen und Mythem zu erhalten.''

:''Im Detali sind das die Work-Pakages:''
:*[https://docs.google.com/document/d/1UzLbOA44IVVG27MNvOLiRjoAdQUvsw6i3Uvbp2Z2AQE/edit?hl=de HF-Parameter & deren Performance ''(testWIRELESS)'']
:*[https://docs.google.com/document/d/1lhDKxFuByJjZ_fnnj9pxMU0GPqIJiWqzEW-a4p_AkgE/edit?hl=de Mythbusting: ESSID & AdHoc ''(ESSID@AdHoc)'']
:*[https://docs.google.com/document/d/1p1SfNYFSDiOkplgLKbinx9yJLF6PGg6hAKmi--mxYd4/edit?hl=de Verfying AutoDeviceConfig Mode ''(LuCI-ADC)'']
:*[https://docs.google.com/document/d/1I9w62jJuowk6YrFhu0Li-Hde7sab2KekAseT-w4LerI/edit?hl=de MultiSSID-Mode ''(multiSSID)'']

Ich bitte euch, die einzelnen Pakete durchzusehen und euch für eines oder zwei entscheiden, wo ihr euch einbringen wollt.

== 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
|-
| Nanostation Loco M5 || Erich ? || ?
|-
| Nano Bridge M5 || Joe || markit
|-
| TL-1043ND || Martin A. || Runout (lagernd bei Alex S.)
|-
| TL-741ND || Joe || ?
|-
| TL-743ND || Runout || ?
|-
| R52 || Joe || markit
|-
| evt. R52N + boards || markit || markit
|-
| (evt.) Rocket + mimo antennen || markit || markit
|-
| WRT54GL || Martin A. || Erich
|-
| Buffalo WHR-HP-G54 || Thomas K. || Joe
|-
| wlan-usbsticks || ? || markit
|-
| Alix Boards mit R52hn || Aaron || Aaron
|-
| ''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
|-
| bridge or not || G || tp-link1043 || u.a.switches || mit vlans - bridge-hakerl am lan od. wan ? || Harald
|-
| ips lokal-global || G || tp-link1043 || u.a.switches || sind mit vlans am lokal port globale ips nötig || Harald
|-
| real world throughput single-hop || G || || || welche wlan treiber && settings sind auf identer funkstrecke/(und idealerweise hardware) wie nützlich || markit
|-
| real world throughput multi-hop || G || || || same as above, aber zusätzlich wieviel stören dann nachbar kanäle, etc. || markit
|-
| loco or nanobridge || G || || || klein vs. gross && keine schirmung vs. schüssel || markit
|-
| ''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]] >

[[category:CONFINE]]

0xFF-Backfire Vienna - Testtage 2011 (EN)

2011-10-14T22:11:37Z

Aaron: /* Testobjects: */

= 0xFF-Backfire Vienna - Testing days 2011 =

Our Funkfeuer networks in Vienna, Graz, Bad Ischl, Weinviertel and many small initiatives in Austria grew to a respectable size. For a long time these communities have been highly influenced by Sven-Ola and the Berlin Freifunk Firmware.

However, time did not stand still and due to the very good compact design of Ubiquity and the unbeatable price of TP-Link time has come to take a look at new products which mainly build upon the successful atheros chipset line.

The 0xFF-Backfire Vienna firmware managed to offer a reasonable snapshot of the most common used settings of the Vienna Funkfeuer network. In addition this firmware manages to fulfill most requirements of above mentioned atheros based devices.

Therefore, theses "testing days" also have the goal of improving the 0xFF-Backfire Vienna firmware images. Mistakes in configuration and settings shall be discovered and solved.

== Goals ==

=== Compatibility ===

When introducing a new software generation (0xFF-Backfire Vienna) it is crucial to maintain compatibility with existing devices and configurations
Therefore our first goal shall be to prove the compatibility of the new software with the existing devices (hard- and software compatibility tests). Tests will be done under lab-conditions (with professional testing equipment). Only after this test, we can claim the new software and hardware generation to be our new (Funkfeuer) "standard" setup.

=== Myths ===
Over the course of the last years in Funkfeuer, a couple of myths developed around devices and configuration settings. The goal of the tests thus shall be to eliminate these myths or to confirm them via rigorous tests.

=== Standard Configuration ===

Funkfeuer has a large and diverse set of devices in it's network. The support for these devices deteriorated over the last years. Goal of the "testing days" shall be to find a smaller set of confirmed working hardware devices + firmware + settings combination which is easy enough for newcomers. Later, when a newcomer gained experience, experiments will be available anyway.

=== Rating: ===

We also want to rate different combinations in order to give newcomers a basis for deciding which hardware they should buy.

== Organizational things ==

=== Date & Time ===
* Sat, 15.10.2011, 10:00 - 22:00
* Sun, 16.10.2011, 10:00 - 17:00

=== Location: ===
ORF- Zentrum Wien
Würzburggasse 30, A-1136 Wien, Raum: GPS 0.3
[https://docs.google.com/document/d/1CfhFuR6tCzhXjO_duchPk6NT8twNTmVGr4qTH5CbFl0/edit?hl=de Orientierungsplan]

Reachability:

*U4 Station Hütteldorf. 58b -> Stop ORF-Zentrum
*U6 Philadelphiabrücke - 8a -> Stop ORF-Zentrum

=== Participants ===

[https://docs.google.com/document/d/1SAcgqe6KD5_1LYXHbaZLhFluc1OWB2z4JHRG_eFBcts/edit?hl=de list of participants]

== Schedule ==
=== Agenda ===
lage
=====15th Oct 2011=====
:10:00 - 11:00 Welcome & Socializing
:11:00 - 12:00 Agenda & MeetingPlanning
:12:00 - 13:00 Lunch
:13:00 - 18:00 Workshops 1st Part
:18:00 - 19:00 Dinner
:19:00 - 22:00 Workshops 2nd Part

=====16th Oct 2011=====
:10:00 - 10:30 Welcome & Review
:10:30 - 13:00 Presentation & Discussion (dokuSTREAM)
:13:00 - 14:00 Lunch
:14:00 - 16:30 Presentation & Discussion (testSTREAM)
:16:30 - 17:00 Closing

Printable [https://docs.google.com/document/d/1-T_UctHH5WHSurRmP3XsxK8it6Y6PFibFpXF-iZWlyo/edit?hl=de agenda]

=====dokuStream: Specification & Documentation=====
:"we want to improve the WIKI, structure it, create pictures and screenshots of the installation and we want to define the base-setup of any 0xFF-Backfire Vienna setup"

:''Specifically we want to handle these Work-Packages:''
:*[https://docs.google.com/document/d/1Hbi5SSIx267-ThmfizENZiPFSfNvXS0JaQlqF-45ddg/edit?hl=de Structure of the Backfire Wiki and base-info ''(infoWIKI)'']
:*[https://docs.google.com/document/d/1VP--Rs5Icmt90STY1Taz6b4Ktv_Mu-lrdE8-weSPCfk/edit?hl=de documentation on the installation of Backfire Vienna ''(installDOKU)'']
:*[https://docs.google.com/document/d/11Liv8sZjSpV1ux6UshVmzq1e2kOqxNsghzvLAs5THPg/edit?hl=de Packages & Defaults ''(devCONF)'']

=====testStream: Testing=====

:"Here we will handle technical issues concerning the Backfire Vienna firmeware as well as technical issues of hardware. We intend to produce confirmed and repeatable statements concerning transmission power, sensitivity of devices. We also want to do some 'mythbusting'"

:''Specifically we want to handle these Work-Packages:''
:*[https://docs.google.com/document/d/1UzLbOA44IVVG27MNvOLiRjoAdQUvsw6i3Uvbp2Z2AQE/edit?hl=de HF-Parameters & their Performance ''(testWIRELESS)'']
:*[https://docs.google.com/document/d/1lhDKxFuByJjZ_fnnj9pxMU0GPqIJiWqzEW-a4p_AkgE/edit?hl=de Mythbusting: ESSID & AdHoc ''(ESSID@AdHoc)'']
:*[https://docs.google.com/document/d/1p1SfNYFSDiOkplgLKbinx9yJLF6PGg6hAKmi--mxYd4/edit?hl=de Verfying AutoDeviceConfig Mode ''(LuCI-ADC)'']
:*[https://docs.google.com/document/d/1I9w62jJuowk6YrFhu0Li-Hde7sab2KekAseT-w4LerI/edit?hl=de MultiSSID-Mode ''(multiSSID)'']

Please take a look at the individual packages and decide upfront where you want to participate.

== Testobjekte & Tests: ==

This section lists all devices and configutations and compatbility tests which will be measured in the 0xFF-Backfire Vienna testing days 2011.
(please add any that you want to have tested)

==== Testobjects: ====

{| 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
|-
| Nanostation Loco M5 || Erich ? || ?
|-
| Nano Bridge M5 || Joe || markit
|-
| TL-1043ND || Martin A. || Runout (currently at Alex S.)
|-
| TL-741ND || Joe || ?
|-
| TL-743ND || Runout || ?
|-
| R52 || Joe || markit
|-
| evt. R52N + boards || markit || markit
|-
| (maybe) Rocket + mimo antennas || markit || markit
|-
| WRT54GL || Martin A. || Erich
|-
| Buffalo WHR-HP-G54 || Thomas K. || Joe
|-
| wlan-usbsticks || ? || markit
|-
| Alix Boards mit R52hn || Aaron || Aaron
|-
| ''please add'' || ? || ?
|}
'' * in order to minimize individual errors of individual devices, please take two of each device''

==== Tests: ====

{| border="3" cellpadding="10" cellspacing="0"
! Testname* || Testtype** || Testobject*** || Testpartner**** || Description || Proposed by
|-
| TX power of the device || G || all || || Does the measured tx power match up with the txpower setting in the firmware? || Joe
|-
| Sensitivity of the device || G || all || reference device || Compare the sensitivities. Until when (which SNR limit) can we achieve good throughput (bits/sec rate)? (due to the testing method we will not be able to do tests for 802.11n in this case) || Joe
|-
| correctness of the SNR values || G || alle || reference device/ source || 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
|-
| bridge or not || G || tp-link1043 || u.a.switches || mit vlans - bridge-hakerl am lan od. wan ? || Harald
|-
| ips lokal-global || G || tp-link1043 || u.a.switches || sind mit vlans am lokal port globale ips nötig || Harald
|-
| real world throughput single-hop || G || || || welche wlan treiber && settings sind auf identer funkstrecke/(und idealerweise hardware) wie nützlich || markit
|-
| real world throughput multi-hop || G || || || same as above, aber zusätzlich wieviel stören dann nachbar kanäle, etc. || markit
|-
| loco or nanobridge || G || || || klein vs. gross && keine schirmung vs. schüssel || markit
|-
| ''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''

0xFF-Backfire Vienna - Testtage 2011 (EN)

2011-10-14T22:11:12Z

Aaron: /* Testobjects: */

= 0xFF-Backfire Vienna - Testing days 2011 =

Our Funkfeuer networks in Vienna, Graz, Bad Ischl, Weinviertel and many small initiatives in Austria grew to a respectable size. For a long time these communities have been highly influenced by Sven-Ola and the Berlin Freifunk Firmware.

However, time did not stand still and due to the very good compact design of Ubiquity and the unbeatable price of TP-Link time has come to take a look at new products which mainly build upon the successful atheros chipset line.

The 0xFF-Backfire Vienna firmware managed to offer a reasonable snapshot of the most common used settings of the Vienna Funkfeuer network. In addition this firmware manages to fulfill most requirements of above mentioned atheros based devices.

Therefore, theses "testing days" also have the goal of improving the 0xFF-Backfire Vienna firmware images. Mistakes in configuration and settings shall be discovered and solved.

== Goals ==

=== Compatibility ===

When introducing a new software generation (0xFF-Backfire Vienna) it is crucial to maintain compatibility with existing devices and configurations
Therefore our first goal shall be to prove the compatibility of the new software with the existing devices (hard- and software compatibility tests). Tests will be done under lab-conditions (with professional testing equipment). Only after this test, we can claim the new software and hardware generation to be our new (Funkfeuer) "standard" setup.

=== Myths ===
Over the course of the last years in Funkfeuer, a couple of myths developed around devices and configuration settings. The goal of the tests thus shall be to eliminate these myths or to confirm them via rigorous tests.

=== Standard Configuration ===

Funkfeuer has a large and diverse set of devices in it's network. The support for these devices deteriorated over the last years. Goal of the "testing days" shall be to find a smaller set of confirmed working hardware devices + firmware + settings combination which is easy enough for newcomers. Later, when a newcomer gained experience, experiments will be available anyway.

=== Rating: ===

We also want to rate different combinations in order to give newcomers a basis for deciding which hardware they should buy.

== Organizational things ==

=== Date & Time ===
* Sat, 15.10.2011, 10:00 - 22:00
* Sun, 16.10.2011, 10:00 - 17:00

=== Location: ===
ORF- Zentrum Wien
Würzburggasse 30, A-1136 Wien, Raum: GPS 0.3
[https://docs.google.com/document/d/1CfhFuR6tCzhXjO_duchPk6NT8twNTmVGr4qTH5CbFl0/edit?hl=de Orientierungsplan]

Reachability:

*U4 Station Hütteldorf. 58b -> Stop ORF-Zentrum
*U6 Philadelphiabrücke - 8a -> Stop ORF-Zentrum

=== Participants ===

[https://docs.google.com/document/d/1SAcgqe6KD5_1LYXHbaZLhFluc1OWB2z4JHRG_eFBcts/edit?hl=de list of participants]

== Schedule ==
=== Agenda ===
lage
=====15th Oct 2011=====
:10:00 - 11:00 Welcome & Socializing
:11:00 - 12:00 Agenda & MeetingPlanning
:12:00 - 13:00 Lunch
:13:00 - 18:00 Workshops 1st Part
:18:00 - 19:00 Dinner
:19:00 - 22:00 Workshops 2nd Part

=====16th Oct 2011=====
:10:00 - 10:30 Welcome & Review
:10:30 - 13:00 Presentation & Discussion (dokuSTREAM)
:13:00 - 14:00 Lunch
:14:00 - 16:30 Presentation & Discussion (testSTREAM)
:16:30 - 17:00 Closing

Printable [https://docs.google.com/document/d/1-T_UctHH5WHSurRmP3XsxK8it6Y6PFibFpXF-iZWlyo/edit?hl=de agenda]

=====dokuStream: Specification & Documentation=====
:"we want to improve the WIKI, structure it, create pictures and screenshots of the installation and we want to define the base-setup of any 0xFF-Backfire Vienna setup"

:''Specifically we want to handle these Work-Packages:''
:*[https://docs.google.com/document/d/1Hbi5SSIx267-ThmfizENZiPFSfNvXS0JaQlqF-45ddg/edit?hl=de Structure of the Backfire Wiki and base-info ''(infoWIKI)'']
:*[https://docs.google.com/document/d/1VP--Rs5Icmt90STY1Taz6b4Ktv_Mu-lrdE8-weSPCfk/edit?hl=de documentation on the installation of Backfire Vienna ''(installDOKU)'']
:*[https://docs.google.com/document/d/11Liv8sZjSpV1ux6UshVmzq1e2kOqxNsghzvLAs5THPg/edit?hl=de Packages & Defaults ''(devCONF)'']

=====testStream: Testing=====

:"Here we will handle technical issues concerning the Backfire Vienna firmeware as well as technical issues of hardware. We intend to produce confirmed and repeatable statements concerning transmission power, sensitivity of devices. We also want to do some 'mythbusting'"

:''Specifically we want to handle these Work-Packages:''
:*[https://docs.google.com/document/d/1UzLbOA44IVVG27MNvOLiRjoAdQUvsw6i3Uvbp2Z2AQE/edit?hl=de HF-Parameters & their Performance ''(testWIRELESS)'']
:*[https://docs.google.com/document/d/1lhDKxFuByJjZ_fnnj9pxMU0GPqIJiWqzEW-a4p_AkgE/edit?hl=de Mythbusting: ESSID & AdHoc ''(ESSID@AdHoc)'']
:*[https://docs.google.com/document/d/1p1SfNYFSDiOkplgLKbinx9yJLF6PGg6hAKmi--mxYd4/edit?hl=de Verfying AutoDeviceConfig Mode ''(LuCI-ADC)'']
:*[https://docs.google.com/document/d/1I9w62jJuowk6YrFhu0Li-Hde7sab2KekAseT-w4LerI/edit?hl=de MultiSSID-Mode ''(multiSSID)'']

Please take a look at the individual packages and decide upfront where you want to participate.

== Testobjekte & Tests: ==

This section lists all devices and configutations and compatbility tests which will be measured in the 0xFF-Backfire Vienna testing days 2011.
(please add any that you want to have tested)

==== Testobjects: ====

{| 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
|-
| Nanostation Loco M5 || Erich ? || ?
|-
| Nano Bridge M5 || Joe || markit
|-
| TL-1043ND || Martin A. || Runout (currently at Alex S.)
|-
| TL-741ND || Joe || ?
|-
| TL-743ND || Runout || ?
|-
| R52 || Joe || markit
|-
| evt. R52N + boards || markit || markit
|-
| (evt.) Rocket + mimo antennas || markit || markit
|-
| WRT54GL || Martin A. || Erich
|-
| Buffalo WHR-HP-G54 || Thomas K. || Joe
|-
| wlan-usbsticks || ? || markit
|-
| Alix Boards mit R52hn || Aaron || Aaron
|-
| ''please add'' || ? || ?
|}
'' * in order to minimize individual errors of individual devices, please take two of each device''

==== Tests: ====

{| border="3" cellpadding="10" cellspacing="0"
! Testname* || Testtype** || Testobject*** || Testpartner**** || Description || Proposed by
|-
| TX power of the device || G || all || || Does the measured tx power match up with the txpower setting in the firmware? || Joe
|-
| Sensitivity of the device || G || all || reference device || Compare the sensitivities. Until when (which SNR limit) can we achieve good throughput (bits/sec rate)? (due to the testing method we will not be able to do tests for 802.11n in this case) || Joe
|-
| correctness of the SNR values || G || alle || reference device/ source || 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
|-
| bridge or not || G || tp-link1043 || u.a.switches || mit vlans - bridge-hakerl am lan od. wan ? || Harald
|-
| ips lokal-global || G || tp-link1043 || u.a.switches || sind mit vlans am lokal port globale ips nötig || Harald
|-
| real world throughput single-hop || G || || || welche wlan treiber && settings sind auf identer funkstrecke/(und idealerweise hardware) wie nützlich || markit
|-
| real world throughput multi-hop || G || || || same as above, aber zusätzlich wieviel stören dann nachbar kanäle, etc. || markit
|-
| loco or nanobridge || G || || || klein vs. gross && keine schirmung vs. schüssel || markit
|-
| ''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''

0xFF-Backfire Vienna - Testtage 2011

2011-10-14T22:10:22Z

Aaron: /* Testobjekte: */

<div style="background: wheat; border: 1px solid #999; padding: 5px; margin-bottom: 5px;"><b>NOTE: english version is [[0xFF-Backfire_Vienna_-_Testtage_2011_(EN)|here]].<br>
Please edit the english version so that other community wireless networks in the world have a chance to read this page and to learn from us.</b>
</div>

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 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: =====
ORF- Zentrum Wien
Würzburggasse 30, A-1136 Wien, Raum: GPS 0.3
[https://docs.google.com/document/d/1CfhFuR6tCzhXjO_duchPk6NT8twNTmVGr4qTH5CbFl0/edit?hl=de Orientierungsplan]

Erreichbarkeit:

*U4 Station Hütteldorf. 58b bis Haltestelle ORF-Zentrum
*U6 Philadelphiabrücke - 8a bist Endstation ORF-Zentrum

===== Teilnehmer: =====
''Das Management der Teilnehmer wurde über [http://doodle.com/29yed3niczc3pr4d doodle.com] organisiert und kann [https://docs.google.com/document/d/1SAcgqe6KD5_1LYXHbaZLhFluc1OWB2z4JHRG_eFBcts/edit?hl=de hier] abgerufen werden.''

== Aufbau & Ablauf: ==

=== Agenda: ===

=====15.Oktober 2011=====
:10:00 - 11:00 Welcome & Socializing
:11:00 - 12:00 Agenda & MeetingPlanning
:12:00 - 13:00 Lunch
:13:00 - 18:00 Workshops 1st Part
:18:00 - 19:00 Dinner
:19:00 - 22:00 Workshops 2nd Part

=====16.Oktober 2011=====
:10:00 - 10:30 Welcome & Review
:10:30 - 13:00 Präsentation & Discussion (dokuSTREAM)
:13:00 - 14:00 Lunch
:14:00 - 16:30 Präsentation & Discussion (testSTREAM)
:16:30 - 17:00 Closing

:''Die Agenda könnt ihr als Dokument [https://docs.google.com/document/d/1-T_UctHH5WHSurRmP3XsxK8it6Y6PFibFpXF-iZWlyo/edit?hl=de hier] abrufen.''

=== Ablauf: ===

Zu Beginn der Veranstaltung werden wir die vorliegende draftAgenda festlegen, die vorbereiteten Arbetspakete vorstellen und gegebenenfalls anpassen oder ergänzen.

Aus den Anfragen der letzten Wochen haben wir folgende Arbeitspakete geschnürt:

=====dokuStream: Spezifikation & Dokumentation=====
:''Dabei wollen wir uns allen organisatorischen Themen rund um Backfire Vienna widmen. In diesem Stream ist geplant, unsere WIKI zu strukturieren, Fotos und Screenshots der Installation anzufertigen sowie die Inhalte der Basis-Config und der Erweiterungsparameter festzulegen.''

:''Im Detali sind das die Work-Pakages:''
:*[https://docs.google.com/document/d/1Hbi5SSIx267-ThmfizENZiPFSfNvXS0JaQlqF-45ddg/edit?hl=de Struktur der Backfire-WIKI & Basisinfos unserer Geräte ''(infoWIKI)'']
:*[https://docs.google.com/document/d/1VP--Rs5Icmt90STY1Taz6b4Ktv_Mu-lrdE8-weSPCfk/edit?hl=de Dokumentierte Installation von Backfire Vienna ''(installDOKU)'']
:*[https://docs.google.com/document/d/11Liv8sZjSpV1ux6UshVmzq1e2kOqxNsghzvLAs5THPg/edit?hl=de Packages & Defaults ''(devCONF)'']

=====testStream: Testing=====
:''Hier widmen wir uns allen technischen Themen rund um Backfire Vienna und den Geräten. Hier ist geplant, verbindliche Aussagen über Sendeleistungen, die Empfindlichkeit der Geräte, aber auch klare und nachweisbare Aussagen über Automatismen und Mythem zu erhalten.''

:''Im Detali sind das die Work-Pakages:''
:*[https://docs.google.com/document/d/1UzLbOA44IVVG27MNvOLiRjoAdQUvsw6i3Uvbp2Z2AQE/edit?hl=de HF-Parameter & deren Performance ''(testWIRELESS)'']
:*[https://docs.google.com/document/d/1lhDKxFuByJjZ_fnnj9pxMU0GPqIJiWqzEW-a4p_AkgE/edit?hl=de Mythbusting: ESSID & AdHoc ''(ESSID@AdHoc)'']
:*[https://docs.google.com/document/d/1p1SfNYFSDiOkplgLKbinx9yJLF6PGg6hAKmi--mxYd4/edit?hl=de Verfying AutoDeviceConfig Mode ''(LuCI-ADC)'']
:*[https://docs.google.com/document/d/1I9w62jJuowk6YrFhu0Li-Hde7sab2KekAseT-w4LerI/edit?hl=de MultiSSID-Mode ''(multiSSID)'']

Ich bitte euch, die einzelnen Pakete durchzusehen und euch für eines oder zwei entscheiden, wo ihr euch einbringen wollt.

== 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
|-
| Nanostation Loco M5 || Erich ? || ?
|-
| Nano Bridge M5 || Joe || markit
|-
| TL-1043ND || Martin A. || Runout (lagernd bei Alex S.)
|-
| TL-741ND || Joe || ?
|-
| TL-743ND || Runout || ?
|-
| R52 || Joe || markit
|-
| evt. R52N + boards || markit || markit
|-
| (evt.) Rocket + mimo antennen || markit || markit
|-
| WRT54GL || Martin A. || Erich
|-
| Buffalo WHR-HP-G54 || Thomas K. || Joe
|-
| wlan-usbsticks || ? || markit
|-
| Alix Boards mit R52hn || Aaron || Aaron
|-
| ''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
|-
| bridge or not || G || tp-link1043 || u.a.switches || mit vlans - bridge-hakerl am lan od. wan ? || Harald
|-
| ips lokal-global || G || tp-link1043 || u.a.switches || sind mit vlans am lokal port globale ips nötig || Harald
|-
| real world throughput single-hop || G || || || welche wlan treiber && settings sind auf identer funkstrecke/(und idealerweise hardware) wie nützlich || markit
|-
| real world throughput multi-hop || G || || || same as above, aber zusätzlich wieviel stören dann nachbar kanäle, etc. || markit
|-
| loco or nanobridge || G || || || klein vs. gross && keine schirmung vs. schüssel || markit
|-
| ''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-14T22:09:25Z

Aaron: add link to EN page

<div style="background: wheat; border: 1px solid #999; padding: 5px; margin-bottom: 5px;"><b>NOTE: english version is [[0xFF-Backfire_Vienna_-_Testtage_2011_(EN)|here]].<br>
Please edit the english version so that other community wireless networks in the world have a chance to read this page and to learn from us.</b>
</div>

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 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: =====
ORF- Zentrum Wien
Würzburggasse 30, A-1136 Wien, Raum: GPS 0.3
[https://docs.google.com/document/d/1CfhFuR6tCzhXjO_duchPk6NT8twNTmVGr4qTH5CbFl0/edit?hl=de Orientierungsplan]

Erreichbarkeit:

*U4 Station Hütteldorf. 58b bis Haltestelle ORF-Zentrum
*U6 Philadelphiabrücke - 8a bist Endstation ORF-Zentrum

===== Teilnehmer: =====
''Das Management der Teilnehmer wurde über [http://doodle.com/29yed3niczc3pr4d doodle.com] organisiert und kann [https://docs.google.com/document/d/1SAcgqe6KD5_1LYXHbaZLhFluc1OWB2z4JHRG_eFBcts/edit?hl=de hier] abgerufen werden.''

== Aufbau & Ablauf: ==

=== Agenda: ===

=====15.Oktober 2011=====
:10:00 - 11:00 Welcome & Socializing
:11:00 - 12:00 Agenda & MeetingPlanning
:12:00 - 13:00 Lunch
:13:00 - 18:00 Workshops 1st Part
:18:00 - 19:00 Dinner
:19:00 - 22:00 Workshops 2nd Part

=====16.Oktober 2011=====
:10:00 - 10:30 Welcome & Review
:10:30 - 13:00 Präsentation & Discussion (dokuSTREAM)
:13:00 - 14:00 Lunch
:14:00 - 16:30 Präsentation & Discussion (testSTREAM)
:16:30 - 17:00 Closing

:''Die Agenda könnt ihr als Dokument [https://docs.google.com/document/d/1-T_UctHH5WHSurRmP3XsxK8it6Y6PFibFpXF-iZWlyo/edit?hl=de hier] abrufen.''

=== Ablauf: ===

Zu Beginn der Veranstaltung werden wir die vorliegende draftAgenda festlegen, die vorbereiteten Arbetspakete vorstellen und gegebenenfalls anpassen oder ergänzen.

Aus den Anfragen der letzten Wochen haben wir folgende Arbeitspakete geschnürt:

=====dokuStream: Spezifikation & Dokumentation=====
:''Dabei wollen wir uns allen organisatorischen Themen rund um Backfire Vienna widmen. In diesem Stream ist geplant, unsere WIKI zu strukturieren, Fotos und Screenshots der Installation anzufertigen sowie die Inhalte der Basis-Config und der Erweiterungsparameter festzulegen.''

:''Im Detali sind das die Work-Pakages:''
:*[https://docs.google.com/document/d/1Hbi5SSIx267-ThmfizENZiPFSfNvXS0JaQlqF-45ddg/edit?hl=de Struktur der Backfire-WIKI & Basisinfos unserer Geräte ''(infoWIKI)'']
:*[https://docs.google.com/document/d/1VP--Rs5Icmt90STY1Taz6b4Ktv_Mu-lrdE8-weSPCfk/edit?hl=de Dokumentierte Installation von Backfire Vienna ''(installDOKU)'']
:*[https://docs.google.com/document/d/11Liv8sZjSpV1ux6UshVmzq1e2kOqxNsghzvLAs5THPg/edit?hl=de Packages & Defaults ''(devCONF)'']

=====testStream: Testing=====
:''Hier widmen wir uns allen technischen Themen rund um Backfire Vienna und den Geräten. Hier ist geplant, verbindliche Aussagen über Sendeleistungen, die Empfindlichkeit der Geräte, aber auch klare und nachweisbare Aussagen über Automatismen und Mythem zu erhalten.''

:''Im Detali sind das die Work-Pakages:''
:*[https://docs.google.com/document/d/1UzLbOA44IVVG27MNvOLiRjoAdQUvsw6i3Uvbp2Z2AQE/edit?hl=de HF-Parameter & deren Performance ''(testWIRELESS)'']
:*[https://docs.google.com/document/d/1lhDKxFuByJjZ_fnnj9pxMU0GPqIJiWqzEW-a4p_AkgE/edit?hl=de Mythbusting: ESSID & AdHoc ''(ESSID@AdHoc)'']
:*[https://docs.google.com/document/d/1p1SfNYFSDiOkplgLKbinx9yJLF6PGg6hAKmi--mxYd4/edit?hl=de Verfying AutoDeviceConfig Mode ''(LuCI-ADC)'']
:*[https://docs.google.com/document/d/1I9w62jJuowk6YrFhu0Li-Hde7sab2KekAseT-w4LerI/edit?hl=de MultiSSID-Mode ''(multiSSID)'']

Ich bitte euch, die einzelnen Pakete durchzusehen und euch für eines oder zwei entscheiden, wo ihr euch einbringen wollt.

== 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
|-
| Nanostation Loco M5 || Erich ? || ?
|-
| Nano Bridge M5 || Joe || markit
|-
| TL-1043ND || Martin A. || Runout (lagernd bei Alex S.)
|-
| TL-741ND || Joe || ?
|-
| TL-743ND || Runout || ?
|-
| R52 || Joe || markit
|-
| evt. R52N + boards || markit || markit
|-
| (evt.) Rocket + mimo antennen || markit || markit
|-
| WRT54GL || Martin A. || Erich
|-
| Buffalo WHR-HP-G54 || Thomas K. || Joe
|-
| wlan-usbsticks || ? || markit
|-
| ''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
|-
| bridge or not || G || tp-link1043 || u.a.switches || mit vlans - bridge-hakerl am lan od. wan ? || Harald
|-
| ips lokal-global || G || tp-link1043 || u.a.switches || sind mit vlans am lokal port globale ips nötig || Harald
|-
| real world throughput single-hop || G || || || welche wlan treiber && settings sind auf identer funkstrecke/(und idealerweise hardware) wie nützlich || markit
|-
| real world throughput multi-hop || G || || || same as above, aber zusätzlich wieviel stören dann nachbar kanäle, etc. || markit
|-
| loco or nanobridge || G || || || klein vs. gross && keine schirmung vs. schüssel || markit
|-
| ''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 (EN)

2011-10-14T17:56:27Z

Aaron: translate

= 0xFF-Backfire Vienna - Testing days 2011 =

Our Funkfeuer networks in Vienna, Graz, Bad Ischl, Weinviertel and many small initiatives in Austria grew to a respectable size. For a long time these communities have been highly influenced by Sven-Ola and the Berlin Freifunk Firmware.

However, time did not stand still and due to the very good compact design of Ubiquity and the unbeatable price of TP-Link time has come to take a look at new products which mainly build upon the successful atheros chipset line.

The 0xFF-Backfire Vienna firmware managed to offer a reasonable snapshot of the most common used settings of the Vienna Funkfeuer network. In addition this firmware manages to fulfill most requirements of above mentioned atheros based devices.

Therefore, theses "testing days" also have the goal of improving the 0xFF-Backfire Vienna firmware images. Mistakes in configuration and settings shall be discovered and solved.

== Goals ==

=== Compatibility ===

When introducing a new software generation (0xFF-Backfire Vienna) it is crucial to maintain compatibility with existing devices and configurations
Therefore our first goal shall be to prove the compatibility of the new software with the existing devices (hard- and software compatibility tests). Tests will be done under lab-conditions (with professional testing equipment). Only after this test, we can claim the new software and hardware generation to be our new (Funkfeuer) "standard" setup.

=== Myths ===
Over the course of the last years in Funkfeuer, a couple of myths developed around devices and configuration settings. The goal of the tests thus shall be to eliminate these myths or to confirm them via rigorous tests.

=== Standard Configuration ===

Funkfeuer has a large and diverse set of devices in it's network. The support for these devices deteriorated over the last years. Goal of the "testing days" shall be to find a smaller set of confirmed working hardware devices + firmware + settings combination which is easy enough for newcomers. Later, when a newcomer gained experience, experiments will be available anyway.

=== Rating: ===

We also want to rate different combinations in order to give newcomers a basis for deciding which hardware they should buy.

== Organizational things ==

=== Date & Time ===
* Sat, 15.10.2011, 10:00 - 22:00
* Sun, 16.10.2011, 10:00 - 17:00

=== Location: ===
ORF- Zentrum Wien
Würzburggasse 30, A-1136 Wien, Raum: GPS 0.3
[https://docs.google.com/document/d/1CfhFuR6tCzhXjO_duchPk6NT8twNTmVGr4qTH5CbFl0/edit?hl=de Orientierungsplan]

Reachability:

*U4 Station Hütteldorf. 58b -> Stop ORF-Zentrum
*U6 Philadelphiabrücke - 8a -> Stop ORF-Zentrum

=== Participants ===

[https://docs.google.com/document/d/1SAcgqe6KD5_1LYXHbaZLhFluc1OWB2z4JHRG_eFBcts/edit?hl=de list of participants]

== Schedule ==
=== Agenda ===
lage
=====15th Oct 2011=====
:10:00 - 11:00 Welcome & Socializing
:11:00 - 12:00 Agenda & MeetingPlanning
:12:00 - 13:00 Lunch
:13:00 - 18:00 Workshops 1st Part
:18:00 - 19:00 Dinner
:19:00 - 22:00 Workshops 2nd Part

=====16th Oct 2011=====
:10:00 - 10:30 Welcome & Review
:10:30 - 13:00 Presentation & Discussion (dokuSTREAM)
:13:00 - 14:00 Lunch
:14:00 - 16:30 Presentation & Discussion (testSTREAM)
:16:30 - 17:00 Closing

Printable [https://docs.google.com/document/d/1-T_UctHH5WHSurRmP3XsxK8it6Y6PFibFpXF-iZWlyo/edit?hl=de agenda]

=====dokuStream: Specification & Documentation=====
:"we want to improve the WIKI, structure it, create pictures and screenshots of the installation and we want to define the base-setup of any 0xFF-Backfire Vienna setup"

:''Specifically we want to handle these Work-Packages:''
:*[https://docs.google.com/document/d/1Hbi5SSIx267-ThmfizENZiPFSfNvXS0JaQlqF-45ddg/edit?hl=de Structure of the Backfire Wiki and base-info ''(infoWIKI)'']
:*[https://docs.google.com/document/d/1VP--Rs5Icmt90STY1Taz6b4Ktv_Mu-lrdE8-weSPCfk/edit?hl=de documentation on the installation of Backfire Vienna ''(installDOKU)'']
:*[https://docs.google.com/document/d/11Liv8sZjSpV1ux6UshVmzq1e2kOqxNsghzvLAs5THPg/edit?hl=de Packages & Defaults ''(devCONF)'']

=====testStream: Testing=====

:"Here we will handle technical issues concerning the Backfire Vienna firmeware as well as technical issues of hardware. We intend to produce confirmed and repeatable statements concerning transmission power, sensitivity of devices. We also want to do some 'mythbusting'"

:''Specifically we want to handle these Work-Packages:''
:*[https://docs.google.com/document/d/1UzLbOA44IVVG27MNvOLiRjoAdQUvsw6i3Uvbp2Z2AQE/edit?hl=de HF-Parameters & their Performance ''(testWIRELESS)'']
:*[https://docs.google.com/document/d/1lhDKxFuByJjZ_fnnj9pxMU0GPqIJiWqzEW-a4p_AkgE/edit?hl=de Mythbusting: ESSID & AdHoc ''(ESSID@AdHoc)'']
:*[https://docs.google.com/document/d/1p1SfNYFSDiOkplgLKbinx9yJLF6PGg6hAKmi--mxYd4/edit?hl=de Verfying AutoDeviceConfig Mode ''(LuCI-ADC)'']
:*[https://docs.google.com/document/d/1I9w62jJuowk6YrFhu0Li-Hde7sab2KekAseT-w4LerI/edit?hl=de MultiSSID-Mode ''(multiSSID)'']

Please take a look at the individual packages and decide upfront where you want to participate.

== Testobjekte & Tests: ==

This section lists all devices and configutations and compatbility tests which will be measured in the 0xFF-Backfire Vienna testing days 2011.
(please add any that you want to have tested)

==== Testobjects: ====

{| 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
|-
| Nanostation Loco M5 || Erich ? || ?
|-
| Nano Bridge M5 || Joe || markit
|-
| TL-1043ND || Martin A. || Runout (currently at Alex S.)
|-
| TL-741ND || Joe || ?
|-
| TL-743ND || Runout || ?
|-
| R52 || Joe || markit
|-
| evt. R52N + boards || markit || markit
|-
| (evt.) Rocket + mimo antennas || markit || markit
|-
| WRT54GL || Martin A. || Erich
|-
| Buffalo WHR-HP-G54 || Thomas K. || Joe
|-
| wlan-usbsticks || ? || markit
|-
| ''please add'' || ? || ?
|}
'' * in order to minimize individual errors of individual devices, please take two of each device''

==== Tests: ====

{| border="3" cellpadding="10" cellspacing="0"
! Testname* || Testtype** || Testobject*** || Testpartner**** || Description || Proposed by
|-
| TX power of the device || G || all || || Does the measured tx power match up with the txpower setting in the firmware? || Joe
|-
| Sensitivity of the device || G || all || reference device || Compare the sensitivities. Until when (which SNR limit) can we achieve good throughput (bits/sec rate)? (due to the testing method we will not be able to do tests for 802.11n in this case) || Joe
|-
| correctness of the SNR values || G || alle || reference device/ source || 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
|-
| bridge or not || G || tp-link1043 || u.a.switches || mit vlans - bridge-hakerl am lan od. wan ? || Harald
|-
| ips lokal-global || G || tp-link1043 || u.a.switches || sind mit vlans am lokal port globale ips nötig || Harald
|-
| real world throughput single-hop || G || || || welche wlan treiber && settings sind auf identer funkstrecke/(und idealerweise hardware) wie nützlich || markit
|-
| real world throughput multi-hop || G || || || same as above, aber zusätzlich wieviel stören dann nachbar kanäle, etc. || markit
|-
| loco or nanobridge || G || || || klein vs. gross && keine schirmung vs. schüssel || markit
|-
| ''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''

0xFF-Backfire Vienna - Testtage 2011

2011-09-04T13:27:20Z

Aaron: nehme teil, minor typos korrigiert

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

== 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 || Joe
|-
| Bullet5 || ? || ?
|-
| Bullet M2 || ? || ?
|-
| Bullet M5 || Joe || ?
|-
| AirGrid M2 || Joe || ?
|-
| AirGrid M5 || ? || ?
|-
| TL-1043ND || ? || ?
|-
| TL-741ND || Joe || ?
|-
| R52 || Joe || Joe
|-
| ''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
|-
| Sendeleistung der Geräte || G || alle || || Entsprechen die Leistungsangaben in der Firmware der Realität?
|-
| 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?''
|-
| 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
|-
| 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),...
|-
| Zuverlässigkeit des Auto-Modes bei der Frequenzwahl || K || ausgewählte Geräte || Gerät mit fixer Kanalzuteilung ||
|-
| ''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''

Erste Schritte

2011-07-27T12:04:29Z

Aaron: map link war veraltet

<google>WIKI</google>

==Über dieses Howto==
Hier werden die ersten Schritte erklärt, die getätigt werden müssen, um einen Anschluss an das FunkFeuer-Netz zu bekommen. Wir wissen, das ist eine trockene Materie, und wir versuchen laufend, sie besser und lebendiger darzustellen. Aber da musst Du durch, wenn Du teilnehmen willst.

Wenn Du die Schritte einmal richtig abgearbeitet hast, ist es erledigt.

Du brauchst:
* einen Internetzugang (zur Not reicht auch ein Internet/Surf-Shop) z.B. zum Wiki lesen
* einen WLAN Router (siehe "[[#Die_Mittel|Die Mittel]]" weiter unten)
* einige Stunden Zeit, um Dich in die Materie einzuarbeiten

Du solltest auch auf unsere [[Montagstreff]]s kommen. Wir verstehen uns als [http://de.wikipedia.org/wiki/Community_of_Practice Community of Practice], als praxisbezogene Arbeitsgemeinschaft. Wir betreiben das freie Bürgernetz und wollen es weiter ausbauen. Es ist ein gemeinnütziges Projekt, ein solidarisches Geben und Nehmen, und man trifft interessante Leute.

==Das Ziel==
Teilnahme an unserem freien und frei zugänglichen Bürgernetz, einem Bürger-[[WLAN]].

==Die Mittel==
Ein handelsüblicher Router, auf dem das '''O'''ptimized '''L'''ink '''S'''tate '''R'''outing (OLSR) Protocol aufgespielt wird. Das [http://de.wikipedia.org/wiki/OLSR OLSR] ist ein proaktives Routing Protokoll für mobile ad hoc Netzwerke. Beachte bitte das Wörtchen "proaktiv": es bedeutet, dass das Protokoll weitgehend selbstregulierend ist, also keiner oder fast keiner Intervention des Anwenders bedarf. Du mußt nicht Routing-Protokolle studieren, um einen Node betreiben zu können. Eine Einführung zu OLSR ist [http://www.olsr.org/index.cgi?action=doc auf olsr.org] (auf Englisch) zu finden. Das Besondere daran: ein Wireless Router wird üblicherweise an ein DSL- oder Kabelmodem angeschlossen und versorgt dann über Funk die PCs, Laptops, Drucker und anderen Geräte im Büro oder zu Hause. Hier ist es umgekehrt. Das Internet kommt über Funkwellen herein und wir schließen unsere Geräte per Kabel an den Router an. Natürlich kann man an den FunkFeuer Wireless Router einen weiteren Router, wenn gewünscht auch einen Wireless Router, für den privaten Gebrauch anschließen.

==Der Weg==
Zuerst muss einmal festgestellt werden, ob dort, wo Du Deinen Knoten errichten willst, Das FunkFeuer Netzwerk in ausreichender Signalqualität und -stärke vorhanden ist. Unser Netz wächst ständig und auf unserer [http://map.funkfeuer.at/ Karte] bekommst Du einen Überblick, wo bereits Knoten installiert sind und wo bald welche dazukommen werden bzw. welche aktuell nicht erreichbar sind.

Zuverlässig lässt sich aber nur durch eine Messung vor Ort, also am Ort des geplanten Einsatzes, feststellen, ob Signalqualität und -stärke ausreichen, um einen Knoten zu betreiben. Dazu solltest Du Dir von uns gegen eine Kaution von € 50,-- eine Messantenne samt PCMCIA WLAN Karte ausborgen. Lade Dir das Programm [http://www.netstumbler.com/downloads/netstumblerinstaller_0_4_0.exe Net Stumbler] herunter (alternativer Download bei [http://www.softpedia.com/progDownload/NetStumbler-Download-17714.html Softepedia]). Das ist ein Programm, mit dem Du Wireless Local Area Networks ([[WLAN]]s) der Standards 802.11a, 802.11b und 802.11g entdecken und ihre Signalstärke messen kannst. Installiere es auf Deinem Laptop, der vorzugsweise unter Windows XP laufen sollte. Wenn Windows 2000 installiert ist, brauchst Du einen speziellen WLAN-PCMCIA Karten-Treiber, den Du [http://www.proxim.com/support/all/orinoco/software/dl2002-oricli-win-sr-02.html hier] bekommst. Dann solltest Du den höchsten Dir zugänglichen Punkt für den geplanten Standort aufsuchen. Dies ist in den meisten Fällen der Dachboden. Wir wissen aus Erfahrungsberichten unserer Mitglieder, dass der Zugang nicht immer leicht möglich ist. Doch ist es wichtig, dass Du vom höchstmöglichen Punkt aus misst, denn das FunkFeuer Netz muss man sich wie eine Wolke über den Dächern der Stadt vorstellen. Nun steckst Du die PCMCIA - Karte in den Laptop und startest Netstumbler.

Vielleicht wirst Du nicht so viele WLANs sehen wie auf diesem Screenshot rechts. Natürlich sollte in der Mitte unten nicht "No wireless adapter found" stehen, sondern Deine WLAN-Karte angegeben sein. Bewege Dich mit dem Laptop und der Messantenne in alle Himmelsrichtungen und drehe die Antenne langsam von allen möglichen Standorten. Nimm Dir Zeit dafür und suche sorgfältig die ganze Umgebung ab. Auf dem Screenshot sind unsere Channels gelb hervorgehoben.

Rechts ist ein altes Netstumblerbild = alte 0xff ssid = wurden geändert [[Kanalwahl]]
[[Bild:Netstumbler1a 01.gif|thumb]]

Klicke nun in Netstumbler auf "SSIDs" und öffne die einzelnen [http://de.wikipedia.org/wiki/SSID SSIDs] von www.funkfeuer.at durch klicken auf das + Zeichen. Für den oder die ...freiesnetz.www.funkfeuer.at SSIDs gibt es wieder ein Unterverzeichnis mit [http://de.wikipedia.org/wiki/MAC-Adresse MAC-Adresse(n)] (die sogenannte physikalische Adresse der Netzwerkkarte) der Knoten, die mit dieser SSID senden. Bei uns haben ALLE Knoten auf Kanal 1 freiesnetz.www.funkfeuer.at die Adresse 4EFE52362E65. <br>
ALLE FunkFeuer-Knoten auf Kanal 1 sollten mit dieser Adresse senden.

Siehe auch [[Kanalwahl]] unter bssid.

Klicke da drauf und eine Grafik erscheint, in der die "[http://de.wikipedia.org/wiki/SNR Signal to Noise Ratio]" auf der senkrechten Achse dargestellt ist. Auf der waagrechten Achse siehst Du Datum und Uhrzeit. Bewege Dich langsam und ausgiebig mit der Antenne, um die Position für die beste Signal to Noise Ratio zu finden. Das Wichtige sind die grünen Säulen. Desto höher sie bei hier gleichem "Noise" (das sind die roten Säulen) sind, desto besser die Empfangssignalqualität. Die SNR sollte mindestens 10 dB betragen.

Interessanter ist auf jeden Fall die SSID '''....freiesnetz.www.funkfeuer.at''', meist auf Kanal 1, siehe auch [[Kanalwahl]], da dies die meist verwendete SSID im FunkFeuer Netz ist. Auch die v4.freiesnetz.www.funkfeuer.at, v10… und v13… sind möglich. Knoten mit diesen SSID's senden vertikal [http://de.wikipedia.org/wiki/Polarisation polarisiert]. Nur die Knoten mit der SSID h13… senden horizontal [http://de.wikipedia.org/wiki/Polarisation polarisiert].

Wenn du wissen möchtest, wo Knoten liegen, kannst du mal auf [http://map.funkfeuer.at/dev diese Karte] schauen.

[[Bild:Netstumbler2.gif|thumb]]

Berichte von Deinen Messergebnissen am [[Montagstreffen]] und/oder in der [https://lists.funkfeuer.at/mailman/listinfo/interesse "Wien" - Mailingliste]. Das Archiv aller Mailinglisten findest Du [https://lists.funkfeuer.at/pipermail hier].

Wenn nun die Messung zufriedenstellend ausgefallen ist, hast Du die wichtigste Hürde für die Teilnahme am FunkFeuer-Netz bereits geschafft! Kauf Dir einen Linksys WRT54GL Wireless-G Broadband Router. Hier ist ein [http://geizhals.at/?a=172494&t=alle&plz=&v=e&filter_submit=Angebote+filtern Link zu geizhals.at].

Oder einen anderen tauglichen, flashbaren Router ([[Hardware|802.11b/g 2,4 GHz Hardware]])

[[Bild:WRT54G 01.jpg|thumb]]

Als nächstes solltest Du, der Betriebsanleitung folgend, den Router an den PC oder Laptop anschließen.
CD braucht man nicht einlegen, da der Router ohnehin mit einer neuen Firmware geflasht ("=programmiert") werden muss.

Neben dem oben genannten Programm Network Stumbler existieren noch zahlreiche andere Programme, welche die selbe Aufgabe erledigen: die Suche nach WLAN-Netzwerken. Unter [[WlanScanTools]] werden einige dieser Tools aufgelistet - auch für andere Betriebssysteme.

==Das Frontend==
Wenn Du die Messantenne zurückbringst, können wir mit Dir über die Messergebnisse sprechen und Dich in unserem [http://www.funkfeuer.at/Frontend.159.0.html Frontend] als neuen Teilnehmer aufsetzen. Dort loggst Du Dich dann ein und überprüfst zuerst einmal die Richtigkeit der [[Frontend_Mitglied|Angaben]], wie [[Frontend_Mitglied#.2A_Nachname|Name]], [[Frontend_Mitglied#.2A_Stra.C3.9Fe|Adresse]], [[Frontend_Mitglied#.2A_E-Mail|E-Mailadresse]], usw. und vervollständigst sie.

== Neuen Funkfeuer Knoten anlegen ==

Die hier beschriebene Methode funktioniert aufgrund datenschutzrechtlicher Überlegungen nur mit Rechnern, die bereits im FunkFeuer-Netz sind.

Um einen neuen Knoten anzulegen, einfach in der [http://www.funkfeuer.at/Karte.118.0.html Karte] auf die Position des neuen Knotens klicken. Im sich öffnenden Fenster auf "Neuen Node registrieren…" klicken. Bei Bedarf ändert sich nun der Zoomlevel der Karte und Du musst erneut auf die nun exakter bestimmbare Position klicken und wieder mit einem Klick auf "Neuen Node registrieren…" bestätigen. Es öffnet sich ein weiteres Fenster, in dem Dein [[Frontend_Mitglied#.2A_Nickname|Nickname]], [[Frontend_Mitglied#.2A_Passwort|Passwort]] und der gewünschte [[Frontend_Node#Name|Namen]] des Knotens einzutragen ist. Mit einem Klick auf "Registrieren" wird das Anlegen des Knoten abgeschlossen und der Knoten samt GPS-Koordinaten in der FunkFeuer-Datenbank gespeichert.

Im [http://www.funkfeuer.at/Frontend.159.0.html Frontend] unter [[Frontend_Nodes|"Nodes"]] siehst Du Deinen Knoten.

Als nächstes legst Du ein [[Frontend_Devices|"Device"]], also Deinen Router im Frontend an.
Dazu musst Du im [http://www.funkfeuer.at/Frontend.159.0.html Frontend] unter [[Frontend_Nodes|"Nodes"]] in der Zeile deines Knoten auf "SHOW" und im sich öffnenden Fenster auf "hinzufügen" klicken.

Gebe bitte folgende Werte ein:
* Name: Die ersten zwei oder drei Buchstaben Deines Straßennamens, gefolgt von der Hausnummer, + "v1": Bsp: mue3v1 also [http://de.wikipedia.org/wiki/Polarisation vertikal] und Kanal 1
* MAC: MAC-Adresse deiner Linksys-Box (siehe Sticker auf der Unterseite)
* Antenne: Omni, Parabol, Gitter, Biquad, Panel, usw.
* Hardware: Die Version deines Routers (siehe Sticker auf der Linksys) oder [http://styx.commando.de/sven-ola/ipkg/_g/readme.txt alternativer FreiFunk-tauglicher Hardware]
* SSID: zb. freiesnetz_www.funkfeuer.at / v4.freiesnetz.www.funkfeuer.at ...
* [[FAQ#Was_ist_dieses_Smokeping-Ding.3F|Smokeping]]: ja

Nachdem Du "Absenden" geklickt hast, kannst Du die Dir soeben zugewiesene offizielle IP unter [[Frontend_Nodes|"Nodes"]] -> "SHOW" einsehen. Diese IP wird später (meist) im Router unter "Drahtlos" eingetragen.

==Computer mit Router verbinden==

[[Bild:Pinghack.gif|thumb]]
Verbinde Deinen PC oder Laptop mit dem Router, wie in der Anleitung des Routers beschrieben.

Als nächstes wirst Du eine neue Firmware in den Router eingespielen. Dies wird auf [[Linksys_flashen_mit_OpenWRT,_Freifunk-Firmware_und_retour#Letzte_.C3.9Cbung:_Freifunk-Firmware_einspielen|Linksys flashen]] und auf [[Freifunk_Firmware#Standard_Konfiguration|Freifunk Firmware für FunkFeuer konfigurieren]] beschrieben.

erster DNS Server: '''193.238.157.16'''
zweiter DNS Server: '''193.238.157.5'''

Öffne den Browser und geh auf [http://www.funkfeuer.at www.funkfeuer.at]

'''Willkommen im FunkFeuer Netzwerk!'''

Sollte die Signalstärke am geplanten Einsatzort (der Wohnung) nicht ausreichen, dann musst Du, am besten am Dach, eine Antenne installieren. Da der Abstand vom Router zur Antenne möglichst gering sein soll, muss auch eine Stromversorgung eingerichtet werden.

==Bei Troubles==
Sollten Probleme beim flashen aufgetreten sein, findest du im [[Troubleshooting]]-Bereich Infos.

[[Category:Dokumentation]]

Hotspot

2011-07-05T09:00:25Z

Aaron:

== ACHTUNG ==

<div style="background: red; border: 1px solid #999; padding: 5px; margin-bottom: 5px;">'''ACHTUNG: Dieser Text ist veraltet! Es gibt kaum noch Hotspots, die so funktionieren!</div>

==Idee==
Internetzugang für Reisende mittels FunkFeuer WLAN Zugriffspunkten (aka Hotspot)
==Problem==
Unsichere Rechtslage bezüglich der Haftung von offenen (d.h. nicht zugriffsbeschränkten) Internet Zugängen von Privatpersonen

==Lösung==
Die Nutzer müssen sich authentifizieren

===Authentifizierung mittels CAcert.org Web of Trust===
====Prinzip====
FunkFeuer vertraut dem CAcert.org [http://de.wikipedia.org/wiki/Web_of_trust Web of Trust] und authentifiziert anhand eines CAcert.org Client Zertifikates. Identitätsmerkmale bei CAcert.org sind Vorname, Nachname, Geburtsdatum und eine E-Mail Adresse.

====Wie kommt man zu einem passenden Zertifikat====
Nachdem man sich bei [http://www.cacert.org CAcert.org] registriert hat und
anschließend von mindestens zwei CAcert Assurern amtliche Lichtbildausweise kontrollieren ließ, kann man auf CAcert.org ein Client Zertifikat mit dem eigenen Namen erstellen.
=====Schritt für Schritt=====
# Auf [http://www.cacert.org/index.php?id=1&lang=de_DE CAcert.org] mit Vorname, Name, Geburtsdatum und E-Mail Adresse registrieren
# CAcert schickt an die angegebene E-Mail Adresse eine Nachricht mit einem Link. Dieser Link muss angeklickt werden, um die E-Mail Adresse zu verifizieren
# auf [https://www.cacert.org/index.php?id=4 CAcert] mit E-Mail Adresse und Passwort anmelden
# Du, also dein Name und dein Geburtsdatum, musst noch von CAcert.org Prüfern (aka "Assurer") auf Richtigkeit überprüft werden. Dazu musst du Prüfer treffen. Die findest du z.B. während des [http://funkfeuer.at/Montagstreffen.102.0.html Montagtreffs] oder via CAcert: "CAcert Vertrauensnetzwerk" -> "Finde einen Prüfer" klicken und mit mindestens zwei Prüfern Kontakt aufnehmen, z.B. per E-Mail:
Lieber CAcert.org Assurer
würdest du mich für CAcert assuren?
Wo könnte ich dich treffen?
Liebe Grüße
# unter "+ CAP/TTP Formulare" das "A4 - WoT - Formular" ausdrucken und gemeinsam mit (am Besten zwei) Lichtbildausweisen die CAcert Prüfer treffen. Diese vergeben Punkte (zwischen 10 und 35)
# Ab 50 Punkten unter "Client Certificates" -> "new" ein Klient Zertifikat (inklusive Name) erstellen und im soeben verwendeten Browser installieren
# Ein Root Zertifikat unter "[http://www.cacert.org/index.php?id=3 Root Certificate]" installieren

==Surfen via FunkFeuer Hotspot==
===Registrieren bei FunkFeuer===
die aktuelle FunkFeuer Lösung setzt zusätzlich zur Authentifizierung noch einen Loginvorgang mit E-Mailadresse als Benutzername und einem Passwort voraus. Dieses Passwort wird automatisch generiert und sofort nach dem Klick auf "Registrierung" angezeigt.

Sollte die [https://marvin.funkfeuer.at/hotspot/images/register_cacert_missingcert.jpg Fehlermeldung] "marvin.funkfeuer.at hat eine falsche oder unerwartete Nachricht erhalten. Fehler-Code: -12227" angezeigt werden, fehlt vermutlich das Root oder das Client Zertifikat

===Login===
* Benutzername: E-Mail Adresse aus dem CAcert.org Client Zertifikat
* Passwort: wird bei der Registrierung angezeigt und per E-Mail versendet

Hotspot

2011-07-05T08:59:09Z

Aaron: veraltet

== ACHTUNG ==

Dieser Text ist veraltet! Es gibt kaum noch Hotspots, die so funktionieren!

==Idee==
Internetzugang für Reisende mittels FunkFeuer WLAN Zugriffspunkten (aka Hotspot)
==Problem==
Unsichere Rechtslage bezüglich der Haftung von offenen (d.h. nicht zugriffsbeschränkten) Internet Zugängen von Privatpersonen

==Lösung==
Die Nutzer müssen sich authentifizieren

===Authentifizierung mittels CAcert.org Web of Trust===
====Prinzip====
FunkFeuer vertraut dem CAcert.org [http://de.wikipedia.org/wiki/Web_of_trust Web of Trust] und authentifiziert anhand eines CAcert.org Client Zertifikates. Identitätsmerkmale bei CAcert.org sind Vorname, Nachname, Geburtsdatum und eine E-Mail Adresse.

====Wie kommt man zu einem passenden Zertifikat====
Nachdem man sich bei [http://www.cacert.org CAcert.org] registriert hat und
anschließend von mindestens zwei CAcert Assurern amtliche Lichtbildausweise kontrollieren ließ, kann man auf CAcert.org ein Client Zertifikat mit dem eigenen Namen erstellen.
=====Schritt für Schritt=====
# Auf [http://www.cacert.org/index.php?id=1&lang=de_DE CAcert.org] mit Vorname, Name, Geburtsdatum und E-Mail Adresse registrieren
# CAcert schickt an die angegebene E-Mail Adresse eine Nachricht mit einem Link. Dieser Link muss angeklickt werden, um die E-Mail Adresse zu verifizieren
# auf [https://www.cacert.org/index.php?id=4 CAcert] mit E-Mail Adresse und Passwort anmelden
# Du, also dein Name und dein Geburtsdatum, musst noch von CAcert.org Prüfern (aka "Assurer") auf Richtigkeit überprüft werden. Dazu musst du Prüfer treffen. Die findest du z.B. während des [http://funkfeuer.at/Montagstreffen.102.0.html Montagtreffs] oder via CAcert: "CAcert Vertrauensnetzwerk" -> "Finde einen Prüfer" klicken und mit mindestens zwei Prüfern Kontakt aufnehmen, z.B. per E-Mail:
Lieber CAcert.org Assurer
würdest du mich für CAcert assuren?
Wo könnte ich dich treffen?
Liebe Grüße
# unter "+ CAP/TTP Formulare" das "A4 - WoT - Formular" ausdrucken und gemeinsam mit (am Besten zwei) Lichtbildausweisen die CAcert Prüfer treffen. Diese vergeben Punkte (zwischen 10 und 35)
# Ab 50 Punkten unter "Client Certificates" -> "new" ein Klient Zertifikat (inklusive Name) erstellen und im soeben verwendeten Browser installieren
# Ein Root Zertifikat unter "[http://www.cacert.org/index.php?id=3 Root Certificate]" installieren

==Surfen via FunkFeuer Hotspot==
===Registrieren bei FunkFeuer===
die aktuelle FunkFeuer Lösung setzt zusätzlich zur Authentifizierung noch einen Loginvorgang mit E-Mailadresse als Benutzername und einem Passwort voraus. Dieses Passwort wird automatisch generiert und sofort nach dem Klick auf "Registrierung" angezeigt.

Sollte die [https://marvin.funkfeuer.at/hotspot/images/register_cacert_missingcert.jpg Fehlermeldung] "marvin.funkfeuer.at hat eine falsche oder unerwartete Nachricht erhalten. Fehler-Code: -12227" angezeigt werden, fehlt vermutlich das Root oder das Client Zertifikat

===Login===
* Benutzername: E-Mail Adresse aus dem CAcert.org Client Zertifikat
* Passwort: wird bei der Registrierung angezeigt und per E-Mail versendet

MobileNodes

2011-04-11T19:09:37Z

Aaron: achtung

[http://forum.funkfeuer.at/viewtopic.php?id=35 Hier] befindet sich ein guter Artikel über die Sinnhaftigkeit von Notebook-Usern im FunkFeuer Netz.

= ACHTUNG =

'''Achtung, dieser Artikel verweist auf veraltete Versionen von OLSR. Funkfeuer kann den Einsatz von mobilen Nodes derzeit nicht empfehlen.
Siehe auch: http://forum.funkfeuer.at/viewtopic.php?id=35'''
= windows =

# aktuelle olsr-setup.exe von http://www.olsr.org besorgen und starten -> installiert "olsr switch"
# [http://de.wikipedia.org/wiki/IP-Adresse IP Adresse] am [[Montagstreff]] abholen und am Laptop einstellen
#* Start -> Systemsteuerung -> Netzwerkverbindungen -> drahtlose Netwerkverbindung -> Eigenschaften
#* im Reiter "Algemein" bei "Diese Verbindung verwendet ..." Internetprotokoll (Tcp/Ip) auswähleun und anschließend auf Eigenschaften klicken
#* zumindest IP-Adresse, Subnetmaske, Standardgateway und eine DNS Serveradresse eintragen
# den Laptop auf das gewünschte WLAN einstellen (freiesnetz.www.funkfeuer.at, Kanal 1, ad-hoc mode = Computer zu Computer Netzwerk, kein WEP)
# erst wenn die WLAN Verbindung steht! "olsr switch" starten und folgendes konfigurieren:
#* "Enable hysterese" nicht anhaken
## "Enable ETX" anhaken
## "offer internet connection" ganz sicher nicht anhaken (!!)
## in der "Interface list" nur die oben eingestellte WLAN IP anhaken
# mit dem "Start" Button den olsrd starten
# in der "Node list" des Reiters "Nodes" sollten erste IP-Adressen von FunkFeuer Knoten erscheinen
# spätestens nach einer Minute sollten Routen in der "Routing Table" des Reiters "Routes" erscheinen

== Screenshots für den olsrd-0.4.10 ==

=== Einstellungen ===
Die Einstellungen sollten so ausschauen. Nicht vom Fenstertitel verwirren lassen - die falsche Versionsnummer dort ist ein Known Bug.
[[Bild:Olsrd-0.4.10-settings.jpg|thumb|none|Screenshot settings]]
=== Log-Ausgaben ===
Wenn man den olsrd gestartet hat, schreibt er ein paar Zeilen ins 2. Tab.
[[Bild:Olsrd-0.4.10-output.JPG|thumb|none|Screenshot log]]
=== Knoten ===

Alle erreichbaren Knoten.

[[Bild:Olsrd-0.4.10-nodes.JPG|thumb|none|Nodes]]

=== Routen ===

Alle olsrd-verwalteten Routen. Für jede IP-Adresse in olsr-Netz gibt es einen Eintrag, d.h. man sollte -zig Zeilen haben.

[[Bild:Olsrd-0.4.10-routes.JPG|thumb|none|Routes]]

OLSR-NG

2011-02-12T20:26:01Z

Aaron: re-wording to make henning happy

<google>OLSR</google>

<div style="background: red; border: 1px solid #999; padding: 5px; margin-bottom: 5px;">'''WARNING: This page is very outdated by now! It purely serves to document the Netidee project of ~2007'''<br>Please go to ''' http://www.olsr.org ''' for more current and up to date info. This is here for historical reasons.</div>

= Goals =

Our mission is simple. Build the most scalable and usable routing daemon routing wireless and fixed line segments.
The routing daemon shall scale up to

# 10000 (10K) nodes and
# 20000 (20K) routes
running on low-cost hardware (200 Mhz RISC CPUs / 32MB of memory).

One of the main goals is to make OLSR more scalable '''in practice'''.
[[Bild:O-Dijkstra.gif|350px|right|Complexity for n=1000 nodes of different data structures in the Dijkstra shortest path (SPF) algorithm. ]]

In the this picture you can see the different complexity graphs for the SPF under the assumption that every node has 10 edges . As you can see, the red line has O(n^2) complexity. This conformed to the implementation of OLSR from www.olsr.org ('''before''' the OLSR-NG project). OLSR-NG reduced the complexity to the green level. This will allow the mesh network clouds to become larger by a factor ~ 1000 (on the level of calculating the dijkstra (shortes path) algorithm so far).

For achieving that we first want to

# fix the existing olsrd and add new data structures and algorithms.
# Once olsrd is running fast we focus on protocol issues like
## measuring better links metrics, like including the bandwidth (ETT)
## link-state db synchronization issues (rather then brute force retransmission).
All protocol extensions shall be documented as an internet-draft and submitted to the IETF MANET working group http://www.ietf.org/html.charters/manet-charter.html

Next we want to improve the management tools of olsrd like the

# http_info plugin or
# txt_info plugins or
# building a new XMLinfo plugin

such that that large clouds consisting of thousands of nodes
can be troubleshooted in an effective way.

Main OLSR-NG project blog: http://olsr.funkfeuer.at
Slides from the OLSR-NG kickoff presentation: http://marvin.funkfeuer.at/~aaron/olsr-ng.pdf

= Current Status =

=== stable ===
* olsrd 0.5.5 was released! Thx everybody a lot! - See changes int the [http://sourceforge.net/project/shownotes.php?release_id=574533&group_id=117612 Changelog]

=== upcoming 0.5.6 ===

'''buglist:''' Things that ''need'' to be changed before we release 0.5.6

<pre>
sven-ola: stimmt. glaub' ich auch. Da sind noch 2 Bugs drin.
[12:19pm] sven-ola: oder sogar drei. Das sind aus meiner Sicht:
[12:20pm] sven-ola: 1) das nach neustart unter http://localhost:2006/links derselbe Node mehrfach auftaucht
[12:20pm] sven-ola: 2) das etx_ff mit olsr-0.5.5 (oder etx_fpm) nur bis LQ=0.6 kommt
[12:20pm] sven-ola: 3) unter windoof: mehrfach Ifaces geht nicht (das mir eigentlich egal)
[12:22pm] sven-ola: bin mal kurz weg (olsrd neu start == nix inet)
...
fein. wobei das dringenste ist "neustart zeigt link mehrfach" - wenn das passiert muss man den nachbarn neu starten sonst gibts keine ordentlichen routen. Und wenn man gerade kein ssh zum Nachbarn hat, kann man lange warten <ggg>
</pre>

* Mac OS X: sendto() has wrong family parameter in OS X -> nothing gets send out
* Bug in etx_ff <-> etx_fpm compatibility: if etx_ff (openBSD) does, then the topo entry still stays in (linux) etx_fpm
* re-test everything on *all* OSes

= sponsor =

[[Bild:netideelogo.png|200px|supported by IPA]]

The initial work of OLSR-NG was made possible by a grant from [http://www.netidee.at IPA].

After the grant, OLSR-NG still continues as a project. We are again looking for sponsors who believe in this work.

= Sub projects =

==[[SPF refactoring]]==
==[[LSDB refactoring]]==
==[[RIB refactoring]]==
==[[miscellaneous improvements]]==
==[[UML test server]]==
==[[Data Structures and Algorithms]]==

= Who wants to contribute? =

OLSR-NG is a open source project. Meaning everybody is invited to join in and help.
We do have some bounties for the best solutions. If you want to participate, drop us an email: mailto:aaron@lo-res.org, mailto:hannes@gredler.at or mailto:bernd@firmix.at

== Bounties ==

please take a look at the slides http://marvin.funkfeuer.at/~aaron/olsr-ng.pdf and get in contact with us directly.

== Source code ==
* Mercurial repo instructions
http://www.olsr.org/?q=mercurial/

{| width="80%" class="events" cellpadding="5" cellspacing="0" border="1"
!align="left" | Who is willing to work on something
!align="left" | Contact info
|-
| Aaron Kaplan
| mailto:aaron@lo-res.org
|-
| Roman Steiner
| mailto:roman.steiner@gmx.at
|-
| Bernd Petrovitsch
| mailto:bernd@firmix.at
|-
| Andrej Rursev (zethix)
| mailto:zethix@gmail.com
|-
| Hannes Gredler
| mailto:hannes@gredler.at
|}

= Who is working on what? =

{| width="80%" class="events" cellpadding="5" cellspacing="0" border="1"
!align="left" | Who
!align="left" | What
!align="left" | Status
!align="left" | Comments
|- class="oeffentlich"
| Bernd Petrovitsch, Thomas Lopatic, Hannes Gredler
| release 0.5
| DONE
|
|-
| ???
| release 0.5 make packages for freifunk FW, DD-WRT, etc, windows (XP, Vista), ... and test them
| OPEN
| freifunk FW is done by Sven-Ola Tücke, .rpm and .deb by various people on olsr-dev@lists.olsr.org, Windows: ???
|-
| Aaron
| analyze IP autoconfig mechanisms and find the best one
| OPEN
|
|-
| Hannes Gredler
| tcpdump parses olsr packets,
| DONE
|
|-
| Hannes Gredler
| SPF improvements
| DONE
|
|-
| Hannes Gredler
| reduce malloc thrashing during SPF computation
| DONE
|
|-
| Hannes Gredler
| improve post-SPF handling (route table conciliation, best path selection)
| DONE
|
|-
| Bernd Petrovitsch
| rework the logging/tracing/error reporting
| WIP/stalled due to work in other areas
|
|-
| Bernd Petrovitsch
| rework the LQ-TC and LQ-HELLO input parsing, avoiding malloc/free thrashing
| DONE
| The output side can also be avoid ''malloc()'' and ''free()''. Alas, the code is more complicated there.
|-
| Bernd Petrovitsch/Hannes Gredler/???
| supersede all of the ''*_chgestruct()'' functions: All of them are called in exactly one place. So one can inline them there and use the ''pkg_get_*()'' functions to check and use the data. This also avoids more malloc/free thrashing and reduces the amount of code.
| WIP
|
|-
| Hannes Gredler
| spurious neighbor loss on nodes with high neighbor count
| OPEN/investigating
|
|-
| Aaron Kaplan,Bernd Petrovitsch
| olsr-ng test server
| DONE
|
|-
| Aaron Kaplan
| theory, complexity analysis. Goal: find the best complexity on the algorithmic side.
| DONE
| theory tells that fibonacci heaps are best, practise tells that an AVL tree as a minheap implementation fits the complexity of frequent re-keyings better
|-
| Zethix, Aaron Kaplan
| UML cluster setup
| WIP, currently we can start around 2000 UML instances. But the uml_switch software still drops packets between virtual interfaces. http://www.openvz.org seems also like a promising solution
|
|-
| Aaron Kaplan, Hannes
| draft. write a draft about LQ extensions
| OPEN
|
|-
| Bernd Petrovitsch
| Variuos '''Cleanup''' Mini- Projects
| DONE/WIP
| reworked floating point ops in src/mantissa.[ch] to minimize run-time impact, fixed dependencies, reworked ip address copying and comparison to get it type-safe,
|-
| Sebastian Sauer
| LinkQuality / metrics (e.g. ETX/ETT) improvements
| OPEN/WIP (no code yet committed)
| evaluate best current practice;
|-
| Sebastian Sauer
| FishEye improvements
| OPEN/investigating
| evaluate best current practice;
|-
| Sebastian Sauer
| effect of OLSR parameters on the mesh
| OPEN/investigating
| evaluate best current practice; spot and (maybe) eliminate dangers/instabilities
|-
| Sebastian Sauer
| selfish nodes / malicious nodes
| OPEN/investigating
| risk assessments
|-
|}

<mm>[[olsr-ng.mm|flash]]</mm>

= Links =
== Papers, Theory ==

* [http://ietfreport.isoc.org/idref/rfc3626/ RFC-3626]: the "OLSR RFC"
* [http://www.lix.polytechnique.fr/hipercom/index.php?option=com_content&task=view&id=152&Itemid=1 Workshop at Hipercom Oct 2006]
* [http://www.lix.polytechnique.fr/hipercom/index.php?option=com_content&task=view&id=60&Itemid=50 OLSR-v2 Draft 01 at hipercom]
** http://www.ietf.org/internet-drafts/draft-ietf-manet-olsrv2-02.txt
** http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-02.txt
** http://olsrv2.online.fr/blog/ OLSRv2 Development Blog
* http://www.adhocsys.org/
AdHocSys is a two-year European project to provide reliable broadband services in rural and mountain regions. This objective
will be achieved by means of the creation of a wireless ad hoc broadband network, with special enhancements to reliability
and availability. The network consists of one or several gateways connecting to the global Internet and several intermediate
nodes which provide multihop connections between the gateways and end users.
* [http://folk.uio.no/kenneho/index.php?page=studies&subpage=wospf WOSPF-OR] Uni Oslo Wireless OSPF with Overlapping Relays
* [http://hipserver.mct.phantomworks.org/ietf/ospf/ W-OSPF] INRA/Boing Wireless OSPF
* [http://ieeexplore.ieee.org/iel5/7693/4381387/04381410.pdf?isnumber=4381387&prod=JNL&arnumber=4381410&arSt=4014&ared=4024&arAuthor=Hamdaoui%2C+B.%3B+Ramanathan%2C+P. A Cross-Layer Admission Control Framework] for Wireless Ad-Hoc Networks using Multiple Antennas, Bechir Hamdaoui and Parameswaran Ramanathan
* [http://www.orbit-lab.org/wiki/FAQ ORBIT simulator]

== misc ==
* Homepage: http://www.olsr.org/
* NATO C3 Agency (NC3A) Radio Protocols Lab https://elayne.nc3a.nato.int/
* commercial start-up http://www.luceor.com/
* commercial MIT Roofnet spin-off http://www.meraki.net/

[[Category:Dokumentation]]
[[Category:Software]]
[[Category:Routing]]
[[Category: Abkürzungen]]

ARDrone

2010-11-13T16:19:59Z

Aaron:

= ARDrone =

Parrot produces a very nice quadcopter called "ARDone"

Homepage: http://ardrone.parrot.com/parrot-ar-drone/usa/

In Vienna you can get them at [http://www.parrot.com/catalog/pos/parrot/ar-drone/AT/stores/mediamarkt-at Mediamarkt] for 300,- EUR

We plan to make a mesh of flying drones.

== FAQ ==
* how long can it fly?
Approximately 15 minutes

* how much can it carry?
Approx. 200 grams

== Documentation ==

=== Hardware ===
* Linux myhost 2.6.27.47-parrot-01227-g93dde09 #1 PREEMPT Fri Jul 2 15:23:06 CEST 2010 armv5tejl GNU/Linux
* Processor : ARM926EJ-S rev 5 (v5l)
* Mykonos Parrot platform,
* REv: 0904
* Memory: 128MB RAM
* Wi-Fi: AR6000

The Wi-Fi chip seems to have it's own SDIO interface driver. Anyway, the good news for us is, that ad-hoc mode works very well.

=== API ===

* https://projects.ardrone.org/

=== Links / external documentation ===
* http://www.kapejod.org/2010/08/parrot-ar-drone-linux-internals/
*

== Pics ==
<gallery>
Datei:AR.Drone.Bottom.jpg
Datei:AR.Drone.Cross.Junction.jpg
Datei:AR.Drone.Accu.jpg
</gallery>
<gallery>
Datei:AR.Drone.Main.PCB.Front.jpg
Datei:AR.Drone.Main.PCB.Back.jpg
Datei:AR.Drone.US.PCB.Sensors.jpg
Datei:AR.Drone.US.PCB.Front.jpg
</gallery>

ARDrone

2010-11-13T15:52:41Z

Aaron:

= ARDrone =

Parrot produces a very nice quadcopter called "ARDone"

Homepage: http://ardrone.parrot.com/parrot-ar-drone/usa/

In Vienna you can get them at [http://www.parrot.com/catalog/pos/parrot/ar-drone/AT/stores/mediamarkt-at Mediamarkt] for 300,- EUR

== FAQ ==
* how long can it fly?

Approximately 15 minutes

* how much can it carry?

Approx. 200 grams

== Documentation ==

=== Hardware ===
* Linux myhost 2.6.27.47-parrot-01227-g93dde09 #1 PREEMPT Fri Jul 2 15:23:06 CEST 2010 armv5tejl GNU/Linux
* Processor : ARM926EJ-S rev 5 (v5l)
* Mykonos Parrot platform,
* REv: 0904
* Memory: 128MB RAM
* Wi-Fi: AR6000

The Wi-Fi chip seems to have it's own SDIO interface driver. Anyway, the good news for us is, that ad-hoc mode works very well.

=== API ===

* https://projects.ardrone.org/

=== Links / external documentation ===
* http://www.kapejod.org/2010/08/parrot-ar-drone-linux-internals/
*

ARDrone

2010-11-13T15:46:52Z

Aaron:

ARDrone

2010-11-13T15:27:31Z

Aaron:

2009-08-25T19:07:51Z

2008-07-27T11:03:30Z

Aaron: /* upcoming 0.5.6 */

<google>OLSR</google>

= Goals =

Our mission is simple. Build the most scalable and usable routing daemon routing wireless and fixed line segments.
The routing daemon shall scale up to

# 10000 (10K) nodes and
# 20000 (20K) routes
running on low-cost hardware (200 Mhz RISC CPUs / 32MB of memory).

One of the main goals is to make OLSR more scalable '''in practice'''.
[[Bild:O-Dijkstra.gif|350px|right|Complexity for n=1000 nodes of different data structures in the Dijkstra shortest path (SPF) algorithm. ]]

In the this picture you can see the different complexity graphs for the SPF under the assumption that every node has 10 edges . As you can see, the red line has O(n^2) complexity. This conformed to the implementation of OLSR from www.olsr.org ('''before''' the OLSR-NG project). OLSR-NG reduced the complexity to the green level. This will allow the mesh network clouds to become larger by a factor ~ 1000 (on the level of calculating the dijkstra (shortes path) algorithm so far).

For achieving that we first want to

# fix the existing olsrd and add new data structures and algorithms.
# Once olsrd is running fast we focus on protocol issues like
## measuring better links metrics, like including the bandwidth (ETT)
## link-state db synchronization issues (rather then brute force retransmission).
All protocol extensions shall be documented as an internet-draft and submitted to the IETF MANET working group http://www.ietf.org/html.charters/manet-charter.html

Next we want to improve the management tools of olsrd like the

# http_info plugin or
# txt_info plugins or
# building a new XMLinfo plugin

such that that large clouds consisting of thousands of nodes
can be troubleshooted in an effective way.

Main OLSR-NG project blog: http://olsr.funkfeuer.at
Slides from the OLSR-NG kickoff presentation: http://marvin.funkfeuer.at/~aaron/olsr-ng.pdf

= Current Status =

=== stable ===
* olsrd 0.5.5 was released! Thx everybody a lot! - See changes int the [http://sourceforge.net/project/shownotes.php?release_id=574533&group_id=117612 Changelog]

=== upcoming 0.5.6 ===

'''buglist:''' Things that ''need'' to be changed before we release 0.5.6

<pre>
sven-ola: stimmt. glaub' ich auch. Da sind noch 2 Bugs drin.
[12:19pm] sven-ola: oder sogar drei. Das sind aus meiner Sicht:
[12:20pm] sven-ola: 1) das nach neustart unter http://localhost:2006/links derselbe Node mehrfach auftaucht
[12:20pm] sven-ola: 2) das etx_ff mit olsr-0.5.5 (oder etx_fpm) nur bis LQ=0.6 kommt
[12:20pm] sven-ola: 3) unter windoof: mehrfach Ifaces geht nicht (das mir eigentlich egal)
[12:22pm] sven-ola: bin mal kurz weg (olsrd neu start == nix inet)
...
fein. wobei das dringenste ist "neustart zeigt link mehrfach" - wenn das passiert muss man den nachbarn neu starten sonst gibts keine ordentlichen routen. Und wenn man gerade kein ssh zum Nachbarn hat, kann man lange warten <ggg>
</pre>

* Mac OS X: sendto() has wrong family parameter in OS X -> nothing gets send out
* Bug in etx_ff <-> etx_fpm compatibility: if etx_ff (openBSD) does, then the topo entry still stays in (linux) etx_fpm
* re-test everything on *all* OSes

= sponsor =

[[Bild:netideelogo.png|200px|supported by IPA]]

The initial work of OLSR-NG was made possible by a grant from [http://www.netidee.at IPA].

After the grant, OLSR-NG still continues as a project. We are again looking for sponsors who believe in this work.

= Sub projects =

==[[SPF refactoring]]==
==[[LSDB refactoring]]==
==[[RIB refactoring]]==
==[[miscellaneous improvements]]==
==[[UML test server]]==
==[[Data Structures and Algorithms]]==

= Who wants to contribute? =

OLSR-NG is a open source project. Meaning everybody is invited to join in and help.
We do have some bounties for the best solutions. If you want to participate, drop us an email: mailto:aaron@lo-res.org, mailto:hannes@gredler.at or mailto:bernd@firmix.at

== Bounties ==

please take a look at the slides http://marvin.funkfeuer.at/~aaron/olsr-ng.pdf and get in contact with us directly.

== Source code ==
* Mercurial repo instructions
http://www.olsr.org/?q=mercurial/

{| width="80%" class="events" cellpadding="5" cellspacing="0" border="1"
!align="left" | Who is willing to work on something
!align="left" | Contact info
|-
| Aaron Kaplan
| mailto:aaron@lo-res.org
|-
| Roman Steiner
| mailto:roman.steiner@gmx.at
|-
| Bernd Petrovitsch
| mailto:bernd@firmix.at
|-
| Andrej Rursev (zethix)
| mailto:zethix@gmail.com
|-
| Hannes Gredler
| mailto:hannes@gredler.at
|}

= Who is working on what? =

{| width="80%" class="events" cellpadding="5" cellspacing="0" border="1"
!align="left" | Who
!align="left" | What
!align="left" | Status
!align="left" | Comments
|- class="oeffentlich"
| Bernd Petrovitsch, Thomas Lopatic, Hannes Gredler
| release 0.5
| DONE
|
|-
| ???
| release 0.5 make packages for freifunk FW, DD-WRT, etc, windows (XP, Vista), ... and test them
| OPEN
| freifunk FW is done by Sven-Ola Tücke, .rpm and .deb by various people on olsr-dev@lists.olsr.org, Windows: ???
|-
| Aaron
| analyze IP autoconfig mechanisms and find the best one
| OPEN
|
|-
| Hannes Gredler
| tcpdump parses olsr packets,
| DONE
|
|-
| Hannes Gredler
| SPF improvements
| DONE
|
|-
| Hannes Gredler
| reduce malloc thrashing during SPF computation
| DONE
|
|-
| Hannes Gredler
| improve post-SPF handling (route table conciliation, best path selection)
| DONE
|
|-
| Bernd Petrovitsch
| rework the logging/tracing/error reporting
| WIP/stalled due to work in other areas
|
|-
| Bernd Petrovitsch
| rework the LQ-TC and LQ-HELLO input parsing, avoiding malloc/free thrashing
| DONE
| The output side can also be avoid ''malloc()'' and ''free()''. Alas, the code is more complicated there.
|-
| Bernd Petrovitsch/Hannes Gredler/???
| supersede all of the ''*_chgestruct()'' functions: All of them are called in exactly one place. So one can inline them there and use the ''pkg_get_*()'' functions to check and use the data. This also avoids more malloc/free thrashing and reduces the amount of code.
| WIP
|
|-
| Hannes Gredler
| spurious neighbor loss on nodes with high neighbor count
| OPEN/investigating
|
|-
| Aaron Kaplan,Bernd Petrovitsch
| olsr-ng test server
| DONE
|
|-
| Aaron Kaplan
| theory, complexity analysis. Goal: find the best complexity on the algorithmic side.
| DONE
| theory tells that fibonacci heaps are best, practise tells that an AVL tree as a minheap implementation fits the complexity of frequent re-keyings better
|-
| Zethix, Aaron Kaplan
| UML cluster setup
| WIP, currently we can start around 2000 UML instances. But the uml_switch software still drops packets between virtual interfaces. http://www.openvz.org seems also like a promising solution
|
|-
| Aaron Kaplan, Hannes
| draft. write a draft about LQ extensions
| OPEN
|
|-
| Bernd Petrovitsch
| Variuos '''Cleanup''' Mini- Projects
| DONE/WIP
| reworked floating point ops in src/mantissa.[ch] to minimize run-time impact, fixed dependencies, reworked ip address copying and comparison to get it type-safe,
|-
| Sebastian Sauer
| LinkQuality / metrics (e.g. ETX/ETT) improvements
| OPEN/WIP (no code yet committed)
| evaluate best current practice;
|-
| Sebastian Sauer
| FishEye improvements
| OPEN/investigating
| evaluate best current practice;
|-
| Sebastian Sauer
| effect of OLSR parameters on the mesh
| OPEN/investigating
| evaluate best current practice; spot and (maybe) eliminate dangers/instabilities
|-
| Sebastian Sauer
| selfish nodes / malicious nodes
| OPEN/investigating
| risk assessments
|-
|}

<mm>[[olsr-ng.mm|flash]]</mm>

= Links =
== Papers, Theory ==

* [http://ietfreport.isoc.org/idref/rfc3626/ RFC-3626]: the "OLSR RFC"
* [http://www.lix.polytechnique.fr/hipercom/index.php?option=com_content&task=view&id=152&Itemid=1 Workshop at Hipercom Oct 2006]
* [http://www.lix.polytechnique.fr/hipercom/index.php?option=com_content&task=view&id=60&Itemid=50 OLSR-v2 Draft 01 at hipercom]
** http://www.ietf.org/internet-drafts/draft-ietf-manet-olsrv2-02.txt
** http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-02.txt
** http://olsrv2.online.fr/blog/ OLSRv2 Development Blog
* http://www.adhocsys.org/
AdHocSys is a two-year European project to provide reliable broadband services in rural and mountain regions. This objective
will be achieved by means of the creation of a wireless ad hoc broadband network, with special enhancements to reliability
and availability. The network consists of one or several gateways connecting to the global Internet and several intermediate
nodes which provide multihop connections between the gateways and end users.
* [http://folk.uio.no/kenneho/index.php?page=studies&subpage=wospf WOSPF-OR] Uni Oslo Wireless OSPF with Overlapping Relays
* [http://hipserver.mct.phantomworks.org/ietf/ospf/ W-OSPF] INRA/Boing Wireless OSPF
* [http://ieeexplore.ieee.org/iel5/7693/4381387/04381410.pdf?isnumber=4381387&prod=JNL&arnumber=4381410&arSt=4014&ared=4024&arAuthor=Hamdaoui%2C+B.%3B+Ramanathan%2C+P. A Cross-Layer Admission Control Framework] for Wireless Ad-Hoc Networks using Multiple Antennas, Bechir Hamdaoui and Parameswaran Ramanathan
* [http://www.orbit-lab.org/wiki/FAQ ORBIT simulator]

== misc ==
* Homepage: http://www.olsr.org/
* NATO C3 Agency (NC3A) Radio Protocols Lab https://elayne.nc3a.nato.int/
* commercial INRIA HIPERCOM spin-off http://www.luceor.com/
* commercial MIT Roofnet spin-off http://www.meraki.net/

OLSR-NG

2008-07-27T10:51:36Z

Aaron: /* Current Status */

<google>OLSR</google>

= Goals =

Our mission is simple. Build the most scalable and usable routing daemon routing wireless and fixed line segments.
The routing daemon shall scale up to

# 10000 (10K) nodes and
# 20000 (20K) routes
running on low-cost hardware (200 Mhz RISC CPUs / 32MB of memory).

One of the main goals is to make OLSR more scalable '''in practice'''.
[[Bild:O-Dijkstra.gif|350px|right|Complexity for n=1000 nodes of different data structures in the Dijkstra shortest path (SPF) algorithm. ]]

In the this picture you can see the different complexity graphs for the SPF under the assumption that every node has 10 edges . As you can see, the red line has O(n^2) complexity. This conformed to the implementation of OLSR from www.olsr.org ('''before''' the OLSR-NG project). OLSR-NG reduced the complexity to the green level. This will allow the mesh network clouds to become larger by a factor ~ 1000 (on the level of calculating the dijkstra (shortes path) algorithm so far).

For achieving that we first want to

# fix the existing olsrd and add new data structures and algorithms.
# Once olsrd is running fast we focus on protocol issues like
## measuring better links metrics, like including the bandwidth (ETT)
## link-state db synchronization issues (rather then brute force retransmission).
All protocol extensions shall be documented as an internet-draft and submitted to the IETF MANET working group http://www.ietf.org/html.charters/manet-charter.html

Next we want to improve the management tools of olsrd like the

# http_info plugin or
# txt_info plugins or
# building a new XMLinfo plugin

such that that large clouds consisting of thousands of nodes
can be troubleshooted in an effective way.

Main OLSR-NG project blog: http://olsr.funkfeuer.at
Slides from the OLSR-NG kickoff presentation: http://marvin.funkfeuer.at/~aaron/olsr-ng.pdf

= Current Status =

=== stable ===
* olsrd 0.5.5 was released! Thx everybody a lot! - See changes int the [http://sourceforge.net/project/shownotes.php?release_id=574533&group_id=117612 Changelog]

=== upcoming 0.5.6 ===

'''buglist:''' Things that ''need'' to be changed before we release 0.5.6

sven-ola: stimmt. glaub' ich auch. Da sind noch 2 Bugs drin.
[12:19pm] sven-ola: oder sogar drei. Das sind aus meiner Sicht:
[12:20pm] sven-ola: 1) das nach neustart unter http://localhost:2006/links derselbe Node mehrfach auftaucht
[12:20pm] sven-ola: 2) das etx_ff mit olsr-0.5.5 (oder etx_fpm) nur bis LQ=0.6 kommt
[12:20pm] sven-ola: 3) unter windoof: mehrfach Ifaces geht nicht (das mir eigentlich egal)
[12:22pm] sven-ola: bin mal kurz weg (olsrd neu start == nix inet)

* Mac OS X: sendto() has wrong family parameter in OS X -> nothing gets send out
* Bug in etx_ff <-> etx_fpm compatibility: if etx_ff (openBSD) does, then the topo entry still stays in (linux) etx_fpm
* re-test everything on *all* OSes

= sponsor =

[[Bild:netideelogo.png|200px|supported by IPA]]

The initial work of OLSR-NG was made possible by a grant from [http://www.netidee.at IPA].

After the grant, OLSR-NG still continues as a project. We are again looking for sponsors who believe in this work.

= Sub projects =

==[[SPF refactoring]]==
==[[LSDB refactoring]]==
==[[RIB refactoring]]==
==[[miscellaneous improvements]]==
==[[UML test server]]==
==[[Data Structures and Algorithms]]==

= Who wants to contribute? =

OLSR-NG is a open source project. Meaning everybody is invited to join in and help.
We do have some bounties for the best solutions. If you want to participate, drop us an email: mailto:aaron@lo-res.org, mailto:hannes@gredler.at or mailto:bernd@firmix.at

== Bounties ==

please take a look at the slides http://marvin.funkfeuer.at/~aaron/olsr-ng.pdf and get in contact with us directly.

== Source code ==
* Mercurial repo instructions
http://www.olsr.org/?q=mercurial/

{| width="80%" class="events" cellpadding="5" cellspacing="0" border="1"
!align="left" | Who is willing to work on something
!align="left" | Contact info
|-
| Aaron Kaplan
| mailto:aaron@lo-res.org
|-
| Roman Steiner
| mailto:roman.steiner@gmx.at
|-
| Bernd Petrovitsch
| mailto:bernd@firmix.at
|-
| Andrej Rursev (zethix)
| mailto:zethix@gmail.com
|-
| Hannes Gredler
| mailto:hannes@gredler.at
|}

= Who is working on what? =

{| width="80%" class="events" cellpadding="5" cellspacing="0" border="1"
!align="left" | Who
!align="left" | What
!align="left" | Status
!align="left" | Comments
|- class="oeffentlich"
| Bernd Petrovitsch, Thomas Lopatic, Hannes Gredler
| release 0.5
| DONE
|
|-
| ???
| release 0.5 make packages for freifunk FW, DD-WRT, etc, windows (XP, Vista), ... and test them
| OPEN
| freifunk FW is done by Sven-Ola Tücke, .rpm and .deb by various people on olsr-dev@lists.olsr.org, Windows: ???
|-
| Aaron
| analyze IP autoconfig mechanisms and find the best one
| OPEN
|
|-
| Hannes Gredler
| tcpdump parses olsr packets,
| DONE
|
|-
| Hannes Gredler
| SPF improvements
| DONE
|
|-
| Hannes Gredler
| reduce malloc thrashing during SPF computation
| DONE
|
|-
| Hannes Gredler
| improve post-SPF handling (route table conciliation, best path selection)
| DONE
|
|-
| Bernd Petrovitsch
| rework the logging/tracing/error reporting
| WIP/stalled due to work in other areas
|
|-
| Bernd Petrovitsch
| rework the LQ-TC and LQ-HELLO input parsing, avoiding malloc/free thrashing
| DONE
| The output side can also be avoid ''malloc()'' and ''free()''. Alas, the code is more complicated there.
|-
| Bernd Petrovitsch/Hannes Gredler/???
| supersede all of the ''*_chgestruct()'' functions: All of them are called in exactly one place. So one can inline them there and use the ''pkg_get_*()'' functions to check and use the data. This also avoids more malloc/free thrashing and reduces the amount of code.
| WIP
|
|-
| Hannes Gredler
| spurious neighbor loss on nodes with high neighbor count
| OPEN/investigating
|
|-
| Aaron Kaplan,Bernd Petrovitsch
| olsr-ng test server
| DONE
|
|-
| Aaron Kaplan
| theory, complexity analysis. Goal: find the best complexity on the algorithmic side.
| DONE
| theory tells that fibonacci heaps are best, practise tells that an AVL tree as a minheap implementation fits the complexity of frequent re-keyings better
|-
| Zethix, Aaron Kaplan
| UML cluster setup
| WIP, currently we can start around 2000 UML instances. But the uml_switch software still drops packets between virtual interfaces. http://www.openvz.org seems also like a promising solution
|
|-
| Aaron Kaplan, Hannes
| draft. write a draft about LQ extensions
| OPEN
|
|-
| Bernd Petrovitsch
| Variuos '''Cleanup''' Mini- Projects
| DONE/WIP
| reworked floating point ops in src/mantissa.[ch] to minimize run-time impact, fixed dependencies, reworked ip address copying and comparison to get it type-safe,
|-
| Sebastian Sauer
| LinkQuality / metrics (e.g. ETX/ETT) improvements
| OPEN/WIP (no code yet committed)
| evaluate best current practice;
|-
| Sebastian Sauer
| FishEye improvements
| OPEN/investigating
| evaluate best current practice;
|-
| Sebastian Sauer
| effect of OLSR parameters on the mesh
| OPEN/investigating
| evaluate best current practice; spot and (maybe) eliminate dangers/instabilities
|-
| Sebastian Sauer
| selfish nodes / malicious nodes
| OPEN/investigating
| risk assessments
|-
|}

<mm>[[olsr-ng.mm|flash]]</mm>

= Links =
== Papers, Theory ==

* [http://ietfreport.isoc.org/idref/rfc3626/ RFC-3626]: the "OLSR RFC"
* [http://www.lix.polytechnique.fr/hipercom/index.php?option=com_content&task=view&id=152&Itemid=1 Workshop at Hipercom Oct 2006]
* [http://www.lix.polytechnique.fr/hipercom/index.php?option=com_content&task=view&id=60&Itemid=50 OLSR-v2 Draft 01 at hipercom]
** http://www.ietf.org/internet-drafts/draft-ietf-manet-olsrv2-02.txt
** http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-02.txt
** http://olsrv2.online.fr/blog/ OLSRv2 Development Blog
* http://www.adhocsys.org/
AdHocSys is a two-year European project to provide reliable broadband services in rural and mountain regions. This objective
will be achieved by means of the creation of a wireless ad hoc broadband network, with special enhancements to reliability
and availability. The network consists of one or several gateways connecting to the global Internet and several intermediate
nodes which provide multihop connections between the gateways and end users.
* [http://folk.uio.no/kenneho/index.php?page=studies&subpage=wospf WOSPF-OR] Uni Oslo Wireless OSPF with Overlapping Relays
* [http://hipserver.mct.phantomworks.org/ietf/ospf/ W-OSPF] INRA/Boing Wireless OSPF
* [http://ieeexplore.ieee.org/iel5/7693/4381387/04381410.pdf?isnumber=4381387&prod=JNL&arnumber=4381410&arSt=4014&ared=4024&arAuthor=Hamdaoui%2C+B.%3B+Ramanathan%2C+P. A Cross-Layer Admission Control Framework] for Wireless Ad-Hoc Networks using Multiple Antennas, Bechir Hamdaoui and Parameswaran Ramanathan
* [http://www.orbit-lab.org/wiki/FAQ ORBIT simulator]

== misc ==
* Homepage: http://www.olsr.org/
* NATO C3 Agency (NC3A) Radio Protocols Lab https://elayne.nc3a.nato.int/
* commercial INRIA HIPERCOM spin-off http://www.luceor.com/
* commercial MIT Roofnet spin-off http://www.meraki.net/