<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hallo!<br>
<br>
Am 2013-12-06 14:27, schrieb Matthias Šubik:<br>
</div>
<blockquote
cite="mid:C530A84D-0161-49B5-BDD4-A964F91808C3@matthias.subik.de"
type="cite">...<br>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Gleichzeitigen Master habe ich nur deshalb, da vorgesehen ist den Adhoc auf dem NW Brenner komplet auszuschalten und nur auf dem Master Betrieb zu verbleiben.
</pre>
</blockquote>
<pre wrap="">Was so bald nicht passieren wird, außer es verschwinden alle WRTs/Buffalos über Nacht aus dem Netz oder werden mit neuerer Firmware ausgestattet.
Eine Firmware, die eine Mischung aus Attitude Adjustment (stable/brcm47xx) und der Freifunk-Firmware wäre, könnte ein Ansatz sein.
Dazu nimmt man eine Openwrt AA, entfernt ein paar Abhängigkeiten, ersetzt iproute2 durch busybox-ip, modifiziert das Paket "base-files" (zwecks Initialisierung, entfernt netifd und Co) soweit bin ich schon einmal... fertig ist das noch länger nicht - ich könnte Hilfe gebrauchen.
</pre>
</blockquote>
<pre wrap="">
Den Teil mit busybox habe ich (glaube ich) verstanden, aber kannst Du für mich (openwrt-trottel-niveau) kurz erklären, was Du für eine Lösung anstrebst?</pre>
</blockquote>
Das Niveau versuche ich gerade zu verlassen - es ist aber leider
immer noch etwas sticky ;-)<br>
<blockquote
cite="mid:C530A84D-0161-49B5-BDD4-A964F91808C3@matthias.subik.de"
type="cite">
<pre wrap="">
Ich habe folgendes verstanden:
- openwrt stable ist zu groß, muss abspecken.</pre>
</blockquote>
Ja, sie ist <u><i>auch</i></u> zu groß. Das Problem sehe ich eher
darin, dass zu viele Daemons den wenigen Ram auffressen und
zusätzlich das bisschen CPU belasten.<br>
Das Gargoyle-Projekt, um ein Beispiel zu nennen, ist im Gegensatz zu
aktuellen OpenWRT-Versionen trotzdem noch vernünftig lauffähig, weil
es verstärkt Aufgaben an die Browser delegiert und damit die CPU und
den RAM des Routers nicht übermäßig strapaziert.<br>
<blockquote
cite="mid:C530A84D-0161-49B5-BDD4-A964F91808C3@matthias.subik.de"
type="cite">
<pre wrap="">- abspecken durch busybox statt whatever ... auch klar.</pre>
</blockquote>
Wir verlieren dabei (im ersten Anlauf dazu) zwar zB
Shaping-Funktionalität über tc, gewinnen aber auch Funktionalität,
weil Platz für andere Dinge da ist.<br>
(uhttpd raus, busybox-httpd rein, sonstige, nützliche Dinge in die
Busybox hinein; tayga und totd möchte ich an Bord sehen, ebenso
einen voll funktionsfähigen wpad, wpa-supplicant, etc...
matrixtunnel sowieso.)<br>
<br>
Was ich auch angedacht habe, ist die Unterstützung für andere User
als root. Webserver als Root zu betreiben, halte ich auch auf
Routern für ein vermeidbares Risiko.<br>
<blockquote
cite="mid:C530A84D-0161-49B5-BDD4-A964F91808C3@matthias.subik.de"
type="cite">
<pre wrap="">
- Du brauchst einen alternativen Init-Ablauf, damit dieser Wechsel auch funktioniert, richtig?
- kann man einen aus einer älteren Version porten?</pre>
</blockquote>
Ja und ja: Allerdings würde man ihn nicht nur stellenweise
überarbeiten müssen, weil sonst auch die Bugs mitgeportet würden,
...<br>
Das UCI würde dabei herausfallen und man würde wieder mit Nvram und
Config-Files arbeiten.<br>
<br>
Der erste Anlauf bringt ein Image der Größe 3,412 Mb für
openwrt-wrt54g-squashfs.bin mit der angefügten .config.<br>
Anzumerken ist, dass ich dafür aber einige Makefiles manipulieren
musste, d.h. mit dieser .config bekommt man mit einem
Standard-Source-Tree noch wesentlich größere Ergebnisse.<br>
Ich überlege, das Projekt (scherzhaft) "Zombie-Gum" (als Kontrapunkt
zu "xyz.Bubbles") auf dem trac-Server zu veröffentlichen, sobald ein
Mindestmaß an Zuverlässigkeit erreicht werden konnte. Ich würde es
allerdings vorziehen, wenn der Source mit alternativen Paketen
ausgestattet dennoch nach einem sync mit dem OpenWRT-Repository noch
lauffähig wäre - das ist er momentan nicht, weil ich direkt an
base-files herumschraube und das "PROVIDES: ..., DEPENDS: ..."
anscheinend nicht so funktioniert, wie ich mir das vorstelle. An
dieser Stelle brauche ich die meiste Hilfe.<br>
<br>
<blockquote
cite="mid:C530A84D-0161-49B5-BDD4-A964F91808C3@matthias.subik.de"
type="cite">
<blockquote type="cite">...<br>
<blockquote type="cite">
<pre wrap="">Aber das ist auch nich nötig, wenn die meiste Datein zu mir nach wie vor von Tunnel und nicht von Brenner kommen. Leider auch von Funkfeuer IPs, nicht unbedingt
aus dem Internet.
</pre>
</blockquote>
</blockquote>
<pre wrap="">den Satz verstehe ich nicht. Funkfeuer IPs (was schon schwammig genug ist, ob das vielleicht housing ist) kommen durch den Tunnel, weil die Metric besser ist? Eigentlich sollte es egal sein, ob Internet oder Mesh-IP, weil ja nur die "beste" Route entscheidet, richtig?</pre>
</blockquote>
Was Petr damit meint, hat sich mir auch nicht erschlossen.<br>
<blockquote
cite="mid:C530A84D-0161-49B5-BDD4-A964F91808C3@matthias.subik.de"
type="cite">
<pre wrap="">
Matthias
ps: ich hab das mal zu Discuss rübergehoben, vielleicht findet das WRT/Buffalo mit aktuellem OpenWRT ja hier seine Anhänger ...</pre>
</blockquote>
Danke! Die Sache mit den WRTs ist nur eine Baustelle. Mein Ziel ist
es weiterhin, dass dasselbe auch mit der Ath9k-Plattform
funktionieren sollte. Die kleinen Router wie der 741er könnten
ebenso von einer anderen Codebasis profitieren. OpenWRT unterstützt
solche Router ebenso wie DD-WRT nur noch widerwillig bis gar nicht
(In den Foren lautet das oft sinngemäß: "Flash <= 4MB: f***
off").<br>
Bei WRTs ist das auch nur noch bedingt sinnvoll, aber es sind halt
doch noch einige (sogar fast neue) in Umlauf, die beschränkt durch
die CPU aber doch, auf Nebenstrecken ihre Berechtigung haben.<br>
Ich halte die WRTs und den gegenwärtigen Softwarestand für einen
Schlüsselfaktor (Bremse) bei einer Umstellung auf andere Konzepte.<br>
<br>
LG<br>
Erich<br>
<br>
</body>
</html>