<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hallo!<br>
<br>
Am 2016-03-10 um 21:12 schrieb Wolfgang Nagele:<br>
</div>
<blockquote
cite="mid:CAK6j62w2OS5P4rVfdD6t1M-SnvnfkWspTr2b4_fyuNBHzC4=pA@mail.gmail.com"
type="cite">
<div dir="ltr">Hey,
<div><br>
[...]</div>
</div>
</blockquote>
(BCC: Henning)<br>
<blockquote
cite="mid:CAK6j62w2OS5P4rVfdD6t1M-SnvnfkWspTr2b4_fyuNBHzC4=pA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>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.</div>
</div>
</blockquote>
Apropos Anfangsphase:<br>
Wie wäre es mit dem folgenden Vorschlag für die
Grundlagenentwicklungsphase:<br>
<ol>
<li>virtuelle Maschinen mit OpenWRT x86-kvm (da gibt's sogar ein
Image dafür) aufsetzen</li>
<li>Testnetz zwischen denen aufbauen</li>
<li>Konfigurationen variieren (v6-only, dual-stack, dual-olsr)</li>
<li>Linksys dazuhängen<br>
</li>
</ol>
Jeder im Team bekommt einen solchen virtuellen oder echten "Router"
zum Testen. Einer von Euch koordiniert die Tests.<br>
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.<br>
Die Testszenarien solltet ihr natürlich im Team planen.<br>
<br>
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?<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Nächster Schritt: Dasselbe mit echten Routern auf der
Atheros-Plattform, auf der mittlerweile recht viel im Netz läuft.<br>
<br>
Letzter Schritt: Firmware für die WRTs.<br>
<br>
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.<br>
<br>
<blockquote
cite="mid:CAK6j62w2OS5P4rVfdD6t1M-SnvnfkWspTr2b4_fyuNBHzC4=pA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Freue mich schon wenn du dich auch mehr beteiligen kannst.</div>
</div>
</blockquote>
Ich lese hier gern mit, was sich tut.<br>
<br>
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.<br>
Ganz wichtig wäre neben der Planungskoordination die Dokumentation
der Erkenntnisse und die (öffentliche) Niederschrift daraus
entwickelter neuer Szenarien.<br>
<br>
<blockquote
cite="mid:CAK6j62w2OS5P4rVfdD6t1M-SnvnfkWspTr2b4_fyuNBHzC4=pA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div> Bin mir sicher das du jede Menge hier beitragen kannst.<br>
</div>
</div>
</blockquote>
Hoffen wir es ;-)<br>
Das hier war jedenfalls schon einmal ein Versuch.<br>
<br>
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...<br>
<br>
<br>
Danke für Dein und Euer Engagement!<br>
<blockquote
cite="mid:CAK6j62w2OS5P4rVfdD6t1M-SnvnfkWspTr2b4_fyuNBHzC4=pA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>lg</div>
<div><br>
</div>
</div>
</blockquote>
LG<br>
Erich<br>
<blockquote
cite="mid:CAK6j62w2OS5P4rVfdD6t1M-SnvnfkWspTr2b4_fyuNBHzC4=pA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">2016-03-10 19:40 GMT+01:00 Erich N.
Pekarek <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:erich@pekarek.at" target="_blank">erich@pekarek.at</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span class="">
<div>Am 2016-03-10 um 18:25 schrieb Wolfgang Nagele:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hallo,
<div><br>
</div>
<div>Sehr viele gute Fragen hier. </div>
</div>
</blockquote>
</span> Auch viele alte Fragen. Henning Rogge hat einige
Vorarbeiten geleistet, soweit ich mir bekannt ist. Sind
diese Grundlage dieser Bestrebungen?<span class=""><br>
<blockquote type="cite">
<div dir="ltr">
<div>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.</div>
</div>
</blockquote>
</span> 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.<br>
Auch können E-Mails produktiver sein als Treffen, bei
denen die Aufmerksamkeit durch Gruppendynamik leicht
abgleitet.<span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>Kurz - der Grossteil dieser Fragen ist noch
komplett offen. Im Moment ist der Fokus auf
Machbarkeit - d.h. Installation und testen.</div>
</div>
</blockquote>
</span> OLSRv2 in ein Image zu kompilieren, ist auch mit
dem Imagebuilder keine allzu große Hexerei:<br>
<br>
oonf-dlep-proxy_0.9.2_ar71xx.ipk<br>
oonf-dlep-radio_0.9.2_ar71xx.ipk<br>
oonf-init-scripts_0.9.1-r3_ar71xx.ipk<br>
oonf-olsrd2_0.9.2_ar71xx.ipk<br>
<br>
'PACKAGES+="oonf-olsrd2 ... "'<br>
<br>
Ansonsten: definiere Machbarkeit; was willst Du
eigentlich machen und wobei genau brauchst Du Hilfe? Die
Devise muss "delegieren und dokumentieren" lauten.<span
class=""><br>
<blockquote type="cite">
<div dir="ltr">
<div> 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.</div>
</div>
</blockquote>
</span> 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.<span
class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
</span> 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.<br>
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.<br>
<br>
Das OpenWRT-Projekt selbst unterstützt Hardware mit
<16 MB RAM und <4MB Flash ohnedies kaum noch.<span
class=""><br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
<br>
</span> 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?<br>
Natürlich könnte man auch heute noch Flugbahnen von
Objekten mit Röhrencomputern errechnen und sicherlich
macht das einigen Enthusiasten auch Spaß...<br>
Es geht heute aber auch anders: schneller und genauer.<span
class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Abschliessend - bitte komm vorbei wir
brauchen mehr Leute die diese Probleme begreifen
und an der Loesung mitarbeiten wollen.</div>
</div>
</blockquote>
</span> Ab dem Sommer gerne. Davor habe ich persönlich
pressierendere Angelegenheiten zu regeln.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Wie Du richtig sagst: Schritt für Schritt.
<div>
<div class="h5"><br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>lg<br>
</div>
<div><br>
On Thursday, 10 March 2016, Erich N. Pekarek
<<a moz-do-not-send="true"
href="mailto:erich@pekarek.at"
target="_blank">erich@pekarek.at</a>>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hallo!<br>
<br>
Ich wollte mich zwar aus der Diskussion
ausklinken, aber möchte nun doch ein Fragen
stellen...<br>
<br>
Am 2016-03-10 um 16:19 schrieb Wolfgang
Nagele:<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi,<br>
<br>
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.<br>
</blockquote>
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.<br>
<br>
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.<br>
<br>
Welche Gründe sprechen für eine
Weiterverwendung, welche dagegen?<br>
<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
[...]<br>
<br>
Um es euch noch etwas schmackhafter zu
machen - hier eine Simulation wie die Netz
Umstellung ausschauen könnte:<br>
<br>
<a moz-do-not-send="true"
href="https://dl.dropboxusercontent.com/u/3352025/funkfeuer-transition-olsr-v1-to-v2.mp4"
target="_blank">https://dl.dropboxusercontent.com/u/3352025/funkfeuer-transition-olsr-v1-to-v2.mp4</a><br>
</blockquote>
<br>
Auf welchem sonstigen Planungskonzept beruht
dieses Rollout-Vorhaben?<br>
Seid Ihr schon so weit, dass man ans Rollout
denken kann? Welche Tests wurden bisher
gemacht?<br>
Wie ist das Laufzeitverhalten von OLSRv2 auf
den üblichen Geräten?<br>
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?)<br>
<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Legende:<br>
- Dunkelgruen sind Links/Knoten die Dual
laufen werden (OLSRv1 auf IPv4 und OLSRv2
auf IPv6)<br>
- Hellgruen sind Links/Knoten auf OLSRv2
mit IPv6 only<br>
- Grau sind Links/Knoten auf OLSRv1 mit
IPv4 only<br>
</blockquote>
Offensichtlich geht Ihr von einer totalen
Migration aus. Wie realistisch ist es, dass
diese passiert?<br>
Ich nehme Bezug auf eventuell verwaiste
Knoten, nicht migrierbare Hardware (Speicher
< 16MB), User-Akzeptanz.<br>
<br>
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)?<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
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.<br>
</blockquote>
Unter welchen Rahmenbedingungen?<br>
Wer koordiniert das?<br>
Wer führt das aus?<br>
<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.<br>
</blockquote>
Ist es sinnvoll, dass Netz nicht zu
fragmentieren oder kann gezielte
Fragmentierung nicht auch ein Vorteil sein?<br>
Was, wenn Knotenbetreiber auf dem Status Quo
beharren?<br>
<br>
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.<br>
<br>
Ist der bisherige Fortschritt und der
Softwareentwicklungsprozess öffentlich
dokumentiert? Wenn ja, wo?<br>
<br>
Danke!<br>
<br>
LG<br>
Erich<br>
<br>
<br>
</blockquote>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</blockquote>
</div>
</div>
LG<span class="HOEnZb"><font color="#888888"><br>
Erich<br>
</font></span></div>
<br>
--<br>
Discuss mailing list<br>
<a moz-do-not-send="true"
href="mailto:Discuss@lists.funkfeuer.at">Discuss@lists.funkfeuer.at</a><br>
<a moz-do-not-send="true"
href="https://lists.funkfeuer.at/mailman/listinfo/discuss"
rel="noreferrer" target="_blank">https://lists.funkfeuer.at/mailman/listinfo/discuss</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<blockquote
cite="mid:CAK6j62w2OS5P4rVfdD6t1M-SnvnfkWspTr2b4_fyuNBHzC4=pA@mail.gmail.com"
type="cite">
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
</body>
</html>