[Discuss] [v642] Hack Weekend
Erich N. Pekarek
(spam-protected)
Do Mär 10 22:39:43 CET 2016
Hallo!
Am 2016-03-10 um 21:12 schrieb Wolfgang Nagele:
> Hey,
>
> [...]
(BCC: Henning)
> Wenn die Simulation und andere Bereiche konkreter sind wirds auch
> ausserhalb der Gruppe die aktiv daran arbeitet mehr Info geben. Im
> Moment waer das einfach zuviel Overhead weil wir in der Anfangsphase sind.
Apropos Anfangsphase:
Wie wäre es mit dem folgenden Vorschlag für die Grundlagenentwicklungsphase:
1. virtuelle Maschinen mit OpenWRT x86-kvm (da gibt's sogar ein Image
dafür) aufsetzen
2. Testnetz zwischen denen aufbauen
3. Konfigurationen variieren (v6-only, dual-stack, dual-olsr)
4. Linksys dazuhängen
Jeder im Team bekommt einen solchen virtuellen oder echten "Router" zum
Testen. Einer von Euch koordiniert die Tests.
So muss man nicht unbedingt extra zusammenkommen, sondern kann gemütlich
remote und koordiniert testen, das Testnetz bleibt auch aktiv, der Rest
vom Netz wird nicht beeinträchtigt und stromsparend sollte es auch sein.
Die Testszenarien solltet ihr natürlich im Team planen.
Ich schätze, dass dem Verein das ein paar prozessorschwache virtuelle
Maschinen zu diesem Zweck im Housing für den Vereinszweck wert sein
werden, oder?
Testen würde ich's erst mal mit IPv6 ULA-Ranges oder gar nur Link-lokal.
Für IPv4 könnt ihr das apipa/autoconf von Henning nützen.
Die Erfahrung mit x86-kvm kann man dann leicht auf alix und co
übertragen. Hinsichtlich der Paketierung von Firmwares für andere
Plattformen kann man auch etwas auf diese Weise lernen.
Aus den Erfahrungen hieraus Usecases entwickeln und die virtuellen
Router spezialisieren. Jeder Maintainer ist für einen Usecase
verantwortlich. Wird die Arbeit zuviel, soll er eigenständig delegieren.
Nächster Schritt: Dasselbe mit echten Routern auf der Atheros-Plattform,
auf der mittlerweile recht viel im Netz läuft.
Letzter Schritt: Firmware für die WRTs.
Für die WRTs und/oder andere ältere Router wäre womöglich ein v4/v6
Übergangsmechanismus plus entsprechende Ankündigung von Routen lohnender
als die Umrüstung auf OLSRv2 und v6. Ich rechne damit, dass die Art
Hardware nicht mehr ewig im Einsatz sein wird.
>
> Freue mich schon wenn du dich auch mehr beteiligen kannst.
Ich lese hier gern mit, was sich tut.
Es wäre nett, wenn die Planung nicht ausschließlich in der
Kaffeehausrunde oder an Devel-Weekends stattfände - wenn Du in der
Gruppe einen Berichterstatter findest, der wöchentlich hier schreibt,
was es Neues gibt, wäre das eine große Hilfe bis dahin.
Ganz wichtig wäre neben der Planungskoordination die Dokumentation der
Erkenntnisse und die (öffentliche) Niederschrift daraus entwickelter
neuer Szenarien.
> Bin mir sicher das du jede Menge hier beitragen kannst.
Hoffen wir es ;-)
Das hier war jedenfalls schon einmal ein Versuch.
Bitte haltet Kontakt "zur augenscheinlich nicht aktiv beteiligten
Außenwelt", Teil- Probleme lassen sich vielleicht auf diese Weise
schneller lösen. Irgendwer weiß immer irgendwas...
Danke für Dein und Euer Engagement!
>
> lg
>
LG
Erich
>
> 2016-03-10 19:40 GMT+01:00 Erich N. Pekarek <(spam-protected)
> <mailto:(spam-protected)>>:
>
> Am 2016-03-10 um 18:25 schrieb Wolfgang Nagele:
>> Hallo,
>>
>> Sehr viele gute Fragen hier.
> Auch viele alte Fragen. Henning Rogge hat einige Vorarbeiten
> geleistet, soweit ich mir bekannt ist. Sind diese Grundlage dieser
> Bestrebungen?
>> Ich lade dich ein beim naechsten Treffen dabei zu sein weil Email
>> fuer diese Zwecke viel zu langwierig ist. Die Gruppe wurde
>> geformt um etwas vom alten Stil der Zusammenarbeit wieder zurueck
>> zu bringen. D.h. auch das beharren darauf das Leute die sich
>> wirklich beteiligen wollen vorbei kommen. Wir haben viel zu tun
>> und wollen das nicht damit verbringen in Emails zu versinken.
> Ich danke für Deine Einladung, kann sie aber bis zum Sommer nicht
> wahrnehmen. Es gibt viele Termine, an denen ich gerne teilnehmen
> würde, die jedoch nicht Priorität haben. Somit stehen mir derzeit
> für derartige Anlässe nur asynchrone Kommunikationsformen zur
> Verfügung.
> Auch können E-Mails produktiver sein als Treffen, bei denen die
> Aufmerksamkeit durch Gruppendynamik leicht abgleitet.
>
>> Kurz - der Grossteil dieser Fragen ist noch komplett offen. Im
>> Moment ist der Fokus auf Machbarkeit - d.h. Installation und testen.
> OLSRv2 in ein Image zu kompilieren, ist auch mit dem Imagebuilder
> keine allzu große Hexerei:
>
> oonf-dlep-proxy_0.9.2_ar71xx.ipk
> oonf-dlep-radio_0.9.2_ar71xx.ipk
> oonf-init-scripts_0.9.1-r3_ar71xx.ipk
> oonf-olsrd2_0.9.2_ar71xx.ipk
>
> 'PACKAGES+="oonf-olsrd2 ... "'
>
> Ansonsten: definiere Machbarkeit; was willst Du eigentlich machen
> und wobei genau brauchst Du Hilfe? Die Devise muss "delegieren und
> dokumentieren" lauten.
>> Die Simulation dient genau auch dem Zwecke der Machbarkeit - wenn
>> es nicht moeglich ist das Netz ohne grossflaechige Fragmentierung
>> auf einen neuen Standard zu heben brauchen wir nicht weiter
>> machen mit diesem Ansatz.
> Mir ist nicht klar, auf welchen Daten die Simulation genau
> aufbaut, welche Annahmen sie voraussetzt und welche Aussage sie
> tätigt, außer: Das Core-Team fängt an und dann rüsten abwechselnd
> die größten Tech-Cs im Netz Alles um, worauf sie selbst Zugriff
> haben, bis am Ende auch die letzten Nodebetreiber mitziehen
> (müssen). Das Maß an Beteiligung, das hier als Anforderung im Raum
> steht, ist im Widerspruch zur Funktion des sozialen Gefüges von
> Funkfeuer, wie ich es kenne. Damit zäumt man das Pferd von Hinten
> auf. Optisch finde ich das Video nett.
>
>>
>> Veraltete Hardware gibts noch zuhauf im Netz (bis zu 70 Linksys
>> aus der WRT54 Reihe). Wobei wir alle prinzipiell die lieber
>> weghaben wuerden verfolgen wir solange es geht den inklusivesten
>> Ansatz den wir umsetzen koennen. Du hast voellig Recht das es
>> sein koennte das dieser nicht machbar sein wird ... das wollen
>> wir aber zuerst sehen.
> Im urbanen Bereich ist die Nutzung dieser Router mittlerweile von
> nur noch geringem praktischen Wert. Die Hardwarekosten für echte
> Outdoor-Router sind auf ein leistbares Niveau gesunken und deren
> Ausstattung ist gut.
> Zudem altern auch Prozessoren und Kondensatoren und es ist nur
> eine Frage der Zeit, bis aufgrund der Umgebungsbedingungen die
> Zahl der Ausfälle oder sonstiger, unspezifischer Fehlfunktionen
> bei der alten Hardware steigt.
>
> Das OpenWRT-Projekt selbst unterstützt Hardware mit <16 MB RAM und
> <4MB Flash ohnedies kaum noch.
>>
>> Schritt fuer Schritt zum Ziel. Alle Fragen theoretisch
>> durchzukauen motiviert niemanden Probleme zu loesen. Dann fuehlt
>> es sich nur wie ein unbeweltigbares Problem an. Das ist es aber
>> 100% nicht.
>
> Die Frage ist, ob wir manche Probleme überhaupt lösen sollen, um
> zum Ziel zu kommen oder, ob man sich damit nicht vermeidbare
> Komplexität einheimst?
> Natürlich könnte man auch heute noch Flugbahnen von Objekten mit
> Röhrencomputern errechnen und sicherlich macht das einigen
> Enthusiasten auch Spaß...
> Es geht heute aber auch anders: schneller und genauer.
>
>>
>> Abschliessend - bitte komm vorbei wir brauchen mehr Leute die
>> diese Probleme begreifen und an der Loesung mitarbeiten wollen.
> Ab dem Sommer gerne. Davor habe ich persönlich pressierendere
> Angelegenheiten zu regeln.
>
> Gerne kann ich Dir ein rudimentäres Build-Script schicken, mit dem
> ich individualiserte Firmwares mit dem OpenWRT Imagebuilder (image
> generator) erstelle. Zusätzlich die passenden Paketlisten für
> einige Usecases und Router-Modelle (TL-WR740/741/842/1043ND,
> UBNT). Aber Vorsicht: nicht jede Firmware, die da herauskommt,
> funktioniert auch. Eine daraus kompilierte Firmware hat auch schon
> einen Router nachhaltig gebrickt.
>
> Die Konzepte für ein neues Netz kann man jedoch auch auf einfacher
> zu wartender Hardware oder virtualisiert vortesten. Erst dann
> würde ich eine Roadmap erstellen und erst danach eine Firmware
> basteln.
>
> Wie Du richtig sagst: Schritt für Schritt.
>
>>
>> lg
>>
>> On Thursday, 10 March 2016, Erich N. Pekarek <(spam-protected)
>> <mailto:(spam-protected)>> wrote:
>>
>> Hallo!
>>
>> Ich wollte mich zwar aus der Diskussion ausklinken, aber
>> möchte nun doch ein Fragen stellen...
>>
>> Am 2016-03-10 um 16:19 schrieb Wolfgang Nagele:
>>
>> Hi,
>>
>> Am letzten Montag haben wir gute Fortschritte gemacht -
>> OpenWRT und OLSRv2 mit native IPv6 haben wir auf einigen
>> Linksysen sowohl auf LAN als auch WLAN zum Laufen gebracht.
>>
>> Wie sinnvoll ist es, bei Neuentwurf des Netzes auf veraltete
>> Hardware mit nur noch eingeschränkt nutzbarem
>> Frequenzspektrum und nur noch wenig nutzbarem Speicher zu
>> setzen? Meiner Erfahrung nach funktionieren die Linksys WRT
>> mit aktuellerem OpenWRT nur bedingt, uz ohne HTTP/LuCI und
>> mit zram (zram-swap), letzteres zeitweise jedoch nur instabil.
>>
>> Auch für LAN-only-Szenarien erscheint mir diese Hardware
>> nicht unbedingt mehr nützlich, auf wenn ich verstehe, dass
>> der Wunsch, nichts wegwerfen zu müssen existiert und
>> ansonsten legitim ist.
>>
>> Welche Gründe sprechen für eine Weiterverwendung, welche dagegen?
>>
>>
>> [...]
>>
>> Um es euch noch etwas schmackhafter zu machen - hier eine
>> Simulation wie die Netz Umstellung ausschauen könnte:
>>
>> https://dl.dropboxusercontent.com/u/3352025/funkfeuer-transition-olsr-v1-to-v2.mp4
>>
>>
>> Auf welchem sonstigen Planungskonzept beruht dieses
>> Rollout-Vorhaben?
>> Seid Ihr schon so weit, dass man ans Rollout denken kann?
>> Welche Tests wurden bisher gemacht?
>> Wie ist das Laufzeitverhalten von OLSRv2 auf den üblichen
>> Geräten?
>> Wie ist der Speicherbedarf auf den Geräten und wie skaliert
>> er in der Theorie und in der Prognose für den Einsatz
>> aufgrund bisheriger Beobachtungen? (schaut Henning Rogge sich
>> das an?)
>>
>> Legende:
>> - Dunkelgruen sind Links/Knoten die Dual laufen werden
>> (OLSRv1 auf IPv4 und OLSRv2 auf IPv6)
>> - Hellgruen sind Links/Knoten auf OLSRv2 mit IPv6 only
>> - Grau sind Links/Knoten auf OLSRv1 mit IPv4 only
>>
>> Offensichtlich geht Ihr von einer totalen Migration aus. Wie
>> realistisch ist es, dass diese passiert?
>> Ich nehme Bezug auf eventuell verwaiste Knoten, nicht
>> migrierbare Hardware (Speicher < 16MB), User-Akzeptanz.
>>
>> Was wäre das Exit-Szenario für die Abwärtskompatibiltät? Wäre
>> grundsätzlich das Abschneiden alter Zöpfe denkbar
>> (insbesondere: alte Linksys WRTxxyz)?
>>
>>
>> Die Simulation basiert auf der Netztopologie sämtlicher
>> Geräte im dzt. Netz. Da ist noch einiges an Arbeit zu
>> machen (Link Quality miteinbeziehen, etc.) aber es zeigt
>> zumindest das es möglich ist.
>>
>> Unter welchen Rahmenbedingungen?
>> Wer koordiniert das?
>> Wer führt das aus?
>>
>> Wenn wir alles andere haben können wir dann damit genau
>> planen wann welche Geräte upgegraded werden müssen sodass
>> das Netz nicht fragmentiert.
>>
>> Ist es sinnvoll, dass Netz nicht zu fragmentieren oder kann
>> gezielte Fragmentierung nicht auch ein Vorteil sein?
>> Was, wenn Knotenbetreiber auf dem Status Quo beharren?
>>
>> Wieder in Bezugnahme auf Linksys WRT, UBNT AR23xx, ...: Kann
>> es unter der Prämisse von Akkus Leitspruch "ich will
>> niemanden verlieren" sinnvoll sein, OLSRv1-Inseln zu
>> belassen, anstelle diese zu migrieren? An den Schnittpunkten
>> genügt solcherart eine Default-Route auf v4 und ein
>> Transitionsmechanismus auf v6.
>>
>> Ist der bisherige Fortschritt und der
>> Softwareentwicklungsprozess öffentlich dokumentiert? Wenn ja, wo?
>>
>> Danke!
>>
>> LG
>> Erich
>>
>>
>>
>>
> LG
> Erich
>
> --
> Discuss mailing list
> (spam-protected) <mailto:(spam-protected)>
> https://lists.funkfeuer.at/mailman/listinfo/discuss
>
>
>
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/discuss/attachments/20160310/380f6591/attachment.htm>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname : erich.vcf
Dateityp : text/x-vcard
Dateigröße : 4 bytes
Beschreibung: nicht verfügbar
URL : <http://lists.funkfeuer.at/pipermail/discuss/attachments/20160310/380f6591/attachment.vcf>
Mehr Informationen über die Mailingliste Discuss