<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Lieber Aaron!<br>
<br>
Am 2017-03-15 um 20:18 schrieb L. Aaron Kaplan:<br>
</div>
<blockquote
cite="mid:AC8252D2-D32E-4235-A0FB-C18A21C59E87@lo-res.org"
type="cite">[...]
<pre wrap="">
Im Ernst: Ich gebe Bernhard recht - ja, das Problem (egal wie es letztlich gemacht wir) wird sein, genügend / alle Leute dazu zu bringen, upzudaten. Egal, ob es compatibility features gibt oder nicht. Wir brauchen updates. So oder so.
Insofern mag ich diese Diskussion *auch* dazu nützen, um ein nachhaltiges update Konzept anzustossen.
Das erscheint mir sogar fast noch wichtiger.
</pre>
</blockquote>
Auch für LEDE gibt es einen Image-Builder. Der Support für den
ersten Release-Cycle (17.01.0) endet aber auch schon recht bald.
Probleme mit diesem sehe ich leider nur insoferne, als der
Ressourcenhunger von LEDE in der Default-Ausstattung auch die an
sich gut bestückten Geräte mit 8MB Flash und 32 MB RAM in die Knie
zwingt (Etwa den TL-WR1043NDv1). Die Tendenz geht zu 64+MB RAM.<br>
Dort empfehle ich die Benützung von kmod-zram, zram-swap und einen
entsprechenden Wert in /etc/config/system in der Sektion "config
system" wie folgt: "option zram_size_mb '24'". Sodann noch in
/etc/rc.local: "sysctl -w vm.min_free_kbytes=0" einfügen und neu
starten.<br>
Außerdem muss man erwähnen, dass das Flashen auf solchen Geräten
leicht zu Bricks führen kann. Es ist mir mit LEDE mehr als einmal
passiert, dass dem Router während des Flashens der Speicher
ausgegangen ist. Der einzig sichere Weg ist das TFTP-Flashing.
Letzteres funktioniert nur mit neueren Bootloadern. D.h. aber man
muss auf älteren Geräten unbedingt einmal auf die Orignal-Firmware
zurück (meist mittels .bin ohne Bootloader). Dann flasht man erneut
die komplette .bin via Webinterface. (Alternative für Hartgesottene:
nur den bootloader mittels dd sichern und via mtd flashen...).<br>
<br>
Für die noch älteren Boxen mit 4Mb Flash und 16 Mb Ram sehe ich
momentan keine Alternative, als sie Auszuwechseln oder sie als
(WDS-)Bridge in Kombination mit VLANs und einem zusätzlichen
OLSRv2-fähigen Gerät zu nützen.<br>
<br>
Ein weiterer Weg - der aber auf Updates verzichten würde - wäre das
Ausstrahlen von VAP/Multi-SSIDs unter Nutzung von VLANs wie
beschrieben, u.z. zusätzlich zu bestehenden SSIDs über die OLSRv1
genützt wird.<br>
Somit blieben diese Geräte selbst auf OLSRv1 und böten einer Box
dahinter die Möglichkeit, unabhängig und absolut kompatibel OLSRv2
zu fahren. Dergestalt wäre der Zugang zu Dual-Stack u.U. relativ
einfach zu realisieren. Die WLAN-APs können dann schrittweise
ausgewechselt, respektive v1 abgeschaltet werden.<br>
Diesen Weg könnte ich mir etwa als Lösungsweg für Knoten wie OZW
oder Brenner vorstellen, wo es definitiv heikler ist, tiefgreifende
Änderungen zu machen.<br>
Nachteil: OLSRv2 wäre von einem einzigen Gerät abhängig - SPoF.<br>
<br>
LG<br>
Erich<br>
<br>
<blockquote
cite="mid:AC8252D2-D32E-4235-A0FB-C18A21C59E87@lo-res.org"
type="cite">
<pre wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
IPv6-wien mailing list
<a class="moz-txt-link-abbreviated" href="mailto:IPv6-wien@lists.funkfeuer.at">IPv6-wien@lists.funkfeuer.at</a>
<a class="moz-txt-link-freetext" href="https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien">https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien</a>
</pre>
</blockquote>
<br>
</body>
</html>